Расскажите, как был организован процесс код-ревью в вашей команде?

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

1. Как всё было организовано, или «Без бумажки ты — какашка»

• Инструменты: Всё крутилось вокруг Pull/Merge Requests (PR/MR) в GitLab. Всё, что сделал, — сразу в ветку и на ревью. Никакого тайного слива кода в main под покровом ночи, нахуй.
• Железные правила: Чтобы твой PR смержился, нужно было пройти через два чистилища:
  1. Получить два апрува от коллег. Не «ой, ок», а именно апрув. Один мог быть от тимлида, второй — от любого другого разраба.
  2. Чтобы CI/CD пайплайн был весь зелёный. Если линтер ругается, тесты падают или сборка ломается — всё, иди чини, пока не загорится, как ёлка на Новый год. Никаких «ой, да это мелочь, я потом».

2. На что конкретно смотрели, или «Чек-лист для параноика»

Когда открываешь чужой PR, глаза разбегаются. Мы смотрели вот на эту хуйню:

• А оно вообще работает? Решает ли код задачу, или чувак накодил какую-то дичь, которая только в его голове логична?
• Можно это прочитать без бутылки? Читаемость — это святое. Если видишь трёхэтажную тернарку или функцию на 200 строк — сразу вопрос: «Мужик, ты это сам через неделю поймёшь?».
• Стиль: За этим следил не только я, но и go fmt с golangci-lint в пайплайне. Автоматика — наш друг, она не устаёт и не злится.
• Тесты, ёбушки-воробушки! Критичная логика должна быть покрыта. Цифра >80% покрытия была не пустым звуком. PR без тестов на новую логику — это как идти по охуенно тонкому льду: вроде прошёл, но чувствуешь себя идиотом.
• Ошибки: Если видишь err и следом // TODO: handle error, то сразу волнение ебать. Ошибки нужно обрабатывать, а не забивать хуй, иначе потом ночью разбудит пейджер.
• Не тормозит ли? В «горячих» участках смотрели, нет ли лишних аллокаций памяти или квадратичных алгоритмов там, где можно за O(n).
• Безопасность: Нет ли прямого подставления строк в SQL или работы с юзер-инпутом без валидации. Чтобы не получилось, что через месяц вас взломают через какую-нибудь '; DROP TABLE users;--.

Вот, например, типичный комментарий в ревью, чтобы не быть голословным:

// Комментарий в ревью:
// Предлагаю здесь использовать errors.Is() вместо прямого сравнения.
// Это более гибкий подход, который будет работать с обернутыми ошибками.

// if err == io.EOF { ... }          // Так не стоит делать
if errors.Is(err, io.EOF) { ... } // А так — отлично

3. Культура, или «Как не послать коллегу нахуй в процессе»

А вот это, блядь, самое важное. Технические штуки — это полдела.

• Конструктив, а не унижение: Замечание должно звучать как «Эй, тут можно сделать вот так, будет надёжнее/быстрее/понятнее», а не «Чё за хуйню ты написал, идиот?». Разница, понимаешь, огромная.
• Уважение: Все мы люди, все иногда косячим. Тон должен быть рабочим, а не снобским.
• Учим друг друга: Ревью — это не только контроль, но и способ прокачаться. Часто в комментариях кто-то делился ссылкой на статью или показывал классный приём — это бесценно.
• Не тяни резину: Было негласное правило — посмотреть PR в течение рабочего дня. Сидеть неделю и ждать, пока кто-то соблаговолит глянуть твою работу, — это пиздец как демотивирует. Терпения ноль ебать.

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