Совершенствование вместо совершенства

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

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

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

Редко, но достаточно

Лиду. Код-ревью — это непросто для команды. Разбор работы отнимает время, может привести к напряжению между сотрудниками. Вот в каких случаях лучше не проводить код-ревью:

— Все разработчики примерно одного уровня. Между проверяющим и проверяемым нет «ступеньки опыта», которая помогает значительно улучшить код.

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

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

Ревью по системе

Лиду. Проверяйте код раундами, от самых крупных и важных мёрдж-реквестов до самых незначительных. Оценивайте объем реквестов и определяйте, можете ли вы проверить его на "одном дыхании«‎, не теряя концентрации. Чем объемнее решение, тем ниже эффективность проверки.

Сперва оценивайте высокоуровнево: на уровне подхода к проектированию решений, архитектурных принципов, модульности, выбора функций. И только если высокоуровневых ошибок нет, начинайте оценивать с большей детализацией.

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

Документация и комментарии

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

Разделите свои комментарии к коду ревьюемого на два потока:

— Общие комментарии — о коде, который должен быть исправлен.

— NT-комментарии (от nitpick) — ваши общие пожелания и рекомендации, которые можно проигнорировать.

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

Разработчику. Обязательно комментируйте код. Используйте автотесты и линтеры, принятые в команде.

«Дни фейлов»

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

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

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