Еще одна статья о code review

[@Akson87]

А могли бы вы привести статистику о том сколько времени тратится у вас в компании на ревью и субъективную оценку эффективности, т.е. как хорошо оно окупается?

[@prograholic]

Первый раз начали заниматься review мы где-то чуть больше года назад. Сначала смотрели изменения с помощью обычного diff в Tortoise SVN, затем поставили crucible + fisheye для проведения review. Но этот инструмент оказался неэффективным (это не значит, что он плохой), потому что мы не могли применить результаты review. Отчасти это было связано с тем, что исправления по результатам review не делались, либо их вносить было поздно (продукт уже проходил финальное тестирование и вносить изменения в код уже было нельзя). Так мы мучились в течении 2-3 месяцев, потом забросили это дело.

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

Сейчас мы решили внедрить code review как необходимый элемент итерации в нашем Scrum, и также прикрутить к CI серверу проверку на пройденный review перед сборкой дистрибутива. Так что я думаю, что у нас должно получиться во второй раз.

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

[@akzhan]

В последние лет пять считаю очень удобной нотификацию о коммитах по электронной почти.

Для SVN использовали search.cpan.org/dist/SVN-Notify/lib/SVN/Notify/HTML/ColorDiff.pm

Для Git использовали github.com/bitboxer/git-commit-notifier (недавно начали использовать доработанные нотификации Gitorious, но мне они не нравятся).

[@TimReset]

Статья не плохая. Ещё о code review я бы порекомендовал почитать в «Code complete» (Глава 21).
P.S. А что значит VCS? Может CVS?

[@0leGG]

Version Control System, вроде бы общеупотребительный термин

[@grigoryvp]

Можно проводить code review разными способами — дистанционно, когда каждый разработчик сидит за своим рабочим местом, и совместно — сидя перед монитором одного из коллег, либо в специально выделенным для этого месте, например meeting room.

В этом вся статья. Не густо :(.

[@m_z]

Особенно полезным получился раздел «Утилиты для review» %)

[@grigoryvp]

Ссылки неплохие, но там тоже общие слова вида «оно есть, потому что если оно не будет есть — оно сдохнет от голода». Я уже года три с code review сношаюсь работаю, и могу точно сказать — штука чуток посложнее, чем «есть такая фигня, ей еще в микрософте пользуются иногда» :).

[@prograholic]

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

Можете порекомендовать литературу по code review? Я могу расширить статью дополнительной информацией.

[@grigoryvp]

Слишком молодая дисциплина, хорошая литература отсутствует как класс. Теоретически, немного информации можно подчерпнуть из инструкций и форумов к Klin, Code Collaborator, ReviewBoard. Но у них пока тоже продвижение на ощупь.

[@Shedal]

Мы для ревью кода используем платный Code Collaborator. Он поддерживает большинство распространённых систем контроля версий.
Весьма довольны :)

[@Andrey2008]

В продолжение темы предлагаю мою заметку, что такое "статический анализ кода". Он рассматривается как автоматизированный процесс обзора кода.

[@prograholic]

Мы пробовали использовать статический анализатор кода pvs, но к сожалению msvc — не основная среда разработки (пишем время от времени), и поэтому как-то не прижался у нас этот инструмент, возможно с другими анализаторами больше повезет. Кстати, возможно прикрутить pvs studio к CI серверу?

[@Andrey2008]

PVS-Studio можно использовать из командной строки без .sln файла (http://www.viva64.com/ru/d/0007/), а если есть .sln файл, то проверка из командной строки совсем простая (http://www.viva64.com/ru/d/0001/).

Пишите, если будут вопросы по интеграции.

[@darkpashka]

Сорри за офф, но уж сильно мне запомнилось фото: вот этих двух парней как раз засняли когда они делали code review

[@truezemez]

Напомнило:

[@Aesthete]

RFC 1149? Отличный выбор.

[@prograholic]

Я рад что вы заметили)

[@VolCh]

Как-то через статью неявно проходит мысль, что анализ кода должен производить не тот, кто его писал? Это обязательное условие?

[@prograholic]

В этом и есть вся суть code review, потому что автор кода относится к свому коду предвзято (грубо говоря, он его считает правильным, идеальным), поэтому задача коллег — сделать этот код еще лучше: указать на опечатки, ошибки, подсказать более правильный путь решения.

[@Leproza]

Когда мы совсем зеленые были, для нас Code Review проводили полуанонимно — не говорили, кто автор анализируемого кода. Все на равных обсуждали. Автора можно было определить лишь по красному от стыда лицу.

[@Xobb]

Используем мердж реквесты в Gitorious для ревью кода. Гибкий и удобный инструмент. Рекомендую.