САБЖ.
Может тут обсуждалось, но я не нашла.
В общем инетресна практика по этому вопросу. У кого делается, если как то какой механизм. Я была свидетелем только неудачного опыта в эом вопросе. Делитесь удачным или соображениями нужно ли это 

Нельзя ли поподробнее?

В плане подтягивания новичков - полезно, а так - сомневаюсь...

Ни фига себе - подтягивание новичков...

Это одно из главных премуществ команды, которое надо использовать. Один программист может написать и продумать много чего, но по своему опыту работы - с помощью code review код "вычищается" и оптимизируется по самое не хочу.

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

Гм. Системный аналитик предложил раз в неделю проводить коде ревью. Был составлен график по дням, в понедельник у одного, во вторник у дрого и т.д. Собералося человек (чей код смотрели), этот самый сис. аналитик, + руководитель проекта и возможно еще пару заинтересованых лиц. КПД от занятия было 0-е, через месяц дело угасло.

Из положительного опыта, эта работа в паре, т.е. кодеревью делается одновременно с написанием. ИМХО на начальных стадиях написания кусков, например на закладке интерфейсов, ИМХО лучше работать в паре, но не везде руководство привествует такой подход.

Вопрос в общем-то не праздный. С одной стороны, кодеревью явно нужно, с другой я не совсем вижу как это правильно организовать.
  - положительный


JackYF, ты бы описал сам процесс, как это видешь. а? плиз.

хм, неудивительно. Я бы тоже был против такой системы.


Вижу так:

Во-первых, рекомендуется использовать систему контроля версий кода, напр. cvs, svn или еще какую. Которая хранит общий репозитарий, следит за всеми изменениями в коде - кто, что, когда, где и т.д.
Так вот. Когда надо написать/изменить/переработать кусок кода, один или два человека берут и какое-то пишут код, тестируют его сами. Потом дают отмашку - я выполнил задачу. После этого люди, которые посвободнее сейчас, прямо в этот момент идут и вместе с человеком просматривают его код. По одному, не все скопом.

Каждый, кто делает такое code review, делает несколько замечаний по коду. Автор опять садится, исправляет ошибки и неточности. Подходит другой человек, делает свои замечания. Когда, наконец, ни у кого не осталось претензий к коду, код автором коммитится - добавляется в общую систему.

Итог из этого: code review, имхо, должен проводиться во время написания кода. Бессмысленно делать review кода, который писался неделю назад.

В целом, описанный вариант мне понравился. Чем-то похоже на парное программирование.

Для опытных программистов - да, а для новичков и через неделю есть смысл просмотра кода.

Код за неделю забывается всеми - и новичками, и профессионалами... зачем делать review через неделю, если можно прямо сейчас, когда код только написан и свеж в памяти?

JackYF, невижу преймуществ такого подхода перед банальным парным программированием. На чтение кода человеком, который будет делать ревью уйдет столько же времени сколько на его написание :( 

JackYF, интересное видение. 

В таком случае и я опишу свой "опыт"(хотя изначально не был уверен, что он напрямую относится к code review). 
Навеяно фразой:

Над кодом я работаю в одиночку. Коммиты в репозиторий(Subversion) стараюсь делать, только тогда, когда реализуемая/исправляемая функциональность в коде приобретает завершённый вид. В среднем получается где-то раз в три дня, раз в неделю. Так вот, перед каждым коммитом просматриваю код чтобы:
1) толково описать изменения которые я сделал
2) убедится что не осталось лишних закомментированных блоков кода
3) новый код оформлен в соответствии со стандартом(в данном случае моим персональным  )

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

Добавлено через 5 минут и 50 секунд
Вот, ещё в тему одна любопытная статья от not a kernel guy описывающая пользу code review и другая не менее полезная от Alex Lebedev. 
Настоятельно рекомендую к ознакомлению.  

Ну, во-первых, за неделю он полностью редко забывается. И даже за месяц не всегда.
А по поводу "зачем через неделю, если можно сейчас" - так не всегда оно того, "можно сейчас".
Понимаешь, тут совсем разные причины для просмотра кода. В случае опытных людей мы имеем больше попытку улучшить код и стандартизировать его, чем попытку научить каждого писать правильно - то, что в одном случае правильно, в другом может оказаться невыгодным или вообще неуместным.
В случае же новичков код полезно просматривать, чтобы в целом направлять их развитие. Далеко не каждый новичёк в состоянии быстро самостоятельно разобраться, что и как стоит делать, а что не стоит и почему. Вот тут-то и поможет просмотр кода с комментариями "почему и как лучше".


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

нет. Парное программирование само по себе неплохо и может применяться. Основываясь на реальном опыте, говорю, что на code review тратится на порядок меньше времени, чем на его написание.



вот, отлично. Это тоже делается автором и проверяющими на завершающей стадии code review.



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



+1. Хорошо объяснил.

Ну, я по крайней мере многое помню. Хотя, ты прав - это сильно индивидуально и зависит не только от человека, но и от окружающей обстановки. Если меня сильно загрузить какой-то проблемой, то предыдущий код может быть забыт уже на следующий день. При просмотре я что-то вспомню и ещё узнаю свой код, но кое-что может уже вызвать вопросы.


Стараемся зарабатывать одобрение.  Мы его любим   

Николай ІІ?