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

Я как-то давненько спорил с AndrewVK о данном вопросе...
Вот он считает что не надо, за исключением.
А я наоборот считаю что надо, за исключением. И с каждым новым проектом убеждаюсь в этом.
Процесс разработки должен быть поставлен правильно.

Здравствуйте, Aikin, Вы писали:
A>Хех, а не вы ли лично полтора года назад просили ключ на руборде? Обрадую вас: вам ответили (и довольно давно).

Э-э, не подскажети как искать, поиск по форуму по Code Collaborator не нашел
Или ссылочку если можно, пожалуйста

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

D>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, debugx, Вы писали:

D>>>И с чего вообще начать внедрение такого процесса в компании?

G>>Запретить все коммиты в репозиторий, к комменте к которому не указан ревьювер.

D>у нас subversion черепашка. Там вроде такое можно настроить, да?

Хуки там вроде есть, парни говорили. Можно.

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

DST>Ну а всем могу заявить, что пользоваться такими замечательными тулами как crucible и codecolaborator могут даже бедные. Так что не ленитесь, и добавляйте такую активность в ваши процессы.

Согласен, crucible — отличный тул, вот только интеграции с VS2008 ему не хватает. Я спросил про это на их форуме, оказывается, реквест уже был создан — если кто-то заинтересован, проголосуйте за него.

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


B>можно я тут мелкую ремарочку?..

B>Здравствуйте, SEDEGOFF, Вы писали:
SED>>Поставьте эксперемент на двух сотрудниках — слабом и сильном. Замерьте — что измениться.

B>вот тут я хотел бы заметить, что не проверка "сильным" — "слабого" (а кто их определяет?!..), а проверка "любым — любого".

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

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

You will always get what you always got
  If you always do  what you always did

D>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом???

Поделюсь своим опытом.

Раньше я клемил кодеревью на чём свет стоит. Раньше я и работал в проектах 7-10 человек и Agile работал за глаза. Ревью не нужно было, так как совместное проектирование, использование Simple Design, юнит тестирование и другое делали своё черное дело. В общем я был убежденный анти-ревьюер.

Сейчас я работаю в проекте. Которые и проектами не назовёшь. Много заказов, много мелких и крупных исполнений. Много вещей передаётся во вне из компании. Помимо этого я и сам веду разработку. В этой повышенной многообразием проектов, людей и мнений ловине информации существуют управляющие гайдлайны, руководства и т.п. с целью стандартизации работы. Но так как людей очень много и каждый раз они перегруппируются под различные проекты. То выдерживать какой-то не то чтобы стиль оформления кода, а некоторый общий подход к разработке очень сложно.

Поэтому фаза ревью стала обязательной, и она может занимать от 30% до 100% времени на разработку. А так как все меняются, ротируются как в плане разработки, так и в плане peer review, то это становится очень мощным механизмом "не задокумментированного стандарта", некоторого общего по больнице.
И самое мощное, мы проводим ревью не стиля оформления (это не очень важно, поэтому разные Code&Style-конвенции отдыхают), а именно смысла вносимых изменений и предлагаемых решений.

Для себя я нашёл в этом следующие положительные моменты:
1. Я контролирую куда в общем приложение двигается на уровне кода и фич, это позволяет развить экспертизу в тех областях приложения, где я тум-тум
2. Повод поворить с людьми. Часто узнаешь трики, либо решения, до которых сам бы не дошёл, а иногда возникают противоречия — а решение их способствует формированию "командной интуиции к стандарту" взамен спущенной сверху уродливой кодеИнэйминг конвенции
3. Действительно исключаются ошибки и код становится проще после ревью. Так как мы проводим ревью не стиля, а смысла.

Вывод такой:
1. Если проект не большой — эта фаза не нужна, достаточно общего владения кодом
2. Если проект большой (в моём ядро проекта за сотни человек) — это хорошее дополнение к таким практикам, как юнит тестирование, коллективное владение и т.п. Так как цена ошибки в таких проектах оооооооочень дорогая.