Comments 22
А могли бы вы привести статистику о том сколько времени тратится у вас в компании на ревью и субъективную оценку эффективности, т.е. как хорошо оно окупается?
Первый раз начали заниматься review мы где-то чуть больше года назад. Сначала смотрели изменения с помощью обычного diff в Tortoise SVN, затем поставили crucible + fisheye для проведения review. Но этот инструмент оказался неэффективным (это не значит, что он плохой), потому что мы не могли применить результаты review. Отчасти это было связано с тем, что исправления по результатам review не делались, либо их вносить было поздно (продукт уже проходил финальное тестирование и вносить изменения в код уже было нельзя). Так мы мучились в течении 2-3 месяцев, потом забросили это дело.
Недавно мы вернулись к практике review и как раз начали с тематических review: проводили анализ существующего кода, изменяли его, писали на него автотесты. Тематические review здорово помогают, мы находили большое количество ошибок (мы делали его сидя вместе за одним компьютером), также появилось небольшое понимание, как это должно работать.
Сейчас мы решили внедрить code review как необходимый элемент итерации в нашем Scrum, и также прикрутить к CI серверу проверку на пройденный review перед сборкой дистрибутива. Так что я думаю, что у нас должно получиться во второй раз.
С точки зрения эффективности — это безусловно эффективно, даже с учетом нашего небольшого опыта в review.
Недавно мы вернулись к практике review и как раз начали с тематических review: проводили анализ существующего кода, изменяли его, писали на него автотесты. Тематические review здорово помогают, мы находили большое количество ошибок (мы делали его сидя вместе за одним компьютером), также появилось небольшое понимание, как это должно работать.
Сейчас мы решили внедрить code review как необходимый элемент итерации в нашем Scrum, и также прикрутить к CI серверу проверку на пройденный review перед сборкой дистрибутива. Так что я думаю, что у нас должно получиться во второй раз.
С точки зрения эффективности — это безусловно эффективно, даже с учетом нашего небольшого опыта в review.
В последние лет пять считаю очень удобной нотификацию о коммитах по электронной почти.
Для SVN использовали search.cpan.org/dist/SVN-Notify/lib/SVN/Notify/HTML/ColorDiff.pm
Для Git использовали github.com/bitboxer/git-commit-notifier (недавно начали использовать доработанные нотификации Gitorious, но мне они не нравятся).
Для SVN использовали search.cpan.org/dist/SVN-Notify/lib/SVN/Notify/HTML/ColorDiff.pm
Для Git использовали github.com/bitboxer/git-commit-notifier (недавно начали использовать доработанные нотификации Gitorious, но мне они не нравятся).
Статья не плохая. Ещё о code review я бы порекомендовал почитать в «Code complete» (Глава 21).
P.S. А что значит VCS? Может CVS?
P.S. А что значит VCS? Может CVS?
Можно проводить code review разными способами — дистанционно, когда каждый разработчик сидит за своим рабочим местом, и совместно — сидя перед монитором одного из коллег, либо в специально выделенным для этого месте, например meeting room.
В этом вся статья. Не густо :(.
Особенно полезным получился раздел «Утилиты для review» %)
Эта статья безусловно не претендует на полноценное описание всей практики, скорее это чисто субъективное мнение на основе небольшого опыта, упорядочивание собственных знаний.
Можете порекомендовать литературу по code review? Я могу расширить статью дополнительной информацией.
Можете порекомендовать литературу по code review? Я могу расширить статью дополнительной информацией.
Мы для ревью кода используем платный Code Collaborator. Он поддерживает большинство распространённых систем контроля версий.
Весьма довольны :)
Весьма довольны :)
В продолжение темы предлагаю мою заметку, что такое "статический анализ кода". Он рассматривается как автоматизированный процесс обзора кода.
Мы пробовали использовать статический анализатор кода pvs, но к сожалению msvc — не основная среда разработки (пишем время от времени), и поэтому как-то не прижался у нас этот инструмент, возможно с другими анализаторами больше повезет. Кстати, возможно прикрутить pvs studio к CI серверу?
PVS-Studio можно использовать из командной строки без .sln файла (http://www.viva64.com/ru/d/0007/), а если есть .sln файл, то проверка из командной строки совсем простая (http://www.viva64.com/ru/d/0001/).
Пишите, если будут вопросы по интеграции.
Пишите, если будут вопросы по интеграции.
Сорри за офф, но уж сильно мне запомнилось фото: вот этих двух парней как раз засняли когда они делали code review
Как-то через статью неявно проходит мысль, что анализ кода должен производить не тот, кто его писал? Это обязательное условие?
Используем мердж реквесты в Gitorious для ревью кода. Гибкий и удобный инструмент. Рекомендую.
Sign up to leave a comment.
Еще одна статья о code review