Терпеть не могу код ревью (2/4) - Цели

Итак, первая попытка в код-ревью прошла ужасно: мы сорвали сроки, много времени решали, как правильно писать код, а как - нет, и настроение в команде было напряженное.

Мы собрались на разбор полетов, и каждый высказал свое видение, почему наш опыт был неудачным. Вдруг кто-то спросил: “Мы столько времени потратили, сорвали сроки, перессорились, может, нам вообще не проводить ревью?”. Вопрос встретила тишина, потому что за всеми спорами мы забыли про цели, которые мы преследуем, внедряя код-ревью.

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

Мы выбрали три основные долгосрочные цели, которые покрывают конкретные боли. Их было озвучено гораздо больше, но некоторые из-за специфики продукта мы отклонили или объединили в общие. Вероятно, в другой команде, на другом проекте они будут несколько отличаться.

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

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

Чтобы писать код так, как принято в команде, мы завели отдельную страничку в confluence (вики) и верхнеуровнево описали наш подход и ключевые моменты, на которые стоит обратить внимание + расшарили на всех настройки IDE и почти выровняли правила для линтеров между проектам.

✅ Команда знает, что происходит в проекте
Зачем нужна эта цель: снижение скорости роста кодовой базы, понимание взаимосвязи компонентов и корректная оценка трудозатрат при планировании.

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

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

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

✅ Находить лучшее решение совместно
Зачем нужна эта цель: уменьшение багов, снижение техдолга, обучение сотрудников.

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

Кто-то прошарил работу библиотеки - подсказал коллеге, почему лучше использовать другой метод. Кто-то шагнул вперед и видит, что реализованное решение не выдержит масштабирования - предложил и объяснил свое решение.

Это позволяет как совместно обучаться (причем не только ревьюверу и разработчику, но и наблюдателям), так и исправлять баги до того, как QA начнет искать их.

———————————————————————

Казалось бы, зачем эти цели, кто еще не знает, для чего нужно ревью? Для синхронизации. Без определения того, что мы ждем в результате введения процесса, нам было сложно договориться о том, на что мы смотрим в ходе проверки: что важно, а что второстепенно - у каждого свое видение.