Разочарование в ревью кода

На протяжении последних нескольких лет я довольно активно пропагандировал ревью кода. Когда я только пришёл в компанию, в том отделе, куда меня взяли, не применялся даже git, а о ревью кода и вовсе не слышали. Так что первым решением было внедрение gitlab и настройка процессов по git-flow. В общем-то отделом это было назвать трудно, 2 человека. При этом просмотр кода позволял держать проекты под контролем. Потом начался другой проект и ещё. Все проекты были небольшие и с коротким развитием. По факту через месяц–полтора активная разработка заканчивалась и начиналась поддержка. И вот начался новый большой проект.

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

Перепроектирование после реализации

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

Решение? В первом случае надо поднимать уровень разработчика или снижать уровень задач для него, либо проектировать решения вместе с ним. В этом случае мне нравится подход парного программирования, недолгие сессии позволяют быстро синхронизировать видение хорошего кода и хороших решений. А вот второй случай говорит лишь о плохой архитектуре системы, раз правильное решение в ней неочевидно. Но при подходе с ревью кода мы начинаем лечение в последней стадии. Как итог человек дважды делает задачу, при этом правильное решение не откладывается у него в голове ведь это не его решение, а ревьювера.

Отсутствие контекста

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

Решение? Последнее время я просто начал звать разработчика, чтобы смотреть его код вместе с ним, чтобы он рассказал про то как и что он сделал. Это увеличивает потраченные на ревью человеко-часы ещё больше, но зато не приходится гадать на диффах. Может подумать над системой описания своих решений в коммитах, так чтобы уже после слития всего этого в общую ветку, можно было вспомнить почему, что и как было сделано.

Тесты на ревью

Просматривать тесты — самое сложное во всём процессе ревью. Довольно часто логика тестов получается достаточно сильно размазана: фикстуры, подготовка, моки и стабы — всё это раскидано по разным местам и оценить как повлияет изменение в одном из этих мест на другие очень тяжело. Ну, и отношение к тестам, что это не основная логика системы, приводит к тому, что тесты попросту пропускаются. А порой получается так, что из-за неправильно изменённых тестов деградирует старый функционал.

Ссоры и обиды

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

Снобизм и элитарность

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

Я не знаю куда двигаться дальше, но куда-то двигаться надо, это я знаю точно. Те задачи, решение которых я возлагал на ревью, надо решать совершенно другими способами. Тогда для чего же нужен ревью?