Код-ревью нужно не для того, чтобы ловить баги. И если у тебя на проекте оно про это — у вас всё плохо.

Я лет шесть ревьюил чужой код, и за это время поймал глазами ну меньше десятка серьёзных багов. Реально критичных, которые ушли бы в прод — единицы. Зато комментов наоставлял тысячи. И в какой-то момент задумался: а что я вообще делаю?

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

А вот для чего ревью реально работает:
— Размазать знание о коде по команде. Чтобы не было одного человека, который единственный знает, как устроен биллинг, и уходит в отпуск с твоей кровью на руках.
— Договориться, как мы тут пишем. Не "так правильно", а "так у нас принято", чтобы код выглядел так, будто его писал один человек.
— Передать контекст младшим разработчикам. Не "тут ошибка", а "смотри, почему так лучше".

А что происходит на практике? Приходит ревьюер и оставляет сорок комментов про пробелы, нейминг переменной i и "а давай вынесем в отдельный метод". Баг при этом спокойно проезжает мимо, потому что разглядывать бизнес-логику долго и скучно, а доебаться до foreach вместо for — быстро и приятно.

Ревью, которое превратилось в придирки по стилю — это не контроль качества, это ритуал власти.

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

👍 — Ревью должно быть про передачу знаний
🌟 — Ахахах стоп нахуй. Доебаться до пробелов это святое