Code review в Visual Studio 2012 - часть 1

(с) отсюда

Дошли у нас наконец-то руки до миграции на TFS 2012.
И сразу начали осваивать новые
штуки, которые он с собой принес.

Одним из таких новшеств VS/TFS 2012 является возможность проводить Code Review, как это говорится "не отходя от кассы".

Первая часть этого опуса скорее о том, зачем оно (Code Review) вообще нужно. (Кому теория неинтересна, тому можно сразу сюда). Я не буду дублировать здесь то, что и так можно найти на просторах интернета. Здесь собраны ссылки на те, показавшиеся мне интересными, ресурсы, которые я находил, пока сам изучал этот вопрос.

В июне 2011 на встрече AgilePiter в офисе Яндекса мы обсуждали инженерные практики. Меня тогда сильно удивило, как много людей используют Code Review. У меня к тому времени сложилось несколько другое, скорее даже, негативное к нему отношение. Давайте попробуем разобраться.

Вообще, по жизни, есть разные практики проведения Code Review:

• до / после check-in'ов (плюсы - минусы каждого из подходов)
• участвует вся команда / только один человек, как правило менеджер или роль переходит
• если участвует вся команда, то ревью по отдельности / митинги 
• обязательно / по желанию / как получится

И так далее.

Также существует много мнений на тему пользы самого Code Review.

(c) proof

Mark Seemann (автор многих интересных книг про программированию) считает, что code review убивает процесс творчества. Хмм, творчество то у нас должно быть созидательным, а плохо/неправильно работающий код скорее деструктивен. Так что это или сарказм, или..., или мой английский недостаточно хорош? ;)

Отдельно проскакивала интересная статистика по коллегиальному code review (формат в виде митинга). Такой формат позволяет найти дополнительные 4% к проблемам уже найденным при индивидуальном ревью. Зато эти проблемы самые "хитрые" и сложно обнаруживаемые.

Еще пару интересных, на мой взгляд, размышлений на этот счет: "Code Review is not about..." и Code Reviews Mindmap

(с) Tomek Kaczanowski

Хорошая инструкция к Code Review на GitHub, а именно к тому, как именно писать комментарии, как правильно настроить себя на получение позитива от процесса.

Также мне понравилась статья из 2-х частей про процесс Code Review от Саши Калугина. Там как раз и про объективность / субъективность, и про проблемы, которые могут возникать в процессе.

Итого, будем исходить из того, что:

• Code Review должно помогать, а не мешать
• Это сложно
• Но возможно :)

Мы все же оптимисты и решили попробовать, а там видно будет насчет пользы-вреда-бесполезности.

Продолжение...