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

Мне кажется, что нет такого понятия, как проверка кода без единого комментария.

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

Обновить

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

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

Поэтому я добавил библиотеку с именем «jscpd» для обнаружения копий. Сбой сборки на копирующих пастах. Это сразу устранило одну проблему.

Далее мы собираемся попробовать кодеклимат.

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

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

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

Но по моему опыту, я подозреваю, что происходит что-то еще.

Считаете ли вы, что ваша команда может почувствовать, что процесс нарушен / глуп / неэффективен для большинства коммитов? Помните, процесс документирует то, что работает хорошо, а не правила, которым нужно подчиняться . И как руководитель команды, вы здесь, чтобы помочь им быть лучшими, а не соблюдать правила.

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

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

Использование инструмента поверх сломанного процесса не улучшит процесс.

Мне не нравится публиковать однострочные ответы, но этот кажется подходящим:

Участвуйте в процессе.

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

Несколько вещей (честно говоря, большинство из них описаны в ответах, но я хотел поместить их в одном месте)

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

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

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

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

Вы можете задокументировать, что команда хочет, в обзорах кода, которые вы обсуждали и согласовывали с разработчиками. Вот некоторые вещи, которые вы могли бы рассмотреть как часть обзоров кода:

• Убедитесь, что код выполняет то, что должен делать, т.е. отвечает требованиям

• Стиль кода, чтобы гарантировать, что разработчики кодируют в единый стиль

• Оптимизация, например, количество вызовов функций

• Архитектура и возможность повторного использования

• Обработка исключений и ведение журнала

• Технический долг: код в лучшем состоянии, чем когда разработчик начал над ним работать

• Проверьте и создайте код (я считаю это полезным, но другие разработчики в моей команде предпочитают оставлять это для тестировщиков)

• Используя автоматизированный инструмент (я использовал SonarQube ). Я считаю полезным интегрировать это в процесс сборки, чтобы обеспечить улучшение кода, например, увеличение охвата тестированием.

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

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

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

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

Во-первых, позвольте мне задать вам вопрос. Используете ли вы систему контроля версий (например, Mercurial, Git)?

Если ваш ответ да, тогда продолжайте.

1. запретить всем толкать что-либо (даже небольшие исправления) непосредственно в главную ветвь (транк) *
2. разрабатывать новые функции (или исправления) в отдельных ветках
3. когда разработчики считают, что ветка готова к интеграции в master, они создают «запрос на извлечение»
4. запретить всем объединять свои собственные запросы *
5. пусть другой разработчик оценит запрос на извлечение и рассмотрит новый код
6. если код проходит проверку, хорошо, запрос на извлечение может быть объединен, в противном случае могут быть применены исправления.
7. повторять шаг 6 до тех пор, пока код не станет достаточно зрелым (это можно сделать без повторного запуска)
8. готово, весь ваш новый код проверен (хотя бы кратко) кем-то с именем

Теперь у вас есть точная точка в вашем рабочем процессе, где выполняется проверка кода.

Действуй там.

* может быть применено автоматически, с помощью серверных перехватчиков

** эта процедура полностью поддерживается GitHub (среди прочих) и довольно проста в использовании, ознакомьтесь с ней

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