Здравствуйте, Пацак, Вы писали:

K>>Поэтому результат может быть и в десять раз.
П>А может и не быть. Все зависит от того, что именно команда понимает под "хорошим кодом" и насколько харизматичен ее член/тимлид, который это понимание сумел пропихнуть в качестве общепринятого.
П>PS Это я не к тому, что code review не нужен, боже упаси. Просто оно, как и прочие методики, нифига не серебрянная пуля. А значит фигня эти хабровские вероятности и прочая математика — при разных условиях количество багов после их внедрения может как сокращаться, так и расти.

скажу за свой опыт.
у нас было 6 человек(включая меня), которые вели ревью друг у дружки перед коммитом.
введено это было после понимания, что слишком много появлялось мелких багов. реально невнимательность и недопонимание постановки задачи.
ревьювер помимо проверки логики работал так же "дебажной уточкой". т.е. автор рассказывал ему что и почему делал. подобная исповедь позволяла заново переосмыслить написанное и обнаружить запрятанную ошибку. ревью поэтому проводился любым членом команды, а не "опытным" над "новичком".
команда была собрана из совсем новичков, поэтому осилить большое количество кода было сложно. отсмотр чужого кода давал большее представление о системе.

в результате количество багов снизилось, новички стали хорошо разбираться и принимать собственные здравые решения.
для таких команд оно работает.

П>Единственное, что дает по-настоящему результат в команде — это опыт ее участников, остальное все — это уже специи.

опытных людей сложнее направлять. не все готовы подстраиваться под других.
всё-таки опыт != профессионализм (а тут много чего притягивается в этот термин)

я думаю, что ревью в первую очередь нужно исполнителю, а не проверяющему.
и у тимлида поэтому возникают задачи объяснить полезность и снизить связность между человеком и его кодом.