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

Продолжение ( часть 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'ов ( плюсы - минусы каждого из подходов...