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

В IT существует похожая схема — Code Review. Это проверка нового кода перед выпуском. Выполняется другими разработчиками, но не тем, кто написал.

Задача Code Review — найти баги и недочёты на этапе разработки. Ведь когда код проверяют несколько специалистов, вероятность обнаружения ошибок возрастает и они не попадают «в бой».

А ещё это полезная практика для команды:

• Больше людей в курсе. Если разработчик заболел, ушёл в отпуск, уволился, другие могут подхватить проект.
• Улучшается качество кода и, соответственно, его поддержка. Код понятен не одному человеку, а многим.   
• Обмен опытом. Коллеги учатся друг у друга, подмечают интересные для себя варианты решения.
• Здоровая атмосфера в команде. Сотрудники сплачиваются и понимают, как давать адекватную обратную связь.

Из недостатков Code Review можно отметить лишь увеличение времени на реализацию и занятость двух и более людей на проекте.

Жёстких правил, кто ревьюрит, нет. Обычно это тимлид или сотрудник с более высоким грейдом — мидл, сеньор. Можно поручать проверку коллеге с похожим опытом. 

В крупных компаниях Code Review часто проводят в два этапа: сначала смотрит мидл, затем тимлид. 

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

Нюансы будут отличаться в каждой команде. Из общих рекомендаций:

• Автоматизировать рутину. Code Style, то есть отступы, пробелы, написание переменных, скобок, прекрасно проверяет машина. Не стоит загружать этим человека.
• Проводить Code Review для каждого члена команды. Несправедливо проверять только джуниоров. Сеньоры тоже ошибаются.
• Ревьюрят все задачи — никаких исключений. Это избавляет от ненужных обсуждений и споров.
• Делить объёмные коды на несколько частей, чтобы не страдало качество. Оптимально проверять за раз от 200 до 400 строк.

Чего стоит избегать:

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

Пробежимся вкратце по основным пунктам:

• Читаемость. Насколько код понятный и чистый, смогут ли в нём разобраться другие разработчики.
• Логика. Должна быть корректной, а код подчиняться определённым правилам и алгоритмам.
• Архитектура. Какова организация и как элементы взаимодействуют друг с другом.
• Производительность. Необходима для быстроты работы и масштабирования.
• Надёжность. Значимый показатель для защиты от хакерских атак и утечки данных.
• Зависимости. Не используются ли устаревшие и опасные библиотеки.
• Отношение к ошибкам. При их обнаружении система должна сообщить о них и продолжить функционировать.

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

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

После Code Review нужно записать в таск-трекере или CRM, что стоит изменить, предложить решения, задать вопросы, если что-то осталось непонятным. 

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

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

Если у вас остались вопросы по код-ревью или другим IT-темам, обращайтесь. Всё объясним, подберём оптимальное решение для вашего бизнеса.