Код-ревью сейчас стало одним из традиционных процессов в разработке софта, смысл которого, как это часто бывает, несколько размылся. Кто-то ставит основной целью отлов багов, кто-то - стандартизацию стиля кода в проекте, кто-то - безопасность, или какие-то еще вещи; чаще всего хочется всего и сразу.
Все исходят из посылки, что чем больше глаз посмотрит участок кода, тем меньше вероятность того, что в нем проскочит что-то некорректное - по логике, стилю или чему-то еще. Это выглядит логичным, но потом сюда подключаются вещи вроде взаимоотношений в команде, нехватки рабочего времени и размытых целей, и итоговый результат получается куда более слабым, чем он мог бы быть.
В статьях ниже рассказывается о том, как улучшить ваши личные навыки ревью, как лучше организовать этот процесс в проекте и как сделать его полезным для всех участников.
- Чем вообще полезно ревью и какими простыми вещами можно поднять его качество на уровне каждого разработчика.
- Общие советы по ревью. Здесь всего понемногу - и технического, и коммуникационного.
- Чеклист того, о чем в принципе стоит задумываться при ревью с технической точки зрения.
- Большой текст о подходе к коммуникации в ревью, который снижает частоту подгорания стульев в команде.
- Распространенные проблемы при код-ревью, как личные, так и организационные.
- Почему единоличное владение кодом плохо.