Чудес не бывает или я ошибаюсь?

Если совсем коротко, то, на мой скромный взгляд, одна из самых переоцененных, но часто используемая практика, которой пытаются чего-то достичь. И как в нее не умели, так и не умеют. Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. ( Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями" ) Хотя на самом деле, в большинстве своем, у многих, она сейчас больше мешает, чем помогает. Имхо, популярность практики связана не с ее ценностью, а человеческой психологией: всегда удобно просто покритиковать кого-то. С другой стороны, ревью кода в виде обозначения "экспертиза исходного кода программы" входит в ГОСТ по безопасной разработке, что как минимум требует формальной галки проведенного ревью, как максимум ожидает настроенного процесса. То есть вроде полезная штука, в чем же подстава? Подстава в последовательности шагов ревью...

Интересная статья про инспекцию (рецензирование) кода (code review). Джим приводит интересную статистику и дает советы по тому, как не тратить время во время code review. Небольшой конспект и мои мысли . Можно не читать тут и идти сразу в оригинал. 1. Сам процесс должен быть легким. Групповое (когда назначается совещание и команда совместно смотрит код) ревью малоэффективно. Только 4% ошибок находится во время такого способа проведения инспекции. Лучше это делать по запросу по email или с помощью специальных инструментов. Тут наша горячо любимая Visual Studio отличилась. Ее возможность Code Review и так не ахти . А если вы храните ваши исходники в git-репозитории, то у вас нет даже ее. Приходится опять смотреть на сторонние инструменты. Недавно попробовали Upsource от Jetbrains работает в TFS-git. Пока завелось. 2. Сколько людей в команде надо привлекать к ревью? Джим считает, что всех приглашать не нужно - бесполезная трата денег. Некоторые исследования показывают, что разраб...

Продолжение ( часть 1 ) (с) Идея начать использовать Code Review возникла еще до перехода на TFS 2012. И в качестве первого инструмента позволяющего делать это удобно (с точки зрения самого процесса ревью) попробовали довольно экзотическую комбинацию  Crucible  &  Fihseye  (экзотическую, потому что сама по себе TFS она не поддерживает). Комбинация понравилось, но косячки все равно нашлись: Так как мы работаем в TFS в качестве системы контроля версий, то пришлось все исходники каждую ночь мигрировать в Git (хотя, естественно, это было ожидаемо).  Смотреть и анализировать изменения удобно в привычном тебе виде/инструменте. Для меня это пожалуй студия: можно перейти на реализацию метода, класса и посмотреть что-там-как. Сам процесс Code Review отделялся от среды разработки, комментарии ревью отделялись от оригинального места хранения исходников. В общем не пошло. Тем временем переход на TFS 2012 опять отложился. Посмотрев по сторонам нашли интере...

(с)  отсюда Дошли у нас наконец-то руки до миграции на TFS 2012. И сразу начали осваивать новые штуки, которые он с собой принес. Одним из таких новшеств VS/TFS 2012 является возможность проводить Code Review, как это говорится "не отходя от кассы". Первая часть этого опуса скорее о том, зачем оно (Code Review) вообще нужно. (Кому теория неинтересна, тому можно сразу сюда ). Я не буду дублировать здесь то, что и так можно найти на просторах интернета. Здесь собраны ссылки на те, показавшиеся мне интересными, ресурсы, которые я находил, пока сам изучал этот вопрос. В июне 2011 на встрече AgilePiter в офисе Яндекса мы обсуждали инженерные практики. Меня тогда сильно удивило , как много людей используют Code Review. У меня к тому времени сложилось несколько другое, скорее даже, негативное к нему отношение. Давайте попробуем разобраться. Вообще, по жизни, есть разные практики проведения Code Review: до / после check-in'ов ( плюсы - минусы каждого из подходов...

Начал разбирать свои favorites в твиттере. Нашел очень полезные советы Саши Калугина о том, как проводить Code-review, объективно и справедливо. Очень рекомендую Часть 1 Часть 2