Делаем процесс Code Review простым и удобным с помощью консоли кода

Я давно работаю с 1С. Много лет увлекаюсь разработкой инструментов, которые облегчают жизнь обычному программисту. Если заглянуть в мой профиль на «Инфостарте», там почти все связано с инструментами. Особенно люблю работать на стыке разных технологий и языков и скрещивать их.

 

Определение Code Review

 

Начнем с определения. Что такое Code Review? Это процесс проверки и анализа кода, который проводится перед его релизом. При этом есть один важный момент: проверку выполняет не тот разработчик, который делал задачу, а другие члены команды. Результатом такой проверки всегда становится обратная связь.

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

 

 

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

 

 

А так выглядит схема, если все организовано правильно.

У нас есть два возможных пути. Либо мы находим ошибки в коде и возвращаем задачу разработчику на доработку – и так по кругу. Либо подтверждаем, что код соответствует требованиям, и отправляем его дальше – на тестирование или в релиз в зависимости от процесса.

 

Цели и преимущества Code Review

 

С определением Code Review мы разобрались, но пока не определили, зачем он нужен. Самый очевидный ответ: чтобы повысить качество кода и, как следствие, качество решений, которые мы предоставляем заказчику.

Может показаться, что код должен проверять только самый опытный разработчик – тот, кто «прошел огонь, воду и 1С 6.0», программировал десятки лет и знает все. Но на самом деле это не обязательно. Напротив, хорошей практикой считается вовлечение в процесс код-ревью всех членов команды. Даже менее опытный разработчик может быть полезен в процессе.

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

 

 

Во-первых – обучение. Если процесс организован правильно и в него включены все члены команды, то помимо качества кода мы получаем обучаемость сотрудников. Разные разработчики используют разные подходы и привычные алгоритмы. У опытного специалиста может «замылиться» глаз: он может не знать какого-то нового, более эффективного решения, потому что давно не интересуется новинками. А вот его менее опытный коллега, наоборот, активно изучает новые технологии и на ревью может предложить: «А давай сделаем вот так – будет гораздо лучше». В процессе такой обратной связи происходит обмен знаниями – команда как бы «переопыляется».

 

 

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

 

 

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

Бас-фактор (от англ. bus – «автобус») – это мера сосредоточения информации среди членов проекта: о том, как что работает, как это устроено и так далее. Чем он ближе к единице, тем хуже.

В компаниях, где до сих пор работают на устаревших версиях 1С (например, 7.7), нередко бывает, что только один человек знает, как все устроено, и отвечает за всю инфраструктуру. Если этот человек – вы, советую попросить у работодателя телохранителя, а лучше вообще не выходить на улицу, чтобы избежать «фактора кирпича». Это когда разработчик вышел из офиса, кирпич упал ему на голову – и человек исчез, а с ним и все знания по проекту.

 

Минусы и риски внедрения Code Review

 

Казалось бы, Code Review – это отличная практика, и стоит немедленно броситься ее внедрять. Но на самом деле у нее есть не только плюсы, но и минусы.

Самый очевидный и серьезный минус – конфликты в команде. Ранее я говорил, что ревью может способствовать развитию культуры общения. Но это происходит не всегда. Если подход не налажен, то вместо конструктивной дискуссии можно услышать на созвонах или в переписке резкие комментарии.

Дело в том, что люди разные. К критике мы относимся по-разному. Разрешение конфликтов – это отдельный разговор, не в рамках этой статьи. Но дать один важный совет могу: перед внедрением Code Review соберите команду и заранее обсудите правила игры. Например, объясните «Васе-синьору», что «Коля-мидл» будет проверять не самого Васю, а только код. Это помогает отделить критику от личных амбиций и снизить напряжение.

 

 

Кстати, когда я показывал эту картинку коллегам, они сказали: «Такого не бывает!» Почему? Потому что вместо мидла должен быть синьор. Когда встречаются два сеньора, то происходит жесткий замес, потому что каждый считает, что он прав, его код лучше, и никакая критика не приветствуется. Здесь в шутку могу посоветовать прокачать одного сеньора, купить ему абонемент в зал, записать на кунг-фу – тогда он будет побеждать всех, и конфликтов станет меньше.

Еще один серьезный минус – увеличение времени на разработку. Это очевидно: раньше задачу реализовывал один человек, теперь к процессу добавляется еще хотя бы один – ревьювер. Пока мы разрабатываем и проверяем, заказчик сидит и ждет.

 

Существующие инструменты для Code Review

 

С определением Code Review разобрались, поговорили о целях и обсудили как плюсы, так и минусы. Теперь перейдем к самому главному – к инструментам.

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

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

Второй способ: берем ручку, бумажку или любой мессенджер – Telegram, Slack, WhatsApp – пишем замечания и отправляем коллеге. Удобства, конечно, никакого, но кое-какой прогресс уже есть. Так, например, в эпоху 1С 7.7 мы как раз и проводили код-ревью: пересылали фрагменты кода и обсуждали их в чатах.

Третье средство – комментарии в коде. Открываем конфигуратор, находим нужный участок кода и прямо в нем оставляем комментарии. Удобно? Нет. Правильно? Тоже вряд ли.

 

 

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

 

 

Четвертый способ – консоль кода. Это мой личный фаворит. Вспомните времена 8.1–8.2, когда еще не было «на клиенте/на сервере» и можно было просто перетащить поле текстового документа на форму, указать в свойствах поддержку встроенного языка – и готово, консоль работает. Это было золотое время для консолей.

 

 

Наиболее известная и до сих пор популярная консоль – та, что входит в состав инструментов разработчика от Сергея Старых. Ее используют тысячи разработчиков, включая меня. Консоль классная, но, к сожалению, только на обычных формах. Долгое время на управляемых формах не было нормальных консолей с подсветкой синтаксиса. А я, признаться, страдал – мне важно, чтобы было красиво. Приходишь на работу, а вокруг все серое, унылое – было больно.

 

 

Но, к счастью, звезды сошлись. С одной стороны, Microsoft выпустила open-source редактор Monaco – тот самый, что используется в VS Code. С другой – 1С заменила движок HTML-документа на WebKit. Благодаря этому удалось внедрить редактор на базе Monaco в 1С: появилась подсветка синтаксиса, подсказки и другие классные штуки, которые есть в современных редакторах кода.

Сейчас эта консоль используется во многих инструментах. Например, в Infostart Toolkit.

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

 

 

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

 

 

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

Некоторое время назад я был наставником у коллеги, и мы активно пользовались этим средством.

 

 

Он присылал мне кусок кода с пометкой «Проверь». Я заходил в браузер, писал замечания. В консоли есть кнопки: замечания можно удалять, видеть степень их важности и что написал проверяющий.

 

Автоматизация и современные платформы

 

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

 

 

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

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

В нашей команде мы долгое время использовали SonarQube, но нестандартным образом. Мы убеждали разработчиков: «Это важно, это полезно, заходите, смотрите, пользуйтесь!» Все кивали, соглашались… но не пользовались.

Немногие знают, по крайней мере в среде 1С я не нашел упоминания об этом, но SonarQube имеет очень хороший API и документацию.

Используя API, мы реализовали автоматическую постановку задач на устранение замечаний. Разработчик спокойно работает, закоммитил код – и в этот момент бац – в систему учета задач прилетает новая задача с перечнем найденных нарушений.

 

 

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

 

 

Сегодня многие команды активно используют облачные платформы – GitHub, GitLab. Это отличные, можно сказать, незаменимые инструменты. Однако проверять код в них все еще немного непривычно.

 

 

Если изменения касаются кода – еще ладно, выглядит более-менее понятно.

 

 

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

 

 

Сторонние инструменты не очень спасают ситуацию. Например, на картинке показан VSCode с плагином GitLab Workflow. Да, в нем уже можно просматривать код, но когда речь заходит об изменениях в реквизитах табличных частях или других элементах метаданных, все это выглядит уже не очень привычно.

 

Создание собственного инструмента для Code Review

 

 

Однажды в нашей команде назрела необходимость внедрить CI/CD. В процессе настройки, просматривая очередной merge request в GitLab, мне захотелось сделать свой велосипед инструмент, который позволял бы в удобном виде видеть вносимые изменения. Под удобным видом я понимаю не только код, но и изменения метаданных.

 

 

В итоге родилось решение Git Code Review

Оно позволяет:

• Удобно просматривать код,

• Видеть все версии хранилища с комментариями, авторами и датами,

• И, что особенно ценно – видеть изменения в метаданных.

 

 

Например, на рисунке видно, что в справочник «Склады» добавили новый реквизит. Да, это выглядит не как в конфигураторе, но это гораздо понятнее, чем голый XML (голый XML тоже можно смотреть).

Причем не обязательно анализировать изменения между последней и предпоследней версией хранилища. На рисунке, например, выделено семь версий хранилища – и буквально спустя секунду мы можем видеть все изменения между ними. Инструмент работает быстро и поддерживает Windows и Linux.

 

 

Но что еще более ценно – в этом инструменте можно вносить замечания. Я хотел доработать консоль так, чтобы она позволяла делать это так же, как в GitHub. На рисунке сверху – форма для ввода. Наводишь курсор на строку кода – появляется плюсик, кликаешь, указываешь тип замечания (ошибка, предупреждение, информация), пишешь комментарий. Ниже – уже оформленное замечание с указанием автора и времени. Его можно редактировать, удалять – все прозрачно и удобно.

 

 

Однако зачем писать все вручную, если есть автоматические проверки? В инструмент встроена возможность запускать BSL Language Server. Ко всем изменениям кода мы можем добавить автоматические замечания, которые выявил BSL Language Server.

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

 

 

Либо это может выглядеть вот так. Замечания показываются прямо в коде, видно ссылку, можно перейти по ней. Это уже BSL Language Server сформировал замечание.

Я сторонник смешанного подхода: сначала запускаем автоматическую проверку, затем вручную просматриваем изменения и добавляем свои замечания. И только после этого отправляем все автору на доработку.

 

 

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

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

Например, можно добавить контекст задачи: подтянуть описание из Jira, Bitrix24, или любой другой системы. Добавить скриншоты, комментарии, пояснения – чтобы проверяющему, который проводит код-ревью, было радостно, и чтобы он видел контекст задачи, в которую вносятся изменения.

 

Недостатки и будущее разработки инструмента

 

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

Главный из них – необходимость использовать Git.

Можно, например, пользоваться GitSync

Даже если вы пока не проводите код-ревью, этот инструмент можно использовать для быстрого просмотра изменений. Не обязательно сравнивать версии хранилища вручную – особенно если речь идет о тяжелом проекте вроде ERP или ERP УХ. Это и больно, и долго. Настраиваете автоматическую выгрузку, подключаете инструмент и за пару секунд видите все изменения. Конечно, лучше все же проводить полноценный код-ревью, но и без него функционал полезен.

Сейчас все больше команд переходят на GitFlow. И здесь отдельные коммиты (или версии хранилища) уже перестают быть центром внимания. Гораздо важнее – merge request'ы (MR). Это набор коммитов для помещения из одной ветки в другую. Вот этот набор изменений и нужно выносить на код-ревью.

 

 

Поэтому родилась идея: научить инструмент анализировать целый merge request, а не отдельные коммиты. Да, технически это можно делать в GitLab или GitHub. Там уже есть интерфейс для ревью. Но к коду претензий нет, а вот к XML – претензии есть.

Было решено сделать специальный инструмент на уже знакомом сайте paste1c.ru. Сейчас этот функционал разрабатывается и скоро станет доступен всем желающим. Пользоваться им можно будет абсолютно бесплатно.

Как это будет работать? Вы просто вставляете на сайте ссылку на merge request, указываете данные для авторизации. Буквально через несколько секунд вы увидите все изменения в удобном виде.

 

 

Да, интерфейс немного непривычный, но он уже гораздо ближе к тому, к чему мы привыкли в 1С. Вы увидите, например, что в документ «АктПроведенияИспытанийВходногоКонтроля» добавлены новые реквизиты, служебную информацию: кто создал merge request, когда, из какой ветки в какую.

 

 

Мы можем увидеть изменения в коде. Также можно как вручную оставлять замечания (как в Git Code Review), так и запускать автоматические проверки через BSL Language Server. В верхней панели – настройки: можно указать, на какие типы ошибок реагировать, а какие игнорировать.

Подход остается тем же: сначала автоматика, потом ручная проверка и добавление своих комментариев – и только после этого отправка автору. Также добавлена панель навигации – удобно перемещаться по замечаниям, по измененным блокам кода.

Что можно сделать с полученными результатами? У меня три варианта:

 

 

Первый вариант: сохранить все на сайте и отправить ссылку разработчику. Он переходит, видит все, что нужно, и исправляет.

 

 

Второй вариант – не хранить данные на сайте. Понимаю, что у многих есть вопросы по безопасности. В этом случае результаты можно отправить напрямую в GitLab или GitHub через API – прямо в комментарии к merge request.

 

 

Третий вариант – комбинированный: сохраняем результаты на сайте и отправляем их через API в облачный хостинг. В комментарии к merge request при этом оставляем ссылку на полную версию – для удобства.

Внимательные читатели могли заметить, что на сайте нужно указать токен авторизации. Некоторые этот сайт впервые видят и думают: «Да, уже побежали токен авторизации указывать». Но могу заверить: токен нигде не хранится на сервере paste1c.ru. Он используется только для запросов к API GitLab и хранится исключительно на вашем локальном компьютере. На самом сайте он не сохраняется.

 

Планы по развитию Git Code Review

 

• Добавить на сайт API Github. Сейчас я фокусируюсь на взаимодействии с GitLab, но GitHub – в планах, не забыт и обязательно появится.

• Добавить на сайт анализ отдельных коммитов. В процессе разработки понял, что эта функция тоже нужна – будет добавлена.

• Анализ PR в 1Ске. Я вообще устаю от 1С, поэтому захотелось попрограммировать на чем-нибудь другом, и родилась идея сделать это на сайте. Но когда была сделана уже половина работы, пришло понимание, что этот же функционал неплохо иметь в 1С в инструменте обработки Git Code Review. Поэтому анализ PR, merge request в 1С тоже будет.

• Добавить поддержку формата EDT. Пока ее нет, но появится. Проблем, думаю, не возникнет.

• Возможно, в редакторе появится возможность вести полноценную дискуссию. Код-ревью – это все-таки процесс взаимодействия по замечаниям. Иногда разработчику важно отстоять свою позицию, сказать: «Я сделал так, потому что…», а не просто прочитать, согласиться и исправить. Сейчас нет возможности вести дискуссию по замечаниям, но очень хочется сделать. Я надеюсь, что получится это реализовать.

• Git Code Review + Electron. Давно смотрю на Electron – это технология, которая позволяет сделать кроссплатформенные приложения. Я понимаю, что пользоваться сторонним сайтом нежелательно, это может запрещать безопасность. Поэтому хотелось бы сделать кроссплатформенное приложение, которое можно запускать у себя внутри, при этом не используя 1С. Надеюсь, когда-нибудь этому будет суждено сбыться.

Мне бы не хотелось, чтобы у вас сложилось впечатление, будто я противопоставляю свои инструменты другим подходам или ратую за их исключительное использование. Ничего подобного. Я считаю, что все инструменты – хороши. Хотите, пользуйтесь бумажкой и ручкой, хотите – конфигуратором, мессенджером, веб-сервисами – выбирайте то, что подходит именно вам. Главное – не используйте подзатыльники 😉.

Мой основной посыл прост: инструментов должно быть как можно больше. И желательно – чтобы они были бесплатными и доступными для всех.

Кстати, на «Инфостарте» есть анонс интересного инструмента под названием Reviewer

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.