Как правильно проводить code review

Готов поспорить, что в 2021 году каждый уважающий себя разработчик не только слышал про такой процесс, как code review, но и на ежедневной основе его практикует. Сейчас нет никакого смысла обсуждать плюсы и минусы код ревью, потому что для всех итак уже очевидно: практика эта весьма и весьма полезная. Если вы считаете, что code review не нужен и только мешает, то взгляните на свой календарь и убедитесь, что на дворе не 1995 год, либо просто валите из профессии, черт возьми! 🤬 Ну а в этом посте я хочу поговорить о том, как правильно подходить к процессу ревью и как заставить ваших коллег трепетать каждый раз, когда они добавляют вас в список проверяющих.

Внезапное откровение. Цель code-review – вовсе не улучшение кода

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

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

Код-ревью – это битва

Когда кто-то выкладывает свой код на ревью, он ожидает схватки. Подумайте сами, ведь это чертовски логично – вы отправляете свой код на проверку только тогда, когда достаточно отполировали его и уверены в своей правоте. Иначе вы бы внесли некоторые правки, прежде чем создавать pull request, верно?

Итак, код отправлен на ревью. Идеальный код. Вы уверены в своей правоте, но тут приходят они – пройдохи, желающие оспорить ваш авторитет. Они цепляются за совершенно нормальный код и пишут свои занудные заранее припасенные фразочки: «Ну, тут бы я сделал по-другому», «Семантически правильнее будет вызывать эту функцию не здесь, а на 125 строчке», «На этот метод нет юнит-тестов», «Какова сложность этого алгоритма?»…

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

На code-review вас оскорбляют

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

Оскорбляйте в ответ

 Вместо того, чтобы критиковать код, критикуйте человека, который написал этот код.  Это золотое правило. Вместо «здесь ошибка» напишите «ты ошибся». Вместо «вызов этой функции расположен в неверном месте» – «Ты не сечешь и вызываешь функцию неправильно». Если код соперника досконально покрыт тестами, можно обсмеять его и спросить, зачем ему это. Неужто он не уверен в качестве своего кода? На эту тему я писал отдельный пост.

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

Идеальное код ревью

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

По сути, даже не важно, что именно вы смерджите в свою релизную ветку. Code review – это такой процесс, где важен сам процесс, а не результат. Главное, чтобы все зарядились православной энергией.

Результат

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

Понравилось? Подписывайтесь на меня в соцсетях!