Надо ли ревьюить код

Вообще, все споры про то, надо ли ревьюить весь AI-generated код, на мой взгляд, довольно бессмысленны. Разговор стоит вести на другом уровне абстракции – нужен ли в целом процесс code review, вне зависимости от того, кто этот код написал.

И вот об этот вопрос копий сломано уже бесконечность, в том числе в нашем канале. Я придерживаюсь того же самого взгляда, что и автор статьи:

👉Чтобы уменьшить фидбэк луп о том, что в техническом решении что-то не так, процесс ревью надо уводить налево, сильно до того, как написана хоть одна строчка продакшн кода, и заменять на дизайн-ревью.
👉Если надо обеспечить передачу знаний о какой-то подсистеме, то лучше сработает сеанс парного программирования, или хотя бы разбора кода вместе.
👉Для обучения джунов есть гораздо более рабочие механизмы – то же парное программирование, или коллективные брейнштормы у доски.
👉Аналогично и для выращивания командного овнершипа, и для выравнивания по архитектуре – чтение кода на PR для этого тоже очень плохой инструмент.

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

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