Недавно я перешел из компании с 30 разработчиками, основанных на одном и том же сайте, в меньшую компанию с 6 разработчиками, работающими по всей стране.
Раньше, когда я проводил обзоры кода, у меня был бы человек, сидящий рядом со мной, или я пошел бы к его/ее ПК и передал бы код с ними.В моей новой компании это невозможно, поскольку люди повсюду. Мне передали пару тысяч строк кода, и я не могу просто сказать кому-то свои мысли.
Единственный способ, которым я могу думать, - написать документ для обзора кода. Поэтому я прибегал к вставке кода в Word и аннотации его, используя небольшие пузырьки, которые вы получаете.
есть ли более простой способ сделать это? Я давно думал, что Visual Studio должна иметь мета-систему комментариев, которая даст вам аналогичные характеристики и позволит писать комментарии на более высоком уровне.
Есть ли какие-нибудь инструменты, которые это делают? Если не так, как люди собираются делать раздаточные обзоры кода?
Вам может понравиться прочитать книгу "Умный медведь": Лучшие секреты обзора одноранговых кодов
Это бесплатно (включая доставку, если вы находитесь в США), поэтому мало причин не получить его. С другой стороны, это отличная небольшая книга с примерами реального мира о том, как лучше всего делать обзоры с кодовым кодом, поэтому есть множество причин для ее заказа.
Я хочу, чтобы была улучшена поддержка этого типа задач, встроенных в Visual Studio. Есть некоторые интересные надстройки, которые могут помочь. Если вы используете Visual Studio Team System, посмотрите TeamReview. Он позволяет создавать специальные рабочие элементы Code Review, которые можно "воспроизвести" кому-то позже.
Ознакомьтесь с предложениями по этому вопросу:
https://stackoverflow.com/questions/403/tool-to-aid-code-review
У нас есть разработчики, основанные во всем мире. Мы используем Smart Bear Code Collaborator. Как любой инструмент, он не идеален, но он, безусловно, выполняет свою работу. Это основано на Интернете и легко учится.
Есть инструмент: http://www.smartbear.com/codecollab.php
В компании, над которой я работаю, патчи, созданные через SVN, ежедневно публикуются в новостной группе. Анализ кода в реальном времени по-прежнему является наиболее эффективным способом завершения обзора, так как мы работаем над виртуальными командами с разработчиками по всему миру, когда-то невозможно, чтобы разработчик и рецензент разговаривали друг с другом.
Чтобы помочь нашим разработчикам делать обзоры, мы собрали контрольный список для проверки кода (доступно по адресу http://www.macadamian.com/index.php?option=com_content&task=view&id=27&Itemid=31).
Наш секрет отзывов по коду: обзор небольшой, часто просматривайте.
Я видел этот проект не так давно, возможно, его могут проголосовать, если люди его используют.
Если возможно, начните с тестовых случаев - попросите человека пройти вас через тестовые примеры. Он показывает дизайн и то, что думал разработчик, решило проблему (проблемы). Погрузитесь в тестовые примеры и посмотрите на код.
Кроме того, взгляните на отчеты о покрытии кода, созданные автоматически из сборки. Это может быть хорошая метрика на тестовых путях.
Что бы я начал.
JIRA имеет возможность назначить кого-то для проверки кода вашей работы, он может дать комментарии в JIRA.
Мы были точно в одной лодке - разработчики по всей стране, не хватает времени перекрытия в течение дня... Все работали асинхронно... Поэтому нам пришлось придумать автономный инструмент для проверки кода.
Мы закончили с достаточно легким процессом: - Для любой нетривиальной части кода требуется экспертная оценка. - Чтобы выполнить проверку, автор создает "упакованный список изменений" (проверьте ваше сообщество управления версиями для такого материала). Это в основном однофайльный, расширяемый ZIP всех изменений, внесенных в этот кусок работы. - Автор отправляет электронное письмо рецензенту с упакованным списком изменений (обратите внимание, что они еще не представили его!) - Рецензент проходит через код, асинхронно, и помещает комментарии по электронной почте - Если у рецензента есть серьезные возражения, код не разрешается входить до следующего раунда обзоров; в противном случае автору разрешается регистрироваться после того, как они исправят предложения ИЛИ открывают ошибки, чтобы исправить предложения.
У нас был некоторый успех с использованием функции shelveset TFS для проведения распределенных обзоров кода. Используя полки, разработчик может "проверить" набор изменений, не связывая их с веткой. Другой разработчик может затем отменить набор изменений и проанализировать разницу между обработанной ветвью. Когда все заинтересованные стороны довольны набором изменений, они отправляются в ветвь.
Очень легкий процесс, который мы использовали, - это использовать Microsoft SharedView и Skype как для сеансов парного программирования, так и для проверки кода. Конечно, это не так формально, как политика регистрации, но может быть хорошим началом для разработки стандартов, прежде чем увековечить их в политике проверки.
Хорошо, я расскажу вам, что делает моя компания, так как она работает хорошо для нас (около 10 разработчиков плюс PM ppl). YMMV.
Мы осуществляем управление изменениями с помощью Subversion и ClearQuest (используется для использования ClearCase, глядя на CQ). Мы делаем наши изменения, создаем файлы патчей с использованием подрывной деятельности, а затем помещаем патч в запись CQ и передаем CQ. Низкотехнологичный, но он работает. Очевидно, вы можете изменить его для работы с любым используемым приложением для продажи билетов.