Управление качеством кода

Публикация № 1096770 22.07.19

Разработка - Математика и алгоритмы

SonarQube BSL АПК acc качество cci

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

Зачем управлять качеством кода.

    Уровни стандартов

    Почему стоит соблюдать стандарты.

        Стандарт это ответ на решенную проблему

        Экономия мыслетоплива

        Удешевление рабочей силы

        Унификация стиля

        Приоритизация

        Сопровождаемость

        Ускорение разработки

    Как проверять качество

        Самоконтроль

        Двойное чтение кода

        Тесты

        Автоматические проверки

    Как статические анализаторы кода улучшают жизнь.

Кому стоит управлять качеством.

Советы по отслеживанию качества

        Проверяются только модули со снятыми замками

        Важно не решить все проблемы, а не вносить новые

        Правило бойскаута

        Нужно четко разделять - это ошибка, тех.долг или ложное срабатывание

        Решить все проблемы не получится

Примеры проверок

    Синтаксическая конструкция вида "Если...Тогда...ИначеЕсли..." должна содержать ветвь "Иначе"

    ТекущаяДата()

    Превышена длина строки

    Орфография

    Отсутствует комментарий к экспортной процедуре (функции)

    В модуле должны быть определены стандартные области

    Установлено право "Интерактивное удаление"

    Использование устаревшей процедуры

    Недопустимый вызов служебной процедуры или функции другой подсистемы

Выводы

 

Это дополнение (продолжение) к статье Олега “Управляй качеством кода 1С с помощью SonarQube”. Как управлять качеством так же писал Никита “Управление техническим долгом - Концепция Continuous Inspection”.

Зачем управлять качеством кода.

В этом разделе попробую продать идею, что правильно писать код - правильно. И как это - правильно.

Нужно как-то измерить внутреннее качество кода.

 

Внутреннее, потому что конечный пользователь этого качества не видит. Это первая холиварная часть - зачем что-то улучшать, что не видит пользователь?

Качество. А что такое качество кода? Каждый разработчик понимает под этим что-то свое. Это вторая холиварная часть. Особенно когда речь заходит о затратах на поддержание этого качества.

Измерить. Если хотим этим управлять, это нужно мерить. И тут тоже без холивара не обходится. Одним кажется важной одна метрика, другим наоборот.

 

Сплошные холивары.

 

Единственный работающий подход для разрубания холиваров - зафиксировать вариант законодательно. Кто соблюдает законы - те молодцы, кто не соблюдает - получает штраф и начинает соблюдать.

 

Законы при разработке в 1С это "Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8"

 

Негласные правила в определении качества: Когда программист смотрит на такой код - вырывается “Ах, что же это такое???”, только матерно. Сокращенно ЧБ. Если код постоянно вызывает ЧБ, то тут нужен стандарт, чтобы так больше не писали. Этот подход используется при добавлении диагностик в https://github.com/1c-syntax/bsl-language-server/issues

 

Уровни стандартов

 

  • Промышленные стандарты (из других языков). На них наткнетесь в интернетах и в книгах. Люто рекомендую прочитать Совершенный код и Чистый код
  • Стандарты 1С https://its.1c.ru/db/v8std. Доступ открыт и бесплатен.
  • Внутренние стандарты Компании. Сюда обычно входят правила префиксации. Правила доработки конфигурации на поддержке для упрощения обновления. Правила идентификации изменений - от любимых // Здесь был Уася по задаче 000666 до правила текста оформления коммита.
  • Личное. Я это называю почерком, когда автора кода легко определить по стилю, но при этом негатива это не вызывает. У меня это “дышащий стиль” с кучей пробелов и отступов, правилами именования, похожими на венгерскую нотацию и другими шаблонами.

 

Чем выше уровень, тем ближе к разработчику. Но если уровни конфликтуют между собой - нужно быть уверенным на 146% в целесообразности. Нужно четко понимать что стоит за нижестоящим стандартом и почему переопределен.

 

Пример хорошего переопределения - префиксация имен у объектов при доработке конфигурации на поддержке. Стандарт 1С запрещает спец. префиксы. Но префиксы помогают при определении принадлежности объекта.

 

Пример плохого переопределения - идентификаторы изменений прям в коде с сохранением старого кода.

 

Почему стоит соблюдать стандарты.

Стандарт это ответ на решенную проблему

Многие стандарты написаны после того, как было потрачено много человекочасов на решение проблемы. Эти правила - превентивные меры по борьбе с ошибками. Придерживаться стандарта стоит минуты, ошибка из-за нарушенного стандарта может превратится в недели потраченного времени. Не писать код, который приводит к ошибке - это и есть качество.

Все стандарты по запросам появились после анализа долгих запросов. Причем долгими в проде.

Экономия мыслетоплива

При разработке постоянно возникают ситуации, когда сидишь над простым куском кода и пытаешся спрогнозировать последствия. Придумываешь абстрактные ситуации, или пропускаешь поведение, которое выстрелит в ногу позже. Стандарт позволяет не помнить всю ситуацию - почему так писать хорошо, а так почему нельзя. Писать нужно так. Точка. Никакой лишней информации. Это позволяет тратить запасы мыслей в других местах.

Удешевление рабочей силы

Вчерашний стажер, который с трудом пишет код и вчерашний стажер, который с трудом пишет код и соблюдает стандарты - это разные уровни. На самом деле сложно писать плохой код соблюдая стандарты. Тут без таланта не обойтись. А раз младший пишет не плохой код, то доверяем задачи посложнее. На сложных задачах растут. А значит эта задача снимается с дорогих разработчиков. Для этого даже термин придумали - стандартизация.

Унификация стиля

Соблюдение стандартов приводит код к единому стилю. А у единого стиля есть одна особенность - разработчик перестает различать где его код, а где коллеги. Разработчик одинаково хорошо начинает разбираться и в своем и в чужом коде. А это приводит к резкому уменьшению желания переписать все с нуля. Меньше энергии тратится на негатив, больше на креатив.

Приоритизация

Что разработчик берет в работу в первую очередь? Важное или срочное? Разработчик берет в первую очередь понятное! (ц) Максим Дорофеев.

Чем качественный код, тем проще разработчикам за него будет взяться, тем меньше будут прокрастинировать над важными или срочными задачами.

Сопровождаемость

Качественный код проще поддерживать и дорабатывать. Чем хуже написан код, тем сложнее найти ошибку или доработать под новые требования. А желание переписать все с нуля возрастает. И наоборот, в качественном коде ошибки становятся очевидными. Можно даже сказать, что при качественной разработке потраченное время переносится с сопровождения на создание по выгодному курсу - качественный код на этапе создания тратит дополнительные минуты, экономя часы и дни поддержки.

Ускорение разработки

Предыдущие пункты складываются в этот. Писать качественно и по стандартам серьезно ускоряет разработку - за счет уменьшения времени на отладку, уменьшения времени на прилетевшие ошибки, на разбирательство в чужом коде, на разбирательство в своем коде…

 

Абстрактный придуманный пример в работе двух команд. Быстрой - которые фигачат код, игнорируя тех. долг, и качественной - у которой качество превыше всего.

 

 

 

Быстрая команда

Качественная команда

Неделя

Задач

Комментарий

Задач

Комментарий

1

20

Ура! Новый проект. Фигачим.

2

Настраиваем окружение, разворачиваем инфраструктуру.

2

20

Все еще фигачим.

2

Продолжаем настраивать, обучаем использованию инструментария

3

18

После выката на прод кое-что отвалилось. Правили.

10

Начали что-то делать. Идет с трудом. Пишем тесты.

4

16

Очередное обновление и очередные проблемы в проде.

15

В проде были проблемы. Писали тесты, чтоб больше не повторилось.

5

15

Один разработчик на дежурстве постоянно мониторит и правит ошибки на проде.

18

Фигачим, вроде втянулись.

6

10

На этот раз прод упал очень сильно. Чинили 2 дня всей командой.

20

Успеваем решить все запланированные задачи и начали писать подробную документацию. Хотя нет, вон статья интересная про сбор ТЖ в ELK, надо попробовать у нас.

7

12

Делать задачи все сложнее. Уже мало кто помнит и понимает почему сделано так.

20

 

8

9

Уволился один из разработчиков.

22

Двоих застукали за опенсорсом в рабочее время, надо с ними что-то сделать.

9

7

Нашли замену. Тратим больше времени на объяснение, чем на разработку.

23

Начали появлятся задачи на доработки старого функционала. Легко и быстро их правим. Придумали что сделать с опенсорсерами. Отправили их на конференцию за обменом опытом.

10

5

Неделя чистоты. Нового ничего старались не делать - только чинили ошибки.

24

Привлекли студентов. Они пилят функционал в песочнице. Когда все тесты проходят и исправлены все ошибки от анализаторов - только тогда рассматриваем их на включение.

11

10

Много замечаний по выполненным задачам

20

Поймали критические ошибки до выкатки в прод. Поправили. Вроде все хорошо.

12

4

Опять упал прод.

25

Выполнили все задачи за 3 дня. Получили разрешение на разработку внутренних проектов.

13

0

Настолько все фигово, что нужно переписать все с нуля. При попытке реализовать новую задачу что-то обязательно отваливается из старого.

20

Скууучно. Статью написать может про управление качеством?

 

 

На этом абстрактном примере, где топлю за “качественную” команду и критикую “быструю” заметны интересные вещи:

 

  • Хоть “качественная” команда и сделала больше уже на 9 неделю - за первые 9 недель они сделали существенно меньше. В реальности этот срок зависит от множества факторов и может быть как 4 недели, так и 4 года. Ускорение при качественной разработке - игра в долгую.
  • Первые 2 недели “качественная” команда раскачивалась и вообще не выдавала задач. Время на раскачку в реальности так же может сильно отличаться. Если процессы известны, инструментарий знаком, команда уже сработана - на раскачку может уйти и 1 день. А если команда это видит в первый раз - тут может и месяца не хватит. Не каждый бизнес готов ждать подготовки к старту проекта больше месяца.
  • Если у вас не больше 100 задач, какую команду выберите? А у какой команды ФОТ выше?
  • Регрессионная спираль смерти - когда невозможно делать новый функционал, т.к. все силы уходят на правку ошибок в существующем, и каждое исправление привносит новые ошибки - это не миф. Я это видел.
  • То, что команда делает больше задач за неделю, чем на проекте с нуля - тоже чистая правда - при настроенной инфраструктуре, хорошем покрытии тестами и проверках не сложно изменить даже ядро системы. А чаще выходит, что новые хотелки решаются 3мя строчками кода.

 

Будем считать, что следование стандартам прямо влияет на качество кода. И следовать стандартам это правильно.

Как проверять качество

Самоконтроль

Учим стандарты, держим открытой вкладку со стандартами, мониторим изменения. Стараемся писать хорошо сразу, используем шаблоны.При написании кода мы так и поступаем. Вопрос только в том - насколько помним стандарты и сколько держим в голове.

Двойное чтение кода

Когда разработчик знает, что его код прочитает еще кто-то - сразу включается гордость и желание написать код получше. Если автор пропустит ошибку, другой разработчик об этом скажет, если заметит.

Под двойным чтением подразумеваются и парное программирование, и проверка старшим разработчиком, и код-ревью, и аудит различной степени внешности и другие способы, когда код смотрят как минимум 2 пары глаз.

Тесты

При разработке с использованием тестов код сам собой меняется. Становится “тестопригодным” и это благополучно сказывается на качестве.

Тесты и нужны для проверки качества решения.

Автоматические проверки

1С:Автоматизированная проверка конфигурации. Умеет проверять на соответствие кучу стандартов, но делает это долго, а результаты смотреть не удобно

1С:EDT. Встроенная проверка ищет потенциальные ошибки без привязки к стандартам. Проверяет типы, использование переменных и методов. Но воспользоваться этой проверкой можно только в EDT.

Платный плагин для SonarQube. Из плюсов - может почти все. Из минусов - стоит денег.

Опенсорсный плагин для SonarQube. А точнее BSL-LS, который умеет отдавать найденные предупреждения в SonarQube, VSC. Проверок пока немного, но он быстрый и быстроразвиваемый. (Да-да, и эта статья преследует цель привлечь побольше народу к участию в разработке - кодом, идеями, популяризацией)

 

За счет наработок разной степени костыльности результаты проверок АПК, EDT и BSL-LS можно получить в одном едином, красивом и специально предназначенном для этого месте - в SonarQube.

Как статические анализаторы кода улучшают жизнь.

То, что находят - показывают. Нет человеческого фактора с “просмотрел”. При самостоятельном аудите, код-ревью, парном программировании просто пропустить ошибку. Робот не пропустит.

Ловят неочевидные ошибки. Некоторые ошибки поймать почти невозможно. Очепятки, смешивание латиницы и кириллицы, неиспользуемый экспортный метод. Иногда даже смотришь на предупреждение и думаешь “Мдааа, похоже анализатор сломался. Ловит ошибки там, где их нет”. А потом присмотришься, и понимаешь, что это реально ошибка.

Ловят такие нарушения стандартов, которые программист еще не знает. Незнание стандартов не освобождает от ответственности. Стандарты могли изменится, могли появится новые. Помнить актуальную версию невозможно. Робот может.

Беспристрастность. Находит нарушение - показывает. Никаких излишних придирок или снисхождения.

Экономия времени. Не нужно тратить время на поиск этих замечаний. Или перед код-ревью прогнать код анализатором и не тратить время на разбор пойманных ошибок. Или в случае ПР автор сам увидит ошибки и предупреждения и поправит, а не дождется, когда на них укажут другие разработчики.

 

Писать код хорошо - хорошо, а статистические анализаторы упрощают и улучшают этот процесс. Бери и делай!

 

Но есть нюанс. Это не бесплатно. Нужно потратить время на изучение стандартов, на развертывание инструментов, на поддержку и обновление, на изучение инструментов. Это точно окупится?

Кому стоит управлять качеством.

 

Алистэр Коуберн в статье “Каждому проекту своя методология“ привел матрицу сложности проекта.

По вертикали - критичность проекта. Что можно потерять в случае ошибок. Пользователи потеряют в комфорте (Comfort - C), немного денег (Discretionary money - D), много денег (Essential money) или жизнь (Life - L).

По горизонтали - размер команды. Больше людей - больше сложных связей.

Каждый переход проекта вправо или вверх - это резкое усложнение и удорожание проекта и более серьезные процессы и методологии для выполнения.

 

 

Жизнь (L)

L3

L10

L30

L80

L150

L300

L600

Много денег (E)

E3

E10

E30

E80

E150

E300

E600

Немного денег (D)

D3

D10

D30

D80

D150

D300

D600

Комфорта (C)

C3

C10

C30

C80

C150

C300

C600

 

1-4

6-20

20-40

50-100

100-200

200-500

500+

 

Если у вас простой зеленый проект C3 - управление качеством кода не нужно. Будет только мешать и тратить время. Сюда относятся учебные проекты, проекты-игры, вспомогательные инструменты для команды, типа багтрекера.

Желтые проекты D3 и C10 - управлять качеством не помешает, но профит будет минимальный. Проводите двойное чтение кода, гонять анализаторы, экспериментировать с тестами. Это обычно внутренние базы компании - думаю сюда входят 80% фикси.

Оранжевые проекты- разработка небольших коробочных продуктов, автоматизация средних предприятий. Управлять качеством уже рекомендуется. Затраты на это окупаются. Без автоматизированных инструментов можно прожить, но это уже вопрос эффективности команды. Здесь уже стоит разворачивать то, что называют “Промышленными стандартами разработки 1С” - тесты, покрытия, сонар, пайплайны, девопс, гиты.

Красные проекты - разработка больших коробочных продуктов, автоматизация крупных предприятий. Здесь нужны полноценные и серьёзные процессы. Без управление качеством тут нельзя. Обязательные автоматические контроли, тесты, покрытие близкое к 100%, код прочитан дважды, в том числе безопасниками. Тут все серьезно.

Адовые проекты - не уверен, что такие есть на 1С. Если у вас такой проект - напишите как вы там вообще живете.

Советы по отслеживанию качества

Проверяются только модули со снятыми замками

Если замок стоит - это не наша проблема. Если снят - наша. В любом случае на эти ошибки повлиять не можем. На замках бывают не только конфигурации вендора, но и наша же конфигурация при "разветвленной разработке". Когда разрабатываю новую подсистему - в основной конфигурации создаю поставку, новую создаю на ее основе - там все на замках. Снимаю с замков только те объекты, которые правлю - и вижу ошибки только по ним.

Важно не решить все проблемы, а не вносить новые

После первоначального анализа впадаешь в уныние - сотни тыщ ошибок, человекогода на исправление. Правишь, правишь - а прогресс и незаметен. Многие в этот момент бросают автоматические проверки. А нужно лишь проверять новый код и не трогать старый. То же с тестами. Нужно не писать тесты на весь функционал, который и так работает. А писать нужно на новый, который еще не обкатан в проде.

Правило бойскаута

Отдельно выделю - Оставляйте код чище, чем застали. Сделайте чуточку лучше тот код, который трогаете при кодировании текущей задачи.

Нужно четко разделять - это ошибка, тех.долг или ложное срабатывание

Часто тех.долг хочется отметить пропуском. Ошибка в коде остается со всеми негативными свойствами. Но теперь найти ее становится еще сложнее.

Решить все проблемы не получится

Смиритесь. В проекте будет тех. долг. Если же упретесь и выведите в 0, то или маленький проект, либо потратили слишком много драгоценного времени на перфекционизм.

 

Примеры проверок

Некоторые из них выстрелили. Причем в ногу и больно.

Синтаксическая конструкция вида "Если...Тогда...ИначеЕсли..." должна содержать ветвь "Иначе"

Первое мнение о проверке - это перебор. Если нет ветки иначе, значит она не нужна и потоки правильно разносятся по ИначеЕсли. Но в какой-то момент психанул и везде, где в Иначе не должно заходить, расставил ВызватьИсключение “Мы тут не должны были оказаться”. И отвалились тесты. Оказалось что во многих местах, где был уверен, т.к. тщательно разрабатывал и тестировал, со временем что-то поменялось и появились скрытые ошибки.

ТекущаяДата()

Сравнительно недавно появился стандарт на запрет использование метода ТекущаяДата() , а может и давно и я о нем не знал. Впервые о запрете узнал, когда это подсветил сонар (через импорт из АПК). Еще подумал “за 10 лет кодинга ни разу не выстрелило в ногу, фигня, а не стандарт”.

А потом случился гейзен-баг. На моей машине, на контуре разработки, на контуре тестирования работало, а на стейдже нет. Было много перекидываний ответственности, был мат и оскорбления, были потрачены человекодни на поиск причины. В итоге нашли, что дело в часовом поясе (Денис, привет). И нужно было всего лишь не использовать ТекущаяДата().

Превышена длина строки

В стандарте указано, что не рекомендуется превышать 120 символов в строке. На проектах, что проверял на качество - это лидирующая по количеству срабатываний проверка. Каждый переопределяет допустимое количество символов под себя. Кто-то выставляет 180, кто-то 200. Я предпочитаю 140.

Длинные строки сложно читать, они не убираются в веб-редакторах - в гитлабе или в сонаре и их неудобно использовать, если расположить два окна рядом.

Когда начал исправлять длинные строки, часто стал находить там ошибки - в том самом конце, который не видно. Запятая не там, или скобка не туда, или не та переменная. Получившиеся строки стали поддаваться рефакторингу - стал находить дублирования, неоптимальности, возможность использовать существующий метод итп.

Орфография

Если ошибки орфографии встречаются в пользовательском интерфейсе - пользователь сразу считает программу косячной, даже если внутри ошибок нет. Это даже хуже ошибки рантайма.

Ошибки орфографии в коде не так заметны, но приводят к созданию дублирующегося метода или переменной. На форме есть реквизит Номенклатура, а в коде написал Номенкатура = ПолучитьНужнуюПозицию(). И код будет считаться валидным, и будет работать. Но неправильно.

А еще мы огребли от “Палета”и “Паллета”. Однозначно правильного варианта написания нет, как подсказывает гугл. Но в коде путаница приводила к реальным ошибкам. Решили, что раз проверка орфографии ругается на “Палета” и не ругается, на “Паллета”, то правильно так, как не ругается. Соответственно на остальные места будет подсветка. Добавлять в исключения запретили.

Отсутствует комментарий к экспортной процедуре (функции)

К ошибкам это не приводит. Но вот новый инструментарий улучшает качество анализа за счет таких комментариев. EDT умеет определять тип по описанию и выполнять проверки исходя из этого типа. А автогенерилки АПИ умеют собирать документацию по этим комментариям.

Ну и момент документирования тут есть. Все любят хорошую документацию. Писать ее, правда, никто не любит.

В модуле должны быть определены стандартные области

Также к ошибкам не приводит. Но повышает удобство разработки. Не нужно думать где размещать те или иные методы. Уже все придумано. При поиске нужного события - так же понятно где искать.

С развитием кодогенерации стандартные области будут еще более полезны.

Установлено право "Интерактивное удаление"

У вас когда-нибудь бывала ситуация, что кто-нибудь из властьимущих (у кого есть полные права в базе) непосредственно удалял объект из базы и потом там что-то ломалось. Я наверно каждый год трачу несколько дней на расследование таких ошибок и каждый раз это сводится к поиску - какая же роль дала право на удаление.

Использование устаревшей процедуры

Легко пропустить, что любимую процедуру в БСП или в другой библиотеке пометили устаревшей. Пометка устаревшей означает, что в одном из следующих релизов ее удалят. Если заранее не исправить эти места - после обновления можно сильно удивиться.

Недопустимый вызов служебной процедуры или функции другой подсистемы

А это уже об использовании приватных методов. Если публичные методы сперва делают устаревшими, чтобы было время на исправление. То приватные методы могут изменится в любой момент. Ну нет в 1С возможности сделать приватный метод на подсистему. Используете чужие приватные методы? Рискуете, что что-то отвалится в неожиданный момент.

Выводы

  • Определитесь, нужно ли качество на проекте. Точнее качество то точно нужно, но готовы ли за него заплатить временем или деньгами? “Технология очень быстрого результата” (она же фигакфигак и в продакшен, не путать с “Технологией Быстрого Результата”) не так уж и плоха.
  • Правильнее на управление качеством (Continuous Code Inspection если по заумному) смотреть как на инструмент. Инструмент применяется под конкретные задачи, процессы, методологии.
  • С течением времени порог на управление качеством будет снижаться. Верю, что наступит время, когда это будет обязательным инструментов при разработке с низкой ценой использования.
  • Даже если нет нужных проектов, или там это очень сложно развернуть - инвестирование в знания окупятся. При смене платформы, проекта, работы.
  •  

-----------------------------------

 

Как реально управлять качеством на реальных проектах в реале расскажет Олег на INFOSTART EVENT 2019.

 

 

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Evil Beaver 7156 22.07.19 11:26 Сейчас в теме
Охрененно! Аффтар, пешы есчо, хорошо же получается!
BaphoBush; Krio2; Evgenij1990; theelectric; pbabincev; tsmult; PowerBoy; pavlov_dv; gubanoff; Winstoncuk; Labotamy; zeegin; olegtymko; Stepa86; +14 Ответить
2. mrXoxot 2679 22.07.19 11:34 Сейчас в теме
Очень здорово!
Пусть все получиться!
pbabincev; vlad.frost; Labotamy; +3 Ответить
3. artbear 1378 22.07.19 11:56 Сейчас в теме
(0) >Все любят хорошую документация

Опечатка.
4. artbear 1378 22.07.19 12:16 Сейчас в теме
(0) Отличная статья. Радует, что все больше разработчиков/команд обращают внимание на качество своей работы - статический анализ кода, автоматические тесты, CI, DevOps и вот это вот все.
Wilka; pbabincev; pavlov_dv; YPermitin; +4 Ответить
5. artbear 1378 22.07.19 12:24 Сейчас в теме
Проверяются только модули со снятыми замками.
Если замок стоит - это не наша проблема.


Вот тут на самом деле непросто.
Да, такое решение упрощает жизнь, скорость анализа, количество замечаний и т.п.

Но самом деле модули на замке (модули от вендора) - это также проблема "наша" (команды, разработчиков), если эти модули используются в бою.
Ведь если в продуктиве возникнет ошибка в таком модуле, бизнес будет обращаться к нам, как к разработчикам/внедренцам системы, а не к вендору, верно :) ?

Команде проекта нужно решить, нужно ли все-таки учитывать такие модули или нет.

Для сложных систем для наших клиентов я советую следующее:
- учитывать модули на замке, а не отбрасывать
- анализировать только новые замечания с уровнем (критичные, блокирующие, важные) - как в статье в соседней рекомендации и написано.
- вдруг все-таки вендор серьезно ошибся, ведь и такое бывает.
Krio2; Светлый ум; Redokov; nvv1970; Winstoncuk; zeegin; +6 Ответить
6. Scorpion4eg 390 22.07.19 14:43 Сейчас в теме
Жаль что никто кроме EDT напрямую с внешними обработками не работает.
АПК от слова совсем. Sonar более менее пережевывает... А ведь во внешних печатных формах можно столько всего на плохокодить.
7. olegtymko 725 22.07.19 14:45 Сейчас в теме
(6) Паковать обработки / отчеты в cf/cfe и прогонять в EDT, АПК и заливать все в SonarQube. Тогда весь плохокод будет на лицо.
Scorpion4eg; +1 Ответить
9. artbear 1378 22.07.19 15:51 Сейчас в теме
(7) Костыль ИМХО. но ради качества на что не пойдешь :)
Scorpion4eg; +1 Ответить
8. artbear 1378 22.07.19 15:50 Сейчас в теме
(6) Почему "никто" ? наш платный плагин для SonarQube (от Пули) прекрасно работает.

и в VSC можно немедленно получать результаты, если кодируешь код в VSC.

давно проверяю инструмент Ванесса-АДД, построенный как раз на внешних обработках.
10. theshadowco 171 22.07.19 16:20 Сейчас в теме
(8) токо в формате edt увы работает неахти
Жолтокнижниг; Labotamy; +2 Ответить
11. Scorpion4eg 390 22.07.19 16:42 Сейчас в теме
(8) Не спорю, классно работает! Но когда мы его тестировали была проблема с "Возможно неиспользуемая процедура" для обработчиков элементов формы. Решили уже?
12. Fox-trot 130 22.07.19 17:33 Сейчас в теме
(11) достаточно добавить операнд "Экспорт", хотя костыль конечно
13. artbear 1378 22.07.19 17:51 Сейчас в теме
(11) Да, эта проблема решена в конце прошлого года или начале этого
Scorpion4eg; +1 Ответить
14. vlad.frost 187 22.07.19 23:49 Сейчас в теме
Правило бойскаута
Отдельно выделю - Оставляйте код чище, чем застали. Сделайте чуточку лучше тот код, который трогаете при кодировании текущей задачи.


SonarQube, кстати, позволяет этому правилу следовать с чуть меньшими рисками:
во-первых, можно заранее, перед выполнением задачи, посмотреть, какие есть в коде нарушения стандартов;
во-вторых, после всех правок убедиться, что все нарушения-таки исправлены.
artbear; Stepa86; +2 Ответить
15. user614660_dajigin 23.07.19 06:47 Сейчас в теме
Все таки есть сомнения по поводу "Иначе". Очень много конструкций таких типов:

Если КакойТоПризнак = ПервоеЗначение Тогда
ВыполнитьДополнительныеДействия1;
ИначеЕсли КакойТоПризнак = ВтороеЗначение Тогда
ВыполнитьДополнительныеДействия2;
КонецЕсли;

...Продолжаем выполнение по плану: действия, которые должны выполняться для ПервоеЗначение, ВтороеЗначение и все последующие....

Что в этом случае? Пустой "Иначе" делать? Какой в нем смысл? Исключения выкидывать нельзя, т.к. "непопадание" в условия это не ошибка.
16. Labotamy 23.07.19 06:52 Сейчас в теме
(15)В этих случаях диагностика ничего вам не скажет. Диагностика срабатывает на Если ИначеЕсли без Иначе.
17. user614660_dajigin 23.07.19 06:53 Сейчас в теме
Уже понял косяк)) Исправил вопрос))
18. Labotamy 23.07.19 06:58 Сейчас в теме
(17)Посмотрите комментарии к статье Олега. Там весёлый холиварчик на эту тему вышел.
olegtymko; Stepa86; +2 Ответить
19. user614660_dajigin 23.07.19 07:07 Сейчас в теме
20. artbear 1378 23.07.19 12:05 Сейчас в теме
(15) Да, эта диагностика холиварна и дает много срабатываний.

Есть важный принцип статического анализа - количество ложных срабатываний должно быть минимальным или их вообще не должно быть.

Если ложных очень много, это создает шум, мешающий команде разработки.

Поэтому мы для своего платного плагина (от Пули) все еще думаем над необходимостью введения этого правила.

Создавать правило, которое, скорее всего, чаще будет отключено, не хочется.
21. olegtymko 725 24.07.19 03:17 Сейчас в теме
(20) Опять же это очень холиварная тема.
На стадии разработки эта проверка очень много нервов и жизней может спасти. Но и в проде поможет отловить определенную массу косяков.
К примеру:
Дан какой-нибудь произвольный обмен с партнером через FTP в их кастомном формате. В коде есть условие, которое определяет что делать с документом
ДД = Новый ДвоичныеДанные(); // какие-то двоичные данные
ВидФайла = "ARRAIV"; // вид файла, который прочитали из именя файла

Если ВидФайла = "PICK" Тогда
	ЗагрузитьКакРасходнуюНакладную(ДД);
ИначеЕсли ВидФайла = "ORDER" Тогда
	ЗагрузитьКакЗаказ(ДД);
ИначеЕсли Видфайла = "STOCK" Тогда
	ЗагрузитьКакРеестрОстатков(ДД);
КонецЕсли;
Показать


Если не сообщить о виде файла, что он не поддерживается, то проблема может жить очень долго и никто об этом не узнает. В этом случае можно код допилить так:
Если ВидФайла = "PICK" Тогда
	ЗагрузитьКакРасходнуюНакладную(ДД);
ИначеЕсли ВидФайла = "ORDER" Тогда
	ЗагрузитьКакЗаказ(ДД);
ИначеЕсли Видфайла = "STOCK" Тогда
	ЗагрузитьКакРеестрОстатков(ДД);
Иначе
	// или исключение (при условии что выше по уровню стоит попытка и отлавливает все исключения)
	ВызватьИсключение(СтрШаблон("Вид файла %1 не поддерживается"));
	// или соообщение в какой нибудь лог
	Логирование.Ошибка("Обмен.СамыйЛучшийПарнер", СтрШаблон("Вид файла %1 не поддерживается"));
КонецЕсли;
Показать


Да, ложные срабатывания бывают. Когда в алгоритме понятно, что если условия не выполнились то и делать ничего не надо. Но есть способ отключить проверку в определенном блоке кода.
24. Scorpion4eg 390 03.11.19 14:25 Сейчас в теме
(20) Никогда не понимал почему холиварная. Для себя давно завел правило: не знаешь что писать в иначе, пишу ВызватьИсключение "Неожиданный вариант".
Исключение - обработка оповещения в формах
kwazi; olegtymko; Labotamy; +3 Ответить
26. Ndochp 103 13.11.19 11:55 Сейчас в теме
(24) Ну вот смотри, у тебя есть что-то, что работает с десятком видов документов и в 8 в реквизите то, что тебе надо, в девятом префикс "ДД.", в десятом - суффикс ".Ик"
вот ты и пишешь:

Если ВидФайла = "PICK" Тогда
    ПараметрСтрокой = Сред(ПараметрСтрокой, 4);
ИначеЕсли ВидФайла = "ORDER" Тогда
    ПараметрСтрокой = Лев(ПараметрСтрокой, СТрДлина(ПараметрСтрокой) - 3);
КонецЕсли;
27. Scorpion4eg 390 13.11.19 15:14 Сейчас в теме
(26) Это понятно. Но что ты будешь делать, если ВНЕЗАПНО (а это всегда внезапно) придет новый ВидФайла? Сколько времени потребуется на поиск ошибки?

А так добавляешь строку:
Иначе
ВызватьИсключение "Неожиданное значение переменной ВидФайла" + ВидФайла;
КонецЕсли;
olegtymko; Labotamy; +2 Ответить
28. Ndochp 103 13.11.19 21:22 Сейчас в теме
(27)У меня для 8 видов все хорошо, для двух - проблемы. Скорее всего с одиннадцатым все будет тоже хорошо. А если не будет, то я об этом не забуду.
Или вы предлагаете сделать еще один блок с видами файла 1..8? А если я точно знаю, что у меня 2 исключения, но не уверен, сколько основных?
Типа уникального перемещения между складами - единственный документ с двумя складами. Вы знаете все документы в конфигурации с реквизитом "Склад"?
29. Labotamy 14.11.19 08:42 Сейчас в теме
(28) А все коллеги знают и помнят эти "нюансы"? И те кто будут после, тоже?
30. Ndochp 103 18.11.19 15:31 Сейчас в теме
А куда деваться? или предлагаете перед каждым использованием реквизита "Склад" в экспортных процедурах модулей складской подсистемы делать проверку на тип документа и выбрасывать исключение для новых типов?
22. kalimehtar 22 29.07.19 08:12 Сейчас в теме
(15)
Пустой "Иначе" делать? Какой в нем смысл?


Смысл в том, что ты явно указал любому читающему, что ветка Иначе пропущена не случайно. Также как в проверках Си "while (c = getchar()) " считается ошибкой, а "while ((c = getchar()))" нормальный код. Вторая пара скобок указывает, что присваивание там осознанно, а не перепутали со сравнением "==".
25. Ndochp 103 13.11.19 11:49 Сейчас в теме
(22) Только АФАИР влетаешь в диагностику " в блоке нет кода"
23. Tavalik 2614 29.07.19 16:36 Сейчас в теме
31. FrancuzbyGmailcom 29.11.19 11:28 Сейчас в теме
Кажется это "содрано" из книги "Совершенный код" ;)
32. Labotamy 29.11.19 15:02 Сейчас в теме
33. Stepa86 1442 29.11.19 15:03 Сейчас в теме
(32) Про стандарты 1С у Макконнелла все же лучше написано
34. mikukrnet 177 16.04.21 14:56 Сейчас в теме
"Синтаксическая конструкция вида "Если...Тогда...ИначеЕсли..." должна содержать ветвь "Иначе""

А можно кейс, где это выстрелило?
35. olegtymko 725 19.04.21 08:47 Сейчас в теме
(34) При переходе на ставку НДС20
36. biimmap 308 24.04.21 17:44 Сейчас в теме
Хорошая статья. тоже ЗА повышение качества кода.

Единственное с чем не соглашусь - это с комментированием старого кода. НА мой взгляд это обязательно нужно делать!
Потом при обновлении как понять, что там было? Почему так написали? Или даже просто требуется доработать то же самое место!

И вот насчет Если ... Иначе... Непонятно почему всегда должна быть ветка иначе? куча моментов когда часть кода выполняется только в определенных сценариях. Здесь неявное Иначе... Т.е. Иначе выполняем код написанный ниже.

Что касается автотестов... у меня обычно 2 кейса в работе:
1. Сотрудник соблюдает все стандарты и проверять там нечего, в том числе мой собственный код.
2. Сотрудник плевать хотел на стандарты, оно и так работает. Поэтому не понимаю зачем это надо за дверями коробочных решений.

всякие опечатки вижу на код ревью, т.к. я их терпеть не могу! И кстати в типовых конфигурациях есть эти проверки... Но опечаток валом!
37. kalyaka 729 25.04.21 16:06 Сейчас в теме
(36)
Единственное с чем не соглашусь - это с комментированием старого кода. НА мой взгляд это обязательно нужно делать!
Остатки старого кода имеют следующие негативные последствия: увеличивают объем мусора в коде, не позволяют делать полноценный рефакторинг.

Почему старый код - мусор? Да потому что новое решение может быть никак не связано со старым, более плохим. Даже если старое решение было хорошим, но компромисным, то новое - это новый компромис. И еще хороший код с хорошими абстракциями может сам себя документировать. Прежний код и комментарии к нему и тем более к новому коду - это избыточная когнитивная нагрузка. Это как раз тот показатель, который нужно снижать, а не повышать.

Почему мешает рефакторингу? Потому что рефакторинг ведет к изменению структуры кода, стилю написания и многим вещам таким, что может вообще не напоминать прежний код. В таком случае прежний код комментируется целиком и продолжает "висеть" мертвым грузом в тексте как разросшийся сорняк. Код при этом начинает напоминать лес, где за зеленью может проклевываться реально работающий код.
38. biimmap 308 25.04.21 16:17 Сейчас в теме
(37) здесь вопрос в том, как его комментируют. Есть люди. которые комментируют процедуру целиком или запрос целиком и пишут новый.... Вот в этой ситуации это реально мусор!

Мой код, если меняю типовой выглядит точечно, пару строк старого, пару строк нового.

Рефакторинг делают обычно в самописных решениях. Или в тиражных! Здесь полностью согласен, не имеет значения что было написано раньше, для этого есть история хранилища.

Поэтому ещё раз сделаю акцент на доработке ТИПОВЫХ модулей и объектов. Конкретно я занимаюсь ЗУПом. Всё что НЕ типовое, никаких комментариев быть не должно, здесь согласен. Но в типовых без знания того "как было до" будет невозможно выполнить обновление, не вникая в суть задачи!
39. kalyaka 729 25.04.21 20:34 Сейчас в теме
(38) в таком случае не будут столь категоричен, однако чистоты коду даже точечные комментарии не добавляют. Когда конфигурация на поставке, то различия можно эффективно находить через трехстороннее сравнение: основная конфигурация, старая конфигурация поставщика и новая. При таком сравнении можно решать точечные конфликты дважды измененных процедур. Если обновления делать часто и они не фундаментальны, то конфликтов будет минимальное количество.

Возможно для типовых будет лучшим решением вести доработки через расширения.
40. biimmap 308 25.04.21 22:41 Сейчас в теме
(39) Я ж описал в каком случае нужны маркеры и старый код. Только при обновлении. В остальных случаях да используем сравнение с чем-нибудь (либо типовая поставка, либо предыдущая версия конфигурации в хранилище).

Расширения это срань полная! Вот кто их придумал, тот пусть и использует. И вот в них как раз отсутствует возможность сравнить с чем-нибудь...
Оставьте свое сообщение

См. также

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С Промо

Математика и алгоритмы Практика программирования v8 v8::blocking 1cv8.cf Бесплатно (free)

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    44441    ids79    45    

С конфигуратора на EDT. Привычки, которые придется поменять

EDT Языки и среды v8 1cv8.cf Бесплатно (free)

Решил перейти на EDT, чтобы повысить эффективность разработки? А теперь приостановись и выдохни! Я расскажу сейчас о том, из-за чего многие новички в EDT (будучи матёрыми кодерами в конфигураторе) воспринимают встречу с новшествами так, будто их с велосипеда пересадили за штурвал Боинга.

16.09.2021    3984    stas_ganiev    16    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

Производительность и оптимизация (HighLoad) Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

Расскажем про инструменты, рассмотрим планы запросов, увидим, как отслеживать и бороться с проблемами производительности на боевой базе.

07.09.2021    3548    ivanov660    22    

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета v8 v8::DataMining Бесплатно (free)

Подробный разбор, с примером использования, встроенного механизма кластеризации 1С.

31.08.2021    1856    dusha0020    8    

Как работает серверный вызов в 1С Промо

Математика и алгоритмы v8::УФ Бесплатно (free)

Клиент-серверная архитектура заложена в платформе изначально — со времен «1С:Предприятие 8.0». Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере. Всё изменилось с выходом платформы «1С:Предприятие 8.2», когда появился тонкий клиент. Теперь на клиенте доступен один функционал, на сервере — другой. Клиент и сервер «общаются» между собой с помощью серверного вызова. Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.

18.11.2017    66538    pahich    83    

1C: EDT: фиксим баги доработанной и устаревшей конфигурации УТ

EDT v8 8.3.14 УТ11 Россия УУ Бесплатно (free)

В этом году у меня появилась возможность использовать 1С: EDT весь рабочий день. В работе конфигурация УТ 11.1, прилично доработанная. Целиком перейти на актуальную конфигурацию УТ 11.4 проблематично, поэтому переходим кусочками в ходе текущих работ.

13.08.2021    1083    pa240775    3    

Практическое применение операции копирования массива

Математика и алгоритмы v8 Бесплатно (free)

Решение задачи https://projecteuler.net/problem=250 из Project Euler средствами 1C.

02.08.2021    902    scientes    2    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

Производительность и оптимизация (HighLoad) Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    8885    ivanov660    77    

Будни автоматизации или "мне нужна программка для 3D упаковки" Промо

Практика программирования Математика и алгоритмы Оптовая торговля Оптовая торговля v8 1cv8.cf УУ Бесплатно (free)

Автоматизация отечественных предприятий, которой приходиться заниматься, это нужная и высокооплачиваемая, но довольно нервная работа. Выручает юмор. Например, при общении с требовательным клиентом можно вспомнить анекдот: "Держась руками за стену, на ногах еле стоит мужик. К нему пристает ребенок: "Ну, папа, пожалуйста, сделай мне кораблик!", папа отвечает: "Ага! - Сейчас все брошу и пойду делать тебе кораблик!". Про один такой сделанный для клиента "кораблик" и хочется рассказать. Надеюсь, совместное погружение в теплое ламповое (то есть клиентоориентированное) программирование доставит Вам положительные эмоции, да и задача попалась интересная. Поплыли?

24.03.2014    46648    ildarovich    116    

Запрос всей номенклатуры с характеристиками

Математика и алгоритмы v8 ERP2 УТ11 КА2 Бесплатно (free)

Сравнение различных вариантов запроса всей номенклатуры с характеристиками (УТ11.4, КА 2.4, ERP 2.4).

1 стартмани

30.07.2021    828    Daemonold    3    

Антипаттерны программирования в 1С

Практика программирования Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про плохой стиль программирования и рассмотрим 17 часто встречающихся антипаттернов.

19.07.2021    9892    ivanov660    121    

Распределенные алгоритмы РИБ 1С

Распределенная БД (УРИБ, УРБД) Математика и алгоритмы v8 Бесплатно (free)

Небольшое исследование на тему применимости классических распределённых алгоритмов репликации и синхронизации данных между узлами обмена РИБ 1С.

02.07.2021    1218    zhichkin    1    

Приемы обработки больших данных в 1С Промо

Универсальные обработки Математика и алгоритмы Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Рассказ об эффективных приемах организации обработок больших объемов данных на платформе 1С

07.08.2015    71095    tormozit    29    

Принципы разветвленной доработки конфигурации, находящейся на поддержке, и ее расширений. Объединение веток разработки

EDT Git (GitHub, GitLab, BitBucket) v8 Бесплатно (free)

Для чего нужно ветвление доработки типовой конфигурации? Как быть с расширениями? Как все это потом связать в одно целое?

02.06.2021    1777    Алексей Воробьев    2    

Чек-листы для проведения Code Review

Рефакторинг и качество кода v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В данной статье будут приведены два чек-листа (основной и для проверки архитектурных решений). По данным чек-листам программист любой квалификации может проверить свой код и код других разработчиков.

17.05.2021    7918    Alexsandr_Retunskiy    99    

Чем воспользоваться для распознавания котиков в 1С?

Практика программирования Математика и алгоритмы v8 Бесплатно (free)

На митапе по инструментам для расширения возможностей 1С выступил Олег Филиппов. Он сравнил подходы Native API, COM, Docker и Serverless, и рассказал, как упростить использование в 1С алгоритмов, реализованных на других языках, с помощью облачной технологии «Функция как сервис».

12.04.2021    3374    comol    10    

XDTO - это просто Промо

Математика и алгоритмы v8 1cv8.cf Бесплатно (free)

С появлением платформы 8.1 фирма “1С” представила механизм, носящий интригующее название XML Data Transfer Objects или, если коротко - XDTO. По традиции, документирование механизма составлял тот, кто хорошо разбирался в вопросе, а стало быть опустил “и так понятные” с его точки зрения моменты. Целью данной статьи (или цикла статей, как получится) стало желание поделиться накопленным опытом. Мне кажется, многие неочевидные вещи в механизме XDTO необходимо осветить получше.

24.12.2012    329273    Evil Beaver    184    

Рекурсия для начинающих

Математика и алгоритмы Практика программирования v8 Бесплатно (free)

Рассмотрен подход к пониманию рекурсий. Приведены примеры из реальной практики.

10.02.2021    2356    szv    5    

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Рефакторинг и качество кода Закрытие периода v8 УПП1 БУ УУ Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    3453    RPGrigorev    19    

Реальный кейс по внедрению CodeReview

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

В различных источниках присутствует достаточно много теоретической информации о CodeReview, но вот описания реальных внедрений CodeReview встречаются редко. В данной статье будет минимум теоретической информации, а будет описан процесс внедрения CodeReview (сложности, задачи и результаты).

20.01.2021    1888    Alexsandr_Retunskiy    3    

1C:Enterprise Development tools (EDT) или кодим в Eclipse Промо

EDT v8 Бесплатно (free)

Как и выход мобильной платформы был для оооочень большого числа разработчиком открытием, так и я уверен, что и о новом конфигураторе - тоже мало кто слышал. Поэтому давайте попробуем пробежаться по новому конфигуратору. (Много больших картинок)

11.04.2015    79516    DitriX    297    

Практика применения DevOps. Работа с SonarQube

DevOps SonarQube v8 1cv8.cf Бесплатно (free)

Во второй части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Виталий Подымников – он рассказал про процесс проверки качества кода и использование SonarQube для работы с ним.

07.12.2020    7364    arcius_7012    11    

Операторы перехода в программном коде: использовать или нет?

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    3451    ivanov660    22    

Чистый кот (Clean cat)

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    1884    vasilev2015    25    

Самоучитель языка запросов 1С. Промо

Практика программирования Решение задач на 1С:Специалист Математика и алгоритмы v8 v8::Запросы Бесплатно (free)

Сервис для изучения запросов 1С: "Консоль изучения запросов 1С:Предприятие 8". Теперь и с конструктором запросов!

07.05.2013    114935    bpc222    327    

Доработайте это "немедленно", или как уменьшить доработки конфигурации

Рефакторинг и качество кода v8 Россия Бесплатно (free)

Доработки конфигурации - необходимое зло. Автор предлагает несколько простых подходов и приемов, позволяющих хотя бы немного, но оптимизировать объем доработок конфигурации, упростить их, и облегчить дальнейшие доработки и обновления конфигурации. Все примеры и подходы взяты автором из реальной жизни и основаны на собственных наблюдениях.

25.09.2020    4165    Богатырев Артур    24    

Метод борьбы с большим количеством комментариев в коде

Практика программирования Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Решил поделиться нашим способом борьбы с сильно закомментированным кодом.

08.09.2020    1532    tambu    9    

1С:EDT. Куда пинать, чтобы полетело?

EDT v8 УНФ Россия Бесплатно (free)

Работал в 1С Конфигуратор и решил перейти на 1С EDT. Не получилось сразу. Потребовалась модификация компьютера.

19.08.2020    6928    pa240775    35    

Решение транспортной задачи запросом Промо

Математика и алгоритмы v8 Бесплатно (free)

Списание по двум последовательностям партий запросом (без программной обработки)

1 стартмани

30.04.2014    36039    bforce    22    

Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

Рефакторинг и качество кода v8 Бесплатно (free)

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    4067    kozlov.alians    1    

Unit-тесты с помощью 1C:Enterprise Development Tools

EDT v8 Бесплатно (free)

Концепция TDD требует перестроения подходов к разработке и наличия инструментов для запуска Unit-тестов. Про написание плагина для EDT, который содержит в себе инструменты написания, анализа результатов и запуска Unit-тестов для конфигураций 1С на конференции Infostart Event 2019 Inception рассказал ведущий специалист по внедрению компании 1С-Рарус Александр Капралов.

11.06.2020    5742    doublesun    8    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    5213    grumagargler    14    

Парсер запросов 1С. Часть 1: Введение, разбор математических выражений Промо

Математика и алгоритмы v8 Бесплатно (free)

Рано или поздно становится скучно решать типичные задачи, для которых придумана 1С. Голова пухнет от бухгалтерских терминов и очередных "хотелок" пользователей. Именно в такие моменты хочется гордо поднять голову, воскликнуть "Но я же программист!" и заняться чем-то интересным. В цикле статей я постараюсь доступно описать, как устроены парсеры в целом и на примере парсера языка запросов 1С. Требования к навыкам читающего: основы языка 1С, основы алгоритмизации.

1 стартмани

04.12.2013    31258    juntatalor    49    

Enterprise Development Tools, версия 2020.2 для мобильной разработки. Бег по граблям (серия публикаций от чайника для чайников)

EDT v8::Mobile 1cv8.cf Бесплатно (free)

Небольшие советы, которые сберегут время при работе с Enterprise Development Tools, версия 2020.2.

10.04.2020    5330    capitan    8    

Партионный учет по двум количественным показателям

Математика и алгоритмы Учет ТМЦ v8 1cv8.cf Оптовая торговля, дистрибуция, логистика Россия УУ Бесплатно (free)

Особенности учета партионной системы при наличии двух количественных показателей.

26.03.2020    4441    lastcontra    5    

Рефакторинг в редакторе модулей

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье НЕ рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    4663    pparshin    5    

Сервис для изучения методов платформы 1С:Предприятие 8. Бесплатно! Промо

Практика программирования Решение задач на 1С:Специалист Математика и алгоритмы v8 Бесплатно (free)

Бесплатный ON-Line сервис изучения методов платформы 1С:Предприятие 8. Подготовка к аттестации 1С:Специалист on-line! Тестовые задания по различным видам учета! Подсказки для оптимального решения!

27.06.2013    51219    bpc222    53    

Качество кода: Поведенческие паттерны проектирования

Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    9138    ivanov660    0    

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода v8::Запросы 1cv8.cf Бесплатно (free)

В текущей публикации я предлагаю вам несколько простых примеров с решениями, в которых будет представлено решение "единым запросом", без использования запросов в цикле.

02.03.2020    9228    aximo    55    

Получение значений всех полей в иерархии структуры отчета

Практика программирования Математика и алгоритмы v8::СКД Россия Бесплатно (free)

При обработке расшифровки данных в отчете (да и не только отчете), основанном на СКД, может потребоваться получить значения всех полей, находящихся в текущей группировке и её родителях. Представляю вашему вниманию алгоритм, выполняющий эту задачу. Как говорится, "просто оставлю это здесь".

28.02.2020    2516    real_MaxA    1    

v8: Концепция минимального изменения конфигурации для легкого обновления Промо

Математика и алгоритмы v8 1cv8.cf Бесплатно (free)

"Лучше день потерять потом за пять минут долететь" ((с) "Крылья, ноги и хвосты") или как сделать так чтобы обновление конфигурации проходило с минимальными трудозатратами.

28.01.2013    38737    MarSeN    57    

Treemapping — способ визуализации данных древовидной структуры. Карта-схема дерева

Математика и алгоритмы Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

Предлагается ознакомиться с редким способом графического представления иерархических данных. Приводится алгоритм формирования и пример реализации.

18.02.2020    6424    randomus    20    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 03

EDT v8 Бесплатно (free)

Групповая разработка в EDT.

21.01.2020    5278    YuriYuriev    3    

EDT + УТ 11.4 + БП 3.0 + Расширения. Часть 02

EDT v8 Бесплатно (free)

Продолжение "путевых заметок" про EDT...

09.01.2020    7491    YuriYuriev    32    

Пример выбора несколько обработчиков событий записи объекта для решения одной задачи Промо

Математика и алгоритмы v8 Бесплатно (free)

Данная публикация предназначена для начинающих разработчиков и является продолжением статьи "Обработчики событий при записи объектов. Зачем и что за чем?" (ссылка далее). Содержит пример использования несколько обработчиков событий для решения одной задачи и объясняется почему выбраны именно они.

27.09.2012    196914    AlbinaAAA    65    

Как управлять качеством кода 1С, используя платформу SonarQube

Рефакторинг и качество кода SonarQube Бесплатно (free)

При быстром росте функциональности проводить визуальный Code-Review для обнаружения некачественного кода проблематично. О том, как автоматизировать проверку качества кода 1С с помощью платформы SonarQube на конференции Infostart Event 2019 Inception рассказал ведущий разработчик компании «Командор» Олег Тымко.

30.12.2019    11418    olegtymko    10    

[После]Новогодние задачи

Практика программирования Математика и алгоритмы v8 Бесплатно (free)

Совсем немного времени осталось до того момента, когда отзвучат куранты, шампанское будет выпито, мандарины съедены, и даже оливье закончится. Возникнет вопрос: чем бы занять неожиданно появившееся свободное время?

30.12.2019    3389    Alxby    23    

EDT + УТ 11.4 + БП 3.0 + Расширения. ЧАСТЬ 01

EDT v8 Бесплатно (free)

...продолжаем мучить(ся с) EDT

28.12.2019    7734    YuriYuriev    8    

Альтернативные способы работы с XML. Часть 2: Введение в xPath или запросы к XML Промо

Обмен через XML Математика и алгоритмы v8 1cv8.cf Бесплатно (free)

В предыдущей статье "Введение в DOM или объектная модель документа" было описано понятие объектной модели документа (DOM), раскрыты плюсы и минусы использования модели при разборе файлов XML, приведено сравнение с построчным последовательным разбором. Были представлены варианты выборки данных с помощью объекта 1С ДокументDOM. Теперь настало время познакомить читателей с самым, на мой взгляд, интересным способом извлечения данных из XML - при помощи языка запросов xPath.

09.08.2012    43229    1cspecialist    13    

EDT 1.16. Первые 20 часов работы

EDT v8 Россия Бесплатно (free)

Первое знакомство с 1C:Enterprise Development Tools, версия 1.16.0.363.

25.12.2019    12406    YuriYuriev    13    

Стабильность превыше всего

Рефакторинг и качество кода v8 Бесплатно (free)

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    10216    YPermitin    40    

Оценка скорости кода. Сложность алгоритма

Практика программирования Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    6679    m-rv    12    

Регистры бухгалтерии. Общая информация

Практика программирования Математика и алгоритмы v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    45838    YPermitin    25