В этом разделе попробую продать идею, что правильно писать код — правильно. И как это — правильно.
Нужно как-то измерить внутреннее качество кода.
Внутреннее, потому что конечный пользователь этого качества не видит. Это первая холиварная часть — зачем что-то улучшать, что не видит пользователь?
Качество. А что такое качество кода? Каждый разработчик понимает под этим что-то свое. Это вторая холиварная часть. Особенно когда речь заходит о затратах на поддержание этого качества.
Измерить. Если хотим этим управлять, это нужно мерить. И тут тоже без холивара не обходится. Одним кажется важной одна метрика, другим наоборот.
Сплошные холивары.
Единственный работающий подход для разрубания холиваров — зафиксировать вариант законодательно. Кто соблюдает законы — те молодцы, кто не соблюдает — получает штраф и начинает соблюдать.
Законы при разработке в 1С это «Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8»
Негласные правила в определении качества: Когда программист смотрит на такой код — вырывается “Ах, что же это такое???”, только матерно. Сокращенно ЧБ. Если код постоянно вызывает ЧБ, то тут нужен стандарт, чтобы так больше не писали. Этот подход используется при добавлении диагностик в https://github.com/1c-syntax/bsl-language-server/issues
Уровни стандартов
- Промышленные стандарты (из других языков). На них наткнетесь в интернетах и в книгах. Люто рекомендую прочитать Совершенный код и Чистый код
- Стандарты 1С https://its.1c.ru/db/v8std. Доступ открыт и бесплатен.
- Внутренние стандарты Компании. Сюда обычно входят правила префиксации. Правила доработки конфигурации на поддержке для упрощения обновления. Правила идентификации изменений — от любимых // Здесь был Уася по задаче 000666 до правила текста оформления коммита.
- Личное. Я это называю почерком, когда автора кода легко определить по стилю, но при этом негатива это не вызывает. У меня это “дышащий стиль” с кучей пробелов и отступов, правилами именования, похожими на венгерскую нотацию и другими шаблонами.
Чем выше уровень, тем ближе к разработчику. Но если уровни конфликтуют между собой — нужно быть уверенным на 146% в целесообразности. Нужно четко понимать что стоит за нижестоящим стандартом и почему переопределен.
Пример хорошего переопределения — префиксация имен у объектов при доработке конфигурации на поддержке. Стандарт 1С запрещает спец. префиксы. Но префиксы помогают при определении принадлежности объекта.
Пример плохого переопределения — идентификаторы изменений прям в коде с сохранением старого кода.
Почему стоит соблюдать стандарты?
Стандарт это ответ на решенную проблему
Многие стандарты написаны после того, как было потрачено много человекочасов на решение проблемы. Эти правила — превентивные меры по борьбе с ошибками. Придерживаться стандарта стоит минуты, ошибка из-за нарушенного стандарта может превратится в недели потраченного времени. Не писать код, который приводит к ошибке — это и есть качество.
Все стандарты по запросам появились после анализа долгих запросов. Причем долгими в проде.
Экономия мыслетоплива
При разработке постоянно возникают ситуации, когда сидишь над простым куском кода и пытаешся спрогнозировать последствия. Придумываешь абстрактные ситуации, или пропускаешь поведение, которое выстрелит в ногу позже. Стандарт позволяет не помнить всю ситуацию — почему так писать хорошо, а так почему нельзя. Писать нужно так. Точка. Никакой лишней информации. Это позволяет тратить запасы мыслей в других местах.
Удешевление рабочей силы
Вчерашний стажер, который с трудом пишет код и вчерашний стажер, который с трудом пишет код и соблюдает стандарты — это разные уровни. На самом деле сложно писать плохой код соблюдая стандарты. Тут без таланта не обойтись. А раз младший пишет не плохой код, то доверяем задачи посложнее. На сложных задачах растут. А значит эта задача снимается с дорогих разработчиков. Для этого даже термин придумали — стандартизация.
Унификация стиля
Соблюдение стандартов приводит код к единому стилю. А у единого стиля есть одна особенность — разработчик перестает различать где его код, а где коллеги. Разработчик одинаково хорошо начинает разбираться и в своем и в чужом коде. А это приводит к резкому уменьшению желания переписать все с нуля. Меньше энергии тратится на негатив, больше на креатив.
Приоритизация
Что разработчик берет в работу в первую очередь? Важное или срочное? Разработчик берет в первую очередь понятное! (ц) Максим Дорофеев.
Чем качественный код, тем проще разработчикам за него будет взяться, тем меньше будут прокрастинировать над важными или срочными задачами.
Сопровождаемость
Качественный код проще поддерживать и дорабатывать. Чем хуже написан код, тем сложнее найти ошибку или доработать под новые требования. А желание переписать все с нуля возрастает. И наоборот, в качественном коде ошибки становятся очевидными. Можно даже сказать, что при качественной разработке потраченное время переносится с сопровождения на создание по выгодному курсу — качественный код на этапе создания тратит дополнительные минуты, экономя часы и дни поддержки.
Ускорение разработки
Предыдущие пункты складываются в этот. Писать качественно и по стандартам серьезно ускоряет разработку — за счет уменьшения времени на отладку, уменьшения времени на прилетевшие ошибки, на разбирательство в чужом коде, на разбирательство в своем коде…
Абстрактный придуманный пример в работе двух команд. Быстрой — которые фигачат код, игнорируя тех. долг, и качественной — у которой качество превыше всего.
На этом абстрактном примере, где топлю за “качественную” команду и критикую “быструю” заметны интересные вещи:
- Хоть “качественная” команда и сделала больше уже на 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).
По горизонтали — размер команды. Больше людей — больше сложных связей.
Каждый переход проекта вправо или вверх — это резкое усложнение и удорожание проекта и более серьезные процессы и методологии для выполнения.
Если у вас простой зеленый проект C3
управление качеством кода не нужно. Будет только мешать и тратить время. Сюда относятся учебные проекты, проекты-игры, вспомогательные инструменты для команды, типа багтрекера.
Желтые проекты D3 и C10
управлять качеством не помешает, но профит будет минимальный. Проводите двойное чтение кода, гонять анализаторы, экспериментировать с тестами. Это обычно внутренние базы компании — думаю сюда входят 80% фикси.
Оранжевые проекты
разработка небольших коробочных продуктов, автоматизация средних предприятий. Управлять качеством уже рекомендуется. Затраты на это окупаются. Без автоматизированных инструментов можно прожить, но это уже вопрос эффективности команды. Здесь уже стоит разворачивать то, что называют “Промышленными стандартами разработки 1С” — тесты, покрытия, сонар, пайплайны, девопс, гиты.
Красные проекты
разработка больших коробочных продуктов, автоматизация крупных предприятий. Здесь нужны полноценные и серьёзные процессы. Без управление качеством тут нельзя. Обязательные автоматические контроли, тесты, покрытие близкое к 100%, код прочитан дважды, в том числе безопасниками. Тут все серьезно.
Адовые проекты
не уверен, что такие есть на 1С. Если у вас такой проект — напишите, как вы там вообще живете.
Советы по отслеживанию качества
Проверяются только модули со снятыми замками
Если замок стоит — это не наша проблема. Если снят — наша. В любом случае на эти ошибки повлиять не можем. На замках бывают не только конфигурации вендора, но и наша же конфигурация при «разветвленной разработке». Когда разрабатываю новую подсистему — в основной конфигурации создаю поставку, новую создаю на ее основе — там все на замках. Снимаю с замков только те объекты, которые правлю — и вижу ошибки только по ним.
Важно не решить все проблемы, а не вносить новые
После первоначального анализа впадаешь в уныние — сотни тыщ ошибок, человекогода на исправление. Правишь, правишь — а прогресс и незаметен. Многие в этот момент бросают автоматические проверки. А нужно лишь проверять новый код и не трогать старый. То же с тестами. Нужно не писать тесты на весь функционал, который и так работает. А писать нужно на новый, который еще не обкатан в проде.
Правило бойскаута
Отдельно выделю — Оставляйте код чище, чем застали. Сделайте чуточку лучше тот код, который трогаете при кодировании текущей задачи.
Нужно четко разделять — это ошибка, тех.долг или ложное срабатывание
Часто тех.долг хочется отметить пропуском. Ошибка в коде остается со всеми негативными свойствами. Но теперь найти ее становится еще сложнее.
Решить все проблемы не получится
Смиритесь. В проекте будет тех. долг. Если же упретесь и выведите в 0, то или маленький проект, либо потратили слишком много драгоценного времени на перфекционизм.
Примеры проверок
Некоторые из них выстрелили. Причем в ногу и больно.
Синтаксическая конструкция вида «Если…Тогда…ИначеЕсли…» должна содержать ветвь «Иначе»
Первое мнение о проверке — это перебор. Если нет ветки иначе, значит она не нужна и потоки правильно разносятся по ИначеЕсли. Но в какой-то момент психанул и везде, где в Иначе не должно заходить, расставил ВызватьИсключение “Мы тут не должны были оказаться”. И отвалились тесты. Оказалось что во многих местах, где был уверен, т.к. тщательно разрабатывал и тестировал, со временем что-то поменялось и появились скрытые ошибки.
ТекущаяДата()
Сравнительно недавно появился стандарт на запрет использование метода ТекущаяДата() , а может и давно и я о нем не знал. Впервые о запрете узнал, когда это подсветил сонар (через импорт из АПК). Еще подумал “за 10 лет кодинга ни разу не выстрелило в ногу, фигня, а не стандарт”.
А потом случился гейзен-баг. На моей машине, на контуре разработки, на контуре тестирования работало, а на стейдже нет. Было много перекидываний ответственности, был мат и оскорбления, были потрачены человекодни на поиск причины. В итоге нашли, что дело в часовом поясе (Денис, привет). И нужно было всего лишь не использовать ТекущаяДата().
Превышена длина строки
В стандарте указано, что не рекомендуется превышать 120 символов в строке. На проектах, что проверял на качество — это лидирующая по количеству срабатываний проверка. Каждый переопределяет допустимое количество символов под себя. Кто-то выставляет 180, кто-то 200. Я предпочитаю 140.
Длинные строки сложно читать, они не убираются в веб-редакторах — в гитлабе или в сонаре и их неудобно использовать, если расположить два окна рядом.
Когда начал исправлять длинные строки, часто стал находить там ошибки — в том самом конце, который не видно. Запятая не там, или скобка не туда, или не та переменная. Получившиеся строки стали поддаваться рефакторингу — стал находить дублирования, неоптимальности, возможность использовать существующий метод итп.
Орфография
Если ошибки орфографии встречаются в пользовательском интерфейсе — пользователь сразу считает программу косячной, даже если внутри ошибок нет. Это даже хуже ошибки рантайма.
Ошибки орфографии в коде не так заметны, но приводят к созданию дублирующегося метода или переменной. На форме есть реквизит Номенклатура, а в коде написал Номенкатура = ПолучитьНужнуюПозицию(). И код будет считаться валидным, и будет работать. Но неправильно.
А еще мы огребли от “Палета”и “Паллета”. Однозначно правильного варианта написания нет, как подсказывает гугл. Но в коде путаница приводила к реальным ошибкам. Решили, что раз проверка орфографии ругается на “Палета” и не ругается, на “Паллета”, то правильно так, как не ругается. Соответственно на остальные места будет подсветка. Добавлять в исключения запретили.
Отсутствует комментарий к экспортной процедуре (функции)
К ошибкам это не приводит. Но вот новый инструментарий улучшает качество анализа за счет таких комментариев. EDT умеет определять тип по описанию и выполнять проверки исходя из этого типа. А автогенерилки АПИ умеют собирать документацию по этим комментариям.
Ну и момент документирования тут есть. Все любят хорошую документацию. Писать ее, правда, никто не любит.
В модуле должны быть определены стандартные области
Также к ошибкам не приводит. Но повышает удобство разработки. Не нужно думать где размещать те или иные методы. Уже все придумано. При поиске нужного события — так же понятно где искать.
С развитием кодогенерации стандартные области будут еще более полезны.
Установлено право «Интерактивное удаление»
У вас когда-нибудь бывала ситуация, что кто-нибудь из властьимущих (у кого есть полные права в базе) непосредственно удалял объект из базы и потом там что-то ломалось. Я наверно каждый год трачу несколько дней на расследование таких ошибок и каждый раз это сводится к поиску — какая же роль дала право на удаление.
Использование устаревшей процедуры
Легко пропустить, что любимую процедуру в БСП или в другой библиотеке пометили устаревшей. Пометка устаревшей означает, что в одном из следующих релизов ее удалят. Если заранее не исправить эти места — после обновления можно сильно удивиться.
Недопустимый вызов служебной процедуры или функции другой подсистемы
А это уже об использовании приватных методов. Если публичные методы сперва делают устаревшими, чтобы было время на исправление. То приватные методы могут изменится в любой момент. Ну нет в 1С возможности сделать приватный метод на подсистему. Используете чужие приватные методы? Рискуете, что что-то отвалится в неожиданный момент.
Выводы
- Определитесь, нужно ли качество на проекте. Точнее качество то точно нужно, но готовы ли за него заплатить временем или деньгами? “Технология очень быстрого результата” (она же фигакфигак и в продакшен, не путать с “Технологией Быстрого Результата”) не так уж и плоха.
- Правильнее на управление качеством (Continuous Code Inspection если по заумному) смотреть как на инструмент. Инструмент применяется под конкретные задачи, процессы, методологии.
- С течением времени порог на управление качеством будет снижаться. Верю, что наступит время, когда это будет обязательным инструментов при разработке с низкой ценой использования.
- Даже если нет нужных проектов, или там это очень сложно развернуть — инвестирование в знания окупятся. При смене платформы, проекта, работы.
