Code-review с помощью нейросети

Попросил нейросеть Khoj сделать ревью своего старого проекта на 1С на GitHub.
Использовал вот такой промпт:

Ты крутой программист 1С, тимлид. Тебе нужно провести ревью кода твоего подчиненного. Код находится здесь - https://github.com/Oxotka/PackageToPDF/blob/forCodeReview/КомплектДокументов/Forms/СохранениеКомплектовВPDF/Ext/Form/Module.bsl

Какие замечания ты сделаешь к коду?

Вот результат:

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

1. Структура и организация кода:
- Код разделен на области (#Область), что помогает в структурировании, но некоторые области, например, ОбработчикиСобытийФормы, содержат слишком много логики. Рекомендуется разделить большие процедуры, такие как ПриСозданииНаСервере, на более мелкие для улучшения читаемости и поддерживаемости.

2. Обработка исключений:
- В коде часто используются конструкции вида "Если НЕ ЗначениеЗаполнено(...) Тогда ВызватьИсключение ... КонецЕсли;". Убедитесь, что все исключения обрабатываются корректно и пользователю предоставляется понятная информация об ошибках.

3. Магические строки и числа:
- В коде встречаются магические строки, например, "Документ_" + Индекс в процедуре ПриСозданииНаСервере. Рекомендуется вынести такие строки в константы или использовать более описательные переменные.

4. Повторяющийся код:
- Наблюдается дублирование кода, например, в процедуре ВосстановитьНастройкиПечатныхФормПоУмолчанию. Рекомендуется вынести повторяющиеся блоки в отдельные процедуры для уменьшения дублирования и упрощения поддержки.

5. Использование глобальных зависимостей:
- В коде используются глобальные переменные и процедуры, такие как ОбщегоНазначенияКлиентСервер.СвойствоСтруктуры. Убедитесь, что эти зависимости документированы и их использование оправдано.

6. Комментарии:
- Некоторые комментарии недостаточно информативны или отсутствуют. Рекомендуется добавить более подробные комментарии для улучшения понимания логики кода.

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

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

Еще пример ревью от нейросети вот и вот.

#AI

AI убьет программистов?

Очень интересное видео на YouTube про настоящее и будущее AI в организации.
Рекомендую смотреть от начала и до конца. Рассказывают про наше потенциальное будущее, на удивление, с примерами на 1С.

Продублирую видео еще в следующем посте, для тех, кто не хочет мучаться с YouTube

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

В любом случае рекомендую к самостоятельному изучению - https://docs.fine.dev/getting-started/software-3.0

#AI

AI агенты для проверки кода

Попробовал несколько популярных агентов для проверки кода с помощью нейросетей. Вот краткая сводка по ним:

1️⃣ CodeRabbit - Бот встраивается в GitHub и GitLab и работает с запросами на слияние (pull request или merge request). В описании сказано, что он может работать и с большими запросами (до 100 файлов с помощью инкрементного обзора), но я это не проверял.

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

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

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

2️⃣ Bito’s AI - Бот встраивается в IDE, например, в Visual Studio Code. Работа происходит в отдельном присоединенном окне, куда можно отправить код или задать вопрос. Бот отвечает очень быстро и может сразу подготовить текст с кодом, который легко скопировать и вставить обратно в проект.

Для подключения к запросам на слияние уже требуется платная версия.
Я просто попросил сделать ревью вставленного кода. Вот результат ревью с помощью этого сервиса.

В целом это удобная оболочка над AI, которая позволяет задавать вопросы из IDE. Например, я попросил подготовить документирующие комментарии к коду, и он их быстро сделал.

3️⃣ CodeScene - Это отдельно стоящий сервис, который работает с репозиториями на GitHub, GitLab и другими хостингами. В бесплатной версии умеет работать только с публичными репозиториями. К сожалению, языка 1С он не знает и ничего выдать не смог. Но с репозиторием на Python сработал хорошо, построил карту модулей и подсветил проблемные моменты (VPN).

Понравилось, что есть динамическое наблюдение и построение трендов как по сложности, так и ошибок в коде. Примерно как SonarQube отслеживает изменения. Жаль, что с 1С пока не работает.

4️⃣ Amazon CodeGuru Reviewer - Еще один сервис для проведения ревью. К сожалению, опробовать его не удалось, так как там не смог пробиться за Paywall.

5️⃣ Pull Request - Интересная идея сервиса для проведения ревью. Там удаленные сеньоры разработчики могут проверить твой код и выдать замечания. Код-ревью на аутсорс - прикольная идея, но опробовать ее не получилось.


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

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

Ну и заявка в мир, смотрите - я использую современные технологии!

#AI

Подходит к концу второй тур голосования за доклады на Infostart Tech Event.
Вот здесь можно проголосовать за мой доклад Навыки высокоэффективных разработчиков.

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

Про качество

У нас довольно высокие оценки за качество 1С:Бухгалтерии от пользователей и партнеров. На картинке оценки за качество конфигурации, которые мы собираем с помощью анкет. Их выставляют партнеры, которые приезжают на большие семинары в Москве. Естественно, это не единственная метрика, но она довольна показательная с точки зрения охвата и динамики.

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

Поэтому расслабляться нельзя и к работе с качеством программы мы прикладываем огромные усилия. Для этого совершенствуем наши инструменты и процессы тестирования. Кстати, в 2022 году даже проводили 1C:TestCon (по ссылке доступны видеозаписи).

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

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

На этой неделе хочу подробнее поговорить про качество и рассказать про Контрольную ошибку и Дни Качества.

Контрольная ошибка

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

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

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

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

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

Кстати, если стыдно за большое количество ошибок в проекте, то можно каждую вторую называть контрольной :)

День качества

Для поддержания качества важно вовремя и хорошо исправлять ошибки. Но и к этому процессу нужно подходить ответственно. Например, у нас вот такой процесс работы с ошибками:
1. Ошибка зарегистрирована. Ошибку удалось воспроизвести
2. Ошибка признана. Разработчик признал такое поведение ошибкой
3. Ошибка исправлена. Разработчик внес исправления в код
4. Выполнено ревью кода. Другой разработчик посмотрел по ней код
5. Ошибка проверена. Выполнена проверка, что ошибка исправлена
6. Ошибка закрыта. Исправление встроено во все необходимые версии

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

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

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

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

После каждого такого дня подводим результаты работы. Например, исправлено 100 ошибок, зарегистрировано 10. Кстати, ошибок, которые зарегистрировали разработчики гораздо больше тех, что приходят от пользователей и партнеров. Это логично, так как мы знаем где искать :)

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

Ну и еще мы любим побывать на дне качества :)

1С на Останкинской телебашне

Карта компетенции

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

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

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

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

Ключевой сотрудник может постепенно подключать к своей зоне ответственности новых людей. Например, сделал какую-то задачу и ее нужно проверить. Если «желтых» сотрудников нет, то ищем среди остальных коллег и отдаем ему задачу. После того как он погрузится и проверит задачу его можно сделать замещающим по направлению.

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

Портфель знаний

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

1️⃣ Инвестировать регулярно

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

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

В книге рекомендуется читать одну техническую книгу в квартал. Это отличный способ формировать свой портфель на регулярной основе.

2️⃣ Диверсифицировать знания и инструменты

Чем больше вы знаете о различных инструментах, тем лучше.

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

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

3️⃣ Иметь консервативные и высокорисковые инструменты

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

То же самое можно сказать сейчас про Элемент. Выстрелит ли он? Неизвестно.
Сейчас это высокорисковый инструмент. Но он может принести прибыль тем, кто решился в него вложиться в будущем.

Высокорисковая часть портфеля как раз обеспечивает развитие, в то время как консервативная позволяет защищаться от рисков. Поэтому нужно иметь и консервативные инструменты - конфигуратор, например, лучше справляется с СКД, чем EDT.

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

4️⃣ Получать знания пока они дешевые, продавать когда дорогие

В книге приводится такое пояснение:

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

Если заменить Java на Элемент, то вполне подойдет и под наши реалии.

SonarQube, YaxUnit или BSL Plugin - уже не вау эффект, а технологический минимум в нашей отрасли. Те кто приходит к ним только сейчас уже отстают.

5️⃣ Пересматривать портфель и ребалансировать его

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

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


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