Практики хорошего code review, или что такое code review за 15 минут. Доклад Никиты Соболева на DUMP в Казани

Никита на протяжении почти 40 минут пытался вскипятить мозги слушателей секции Backend, рассуждая о code review

Интересное утверждение, был готов открыть для себя что-то новое и переосмыслить настолько стандартный процесс в backend… в реальности же почти все озвученное больше относится к секции web разработки. Есть и то что применимо для «нас», но это скорей случайность и мое желание подогнать новую финтиплюшку под существующие проблемы.

Простите, но когда даже жестко настроенный статический анализатор находит в 2-3 раза меньше проблем чем я, по старинке, ручками… о какой автоматизации и ревью за 15 минут вы говорите? Да, задачи на 3-4 часа действительно можно успеть проверить за это время (и то далеко не всегда), но будем честны, намного чаще фигурируют числа 3-4 дня (не всегда имеет смысл дробить задачу на такие осколки, теряется целосность и контекст). Вы предлагаете оставить проверку кода машинам, а нам лишь окинуть взглядом нейминг переменных. Я могу ошибаться, но на мой вкус статические анализаторы еще не доросли до нужного уровня, что бы настолько им верить. Сейчас сообщения анализатора лишь помогают не пропустить какие-то особо яркие косяки, но не повзоляют проверять ТОЛЬКО те места, на которые они указали.

Действительно хорошая идея проверять импорты и выносить создание архитектуры решения в отдельный «процесс», но в целом никакого ревью за 15 минут и тем более практик хорошего ревью для крупных backend проектов, как обещал заголовок, я, увы, не вижу…

А давайте с другой стороны посмотрим на цели:

многие люди контролируют выполнение какой-то задачи при помощи code review

Захожу в патч (пулреквест), вижу описание задачи с номером на багтреке, перехожу в багтрек, вижу статус в багреке: Задача закрыта или Задача на обсуждении.
Чем не контроль выполнения?

контроль качества кода

Из быстрого, что вспоминается:
— SQL-выражения, некачественное отсеевается сразу.
— Структура SQL-таблицы: на лицо качество или ее отсутствие, когда видишь ее описание.
— JUnit тесты — задача конкретного метода тестом не покрыта.
Чем не контроль качества кода?

чтобы новички не повторяли грабли, на которые уже сто раз наступали

Не хочу никого расстраивать, но это неизбежно в проектке с легаси кодом, которому более 15 лет.
Код ревью — это второй инструмент отлова граблей, первый конечно — Слово.

многие делают code review для архитектурного review

Не встречался с таким, поэтому без комментариев

многие через code review обучают людей.

Не является целью, согласен, но как следствие — обучение через код ревью неизбежно. Будет происходить само по себе.