В большинстве вакансий, что мы видели за последние 10 лет, было упоминание процесса Code Review. Но ни в одной из этих вакансий не было описано, как именно этот процесс происходит. Между тем, в каждой конкретной команде были свои нюансы: на кого надо назначать, кого подключать дополнительно, сколько процесс занимает по времени, сколько человек в этом участвуют, сколько approve-голосов считается достаточным.
Где-то в глубине души нас терзали мысли о том, что мы что-то делаем не так, или недостаточно “так”. Но, как говорится: критикуешь - предлагай.
А предложить было нечего. Потому что хотя бы половина ответа на что-либо, как известно, содержится в правильном поставленном вопросе. И вот сейчас, на текущем месте работы, мы пришли к правильной мысли (как нам кажется), которой хотим поделиться и узнать ваше мнение :)
Что нужно сделать до внедрения чек-листов для Code Review
Первым делом имеет смысл закрыть “базовые потребности” любого проекта:
Вся команда придерживается определенного Code Style Guide
Статические анализаторы кода помогают с пунктом №1
Имеется корпоративный/командный/проектный вики с best practices
Как создавать чек-листы для Code Review
Выберите тему (пусть сейчас это будет “Работа с базой данных”). Выпишите кратко все best practices на эту тему, которые актуальны для текущего проекта. Добавьте (бонусное задание - выделите особым цветом) все предыдущие факапы инциденты в виде тезисов или ключевых выводов. Дополняйте по мере поступления новых хороших идей и/или новых факапов инцидентов.
Помните, что чек-лист должен быть лаконичным и приятным, а не огромным отпугивающим. Я бы рекомендовал версионировать чек-листы.
В чем польза от чек-листов для Code Review? Я вижу две основные пользы:
уменьшение зависимости от опыта / текущего состояния разработчика
уменьшение вероятности возникновения уже пройденных ошибок
Польза #1. Уменьшение зависимости от опыта/текущего состояния разработчика
Опытным разработчикам многие ошибки и потенциально опасные места видны сразу. Но все-таки случается такое, что из-за кучи переключений или текущего состояния (самочувствия) можно что-то и не заметить. Конечно, чек-лист нас не спасет от этого, но вспоминание прошлого опыта вместо прохождения по чек-листу - операция более энергозатратная.
Кроме этого, коллеги-новички могут не знать того, что знают их более опытные участники команды. Даже прохождение по чек-листу может уже дать новых знаний или хотя бы поводов для обсуждений с автором кода. Таким образом, чек-лист, косвенно, приводит к передаче опыта внутри команды.
Польза #2. Уменьшение вероятности возникновения уже пройденных ошибок
В каждой компании, где я работал, случались проблемы на проде. К сожалению, иногда проблемы были повторяющимися, а не новыми. И случалось это, в основном, из-за недостаточно качественного Code Review.
Последнее, что хочу сюда добавить - это знание об индивидуальных особенностях определенной части системы, в коде которой делается изменение. Возможно, разработчик, который делает ревью, никогда не работал с этим кодом (потому что он новенький, или потому что проект достался “по наследству”) и не знает о нюансах, которые могут вскрыться. Имея под рукой чек-лист, он сможет проверить измененный код на эти нюансы.
Мне вспоминается фраза “Всё уже украдено до нас”. Оставлю здесь ссылку на один из самых лаконичных и хороших чек-листов для Code Review.