Если совсем коротко, то, на мой скромный взгляд, одна из самых переоцененных, но часто используемая практика, которой пытаются чего-то достичь. И как в нее не умели, так и не умеют.
Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. (Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями")
Хотя на самом деле, в большинстве своем, у многих, она сейчас больше мешает, чем помогает.
Имхо, популярность практики связана не с ее ценностью, а человеческой психологией: всегда удобно просто покритиковать кого-то.
С другой стороны, ревью кода в виде обозначения "экспертиза исходного кода программы" входит в ГОСТ по безопасной разработке, что как минимум требует формальной галки проведенного ревью, как максимум ожидает настроенного процесса. То есть вроде полезная штука, в чем же подстава?
Подстава в последовательности шагов ревью и квалификации команды. Остальное вторично.
Интуитивно: если мы делаем ревью чего-то, то мы предполагаем существование этого чего-то. То есть сначала пишем код, потом его анализируем. Потом, по комментам, код меняется и снова ревью. Кто-нибудь анализирует основные причины комментариев? Что заставляет сильно менять код? Как часто находятся проблемы? Могли бы эти проблемы найдены статическими анализаторами, линтерами и тестами (рядом с кодом)?
По моему опыту (давнему разработческому и текущему наблюдающему), если настроен автоматический анализ кода + пишутся тесты, то это намного эффективнее находит проблемы, чем глаз коллеги, особенно, если его экспертиза в разработке или доменной области решаемой кодом сильно разнятся от вашей.
Что нельзя отловить анализаторами и тестами? Ошибки проектирования (хотя считается, что юнит-тесты как-то помогают). Значит добавляем промежуточный шаг, когда разработчик предлагает сделать ревью не готового кода в 100500 изменений, а драфта возможного решения: набросок кода, схемы предполагаемого взаимодействия (data flow, межкомпонентного и тдтп). Это смотрится, обсуждается, дальше реализация, а потом уже или быстрое ревью, или только автоматизация.
Вот кажется, это единственно разумный вид процесса code review. Все остальное - бесполезная трата времени.
Полезные ссылки:
• Stop doing code reviews and try these alternatives (там хороший анализ с примерами исследований и возможных альтернатив)
• И снова про code review или новая единица измерения качества (WTF/minute) (самопис в мою бытность ревьювера)
Комментарии
Отправить комментарий