Как вы делаете обзоры кода?

Недавно я перешел из компании с 30 разработчиками, основанных на одном и том же сайте, в меньшую компанию с 6 разработчиками, работающими по всей стране.

Раньше, когда я проводил обзоры кода, у меня был бы человек, сидящий рядом со мной, или я пошел бы к его/ее ПК и передал бы код с ними.

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

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

есть ли более простой способ сделать это? Я давно думал, что Visual Studio должна иметь мета-систему комментариев, которая даст вам аналогичные характеристики и позволит писать комментарии на более высоком уровне.

Есть ли какие-нибудь инструменты, которые это делают? Если не так, как люди собираются делать раздаточные обзоры кода?

ОТВЕТЫ

Ответ 1

Вам может понравиться прочитать книгу "Умный медведь": Лучшие секреты обзора одноранговых кодов

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

Ответ 2

Я хочу, чтобы была улучшена поддержка этого типа задач, встроенных в Visual Studio. Есть некоторые интересные надстройки, которые могут помочь. Если вы используете Visual Studio Team System, посмотрите TeamReview. Он позволяет создавать специальные рабочие элементы Code Review, которые можно "воспроизвести" кому-то позже.

Снимок экрана TeamReview http://www.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=TeamReview&DownloadId=32263

Ответ 4

У нас есть разработчики, основанные во всем мире. Мы используем Smart Bear Code Collaborator. Как любой инструмент, он не идеален, но он, безусловно, выполняет свою работу. Это основано на Интернете и легко учится.

Ответ 6

В компании, над которой я работаю, патчи, созданные через SVN, ежедневно публикуются в новостной группе. Анализ кода в реальном времени по-прежнему является наиболее эффективным способом завершения обзора, так как мы работаем над виртуальными командами с разработчиками по всему миру, когда-то невозможно, чтобы разработчик и рецензент разговаривали друг с другом.

Чтобы помочь нашим разработчикам делать обзоры, мы собрали контрольный список для проверки кода (доступно по адресу http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31).

Наш секрет отзывов по коду: обзор небольшой, часто просматривайте.

Ответ 7

http://www.review-board.org/

Я видел этот проект не так давно, возможно, его могут проголосовать, если люди его используют.

Ответ 8

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

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

Что бы я начал.

Ответ 9

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

Ответ 10

Мы были точно в одной лодке - разработчики по всей стране, не хватает времени перекрытия в течение дня... Все работали асинхронно... Поэтому нам пришлось придумать автономный инструмент для проверки кода.

Мы закончили с достаточно легким процессом: - Для любой нетривиальной части кода требуется экспертная оценка. - Чтобы выполнить проверку, автор создает "упакованный список изменений" (проверьте ваше сообщество управления версиями для такого материала). Это в основном однофайльный, расширяемый ZIP всех изменений, внесенных в этот кусок работы. - Автор отправляет электронное письмо рецензенту с упакованным списком изменений (обратите внимание, что они еще не представили его!) - Рецензент проходит через код, асинхронно, и помещает комментарии по электронной почте - Если у рецензента есть серьезные возражения, код не разрешается входить до следующего раунда обзоров; в противном случае автору разрешается регистрироваться после того, как они исправят предложения ИЛИ открывают ошибки, чтобы исправить предложения.

Ответ 11

У нас был некоторый успех с использованием функции shelveset TFS для проведения распределенных обзоров кода. Используя полки, разработчик может "проверить" набор изменений, не связывая их с веткой. Другой разработчик может затем отменить набор изменений и проанализировать разницу между обработанной ветвью. Когда все заинтересованные стороны довольны набором изменений, они отправляются в ветвь.

Ответ 12

Очень легкий процесс, который мы использовали, - это использовать Microsoft SharedView и Skype как для сеансов парного программирования, так и для проверки кода. Конечно, это не так формально, как политика регистрации, но может быть хорошим началом для разработки стандартов, прежде чем увековечить их в политике проверки.

Ответ 13

Хорошо, я расскажу вам, что делает моя компания, так как она работает хорошо для нас (около 10 разработчиков плюс PM ppl). YMMV.

Мы осуществляем управление изменениями с помощью Subversion и ClearQuest (используется для использования ClearCase, глядя на CQ). Мы делаем наши изменения, создаем файлы патчей с использованием подрывной деятельности, а затем помещаем патч в запись CQ и передаем CQ. Низкотехнологичный, но он работает. Очевидно, вы можете изменить его для работы с любым используемым приложением для продажи билетов.