Каковы цели и лучшие практики проведения Code Review?

Давай разберем эту всю хуйню про Code Review, а то читаешь — как будто инструкцию к стиральной машине перевели с китайского через гугл-переводчик. Э, сабака сука, слушай сюда.

Ну, Code Review, или, как мы его ласково называем, CR — это когда ты написал код, а потом приходят твои же коллеги и начинают его разглядывать, как обезьяна гранату, перед тем как запихнуть это всё в основную ветку. Чтобы потом не было мучительно больно, когда всё на боевом сервере накрывается медным тазом.

А зачем это вообще нужно, спросишь ты? Цели, блядь, простые, как три копейки:

1. Чтобы код не был говном. Самый главный пункт, ёпта. Находим баги, дыры в безопасности и места, где всё тормозит, как старый дед на подъёме. Лучше найти косяк сейчас, чем потом в три часа ночи получать алерт, что прод упал, и волосы на жопе шевелятся.
2. Чтобы все были в курсе, кто во что горазд. Новый пацан пришёл? Пусть посмотрит, как старожилы пишут. Все пишут по-разному? Пора договориться, как правильно, а то получится пиздопроебибна из стилей. Это как передача мудрости, только без бороды и посоха.
3. Чтобы сэкономить бабки. Исправить косяк, пока он только в пул-реквесте — это как заклеить дырку в лодке на берегу. А чинить его в продакшене — это уже чинить лодку, которая тонет посреди океана, и акулы вокруг. Дороже, блядь, в овердохуища раз.
4. Чтобы архитектура не превратилась в лапшу. Один может накодить такое, что потом десять лет расхлёбывать. А когда несколько глаз смотрят — больше шансов, что кто-то крикнет: «Стой, мудак! Так делать нельзя, у нас же тут микросервисы, а не монолитная помойка!».

А теперь, чувак, как надо ревьюить, чтобы тебя не возненавидели всей командой (для ревьювера):

• Бей по коду, а не по челу. Фраза «Этот модуль — говно» работает лучше, чем «Ты — говнокодер». Понимаешь разницу? Первое — критика, второе — повод для драки в курилке.
• Не тычь пальцем, а спрашивай. Вместо «Здесь ошибка, идиот» пиши: «А что будет, если сюда прилетит null? У нас же тут NPE может выскочить, как хуй из штанов». Это наводит на мысли, а не на обиду.
• Хвали, если увидел красоту. Нашёл элегантное решение? Напиши «Красава, остроумно!» или «Ни хуя себе, я бы так не додумался». Это, блядь, мотивирует сильнее пиццы в пятницу.
• Не затягивай, как последний жмот. Если тебе закинули на ревью — посмотри в течение дня, а не через неделю. У всех терпения ноль ебать, когда их фича висит в воздухе.
• Используй чек-лист, а не интуицию. Гляди по пунктам: работает ли? Читается ли? Тесты есть? На все случаи жизни учтено? Не сломает ли оно всё к хуям?

А если ты — автор кода (тот, кого ревьюят), то:

• Дели код на мелкие куски. Присылать пул-реквест на 5000 строк — это не review, это пытка. Это как схавать целого быка за раз. Делай маленькие, атомарные PR. Их и проверить быстрее, и понять легче.
• Распиши, что ты натворил. В описании к PR не пиши «фикс». Напиши нормально: «Исправил баг с кэшированием пользовательских сессий, потому что они сбрасывались после каждого запроса. Для теста: залогинься, обнови страницу — сессия должна сохраниться». Видишь разницу? Первое — «повесил картину», второе — «повесил картину, она криво висит, потому что гвоздь косой, поправь молотком».
• Сам сначала посмотри на своё творение. Перед тем как отправить, пробегись глазами. Убери опечатки, удали закомменченный код, который ты забыл стереть. Self-review — это как посмотреть в зеркало перед выходом из дома, чтобы не выйти с торчащим хуем из ширинки.
• Отвечай на все комментарии. На каждый. Даже если не согласен. «Исправил» или «Не исправляю, потому что здесь требование было именно такое, смотри тикет JIRA-666». Молчание — знак того, что тебе похуй, а это, блядь, раздражает.

И наконец, что собственно проверяем, когда уставились в код? Работает ли оно? Понятно ли написано, или надо вызывать шамана, чтобы расшифровать? Тесты есть, или мы просто верим на слово? А что если сюда прилетит не число, а строка? А не будет ли это тормозить, если записей будет миллион?

Короче, эффективный Code Review — это не формальность и не полиция кода. Это, блядь, главный инструмент, чтобы не превратить проект в огромную, вонючую, неподдерживаемую помойку, где каждый новый фикс рождает три новых бага. Это инвестиция в то, чтобы потом не орать «Да кто это написал?!» и не находить в git blame своё же имя.