Когда делать Code Review

Недавно мы перешли к скрам-процессу и работаем над задачами и пользовательскими историями внутри спринтов. Мы хотели бы делать обзоры кода часто, чтобы сделать их менее пугающими. Мы думаем, что делаем их на уровне истории пользователя, но не уверены, как разветвить наш код, чтобы учесть это.

Мы используем VS и TFS 2010, и мы команда из 6 человек.

В настоящее время мы разрабатываем функции, но работаем над переходом на ветку для Scrum.

В настоящее время мы не используем полки и не хотим их реализовывать, если есть другие методы.

Как вы рекомендуете выполнять проверку кода для пользовательской истории?

Это зависит от характера пользовательских историй.

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

Чтобы работать в манере, истории должны быть тщательно детализированы, чтобы предотвратить неуправляемые задачи слияния в конце спринта. Небольшие истории позволят постоянно обновлять ветку разработчика через спринт, который разработчики, работающие над другими пользовательскими историями, должны постоянно извлекать (базовый VCM).

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

В конце спринта вы объединяете свою ветку разработчика в интеграцию / производство и т. Д.

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

Самый эффективный способ проверить код - это встать, найти кого-то и попросить его прийти и обсудить код, который вы только что разработали.

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

Вы можете полностью избежать проверки кода путем сопряжения.

Все в команде местные? Если это так, просто попросите кого-нибудь прийти и посмотреть, прежде чем код будет зарегистрирован. Не локально? Запустите свою любимую программу обмена экранами и позвоните кому-нибудь. Я лично делаю это часто. Иногда я делаю это просто, чтобы сказать: «Эй, посмотри, что я сделал!»

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

Я считаю, что проверка кода не является официальной частью SCRUM, но пересмотр - это независимая тактика для достижения качества и улучшения ваших проектов / команды.

Таким образом, вы будете использовать SCRUM (или другую методологию гибкой разработки) для обеспечения / улучшения качества ПРОЕКТА и соблюдения графика. Кроме того, хорошей тактикой является выполнение пересмотра продукта (а не кода) независимо от ваших обычных задач обеспечения качества / тестирования. Если эта деятельность может быть выполнена перед вашей командой / партнерами / клиентами / аудиторией, это будет лучше.

Вы должны использовать исправления кода (или другие конкретные) в основном для улучшения вашей КОМАНДЫ, ожидая результатов в среднесрочной / долгосрочной перспективе. Это повлияет на ваши ПРОЕКТЫ, но в долгосрочной перспективе как результат улучшения вашей КОМАНДЫ.

Итак, чтобы ответить на ваш вопрос, я полагаю, что вы пытаетесь слишком сильно оттолкнуться от SCRUM, и вам лучше рассмотреть изменения только в том виде, в каком они есть.

Разве не очевидно делать проверки кода перед проверкой кода?

TFS не работает как GIT, поэтому всякий раз, когда вы регистрируете код в ветви или транке, он доступен для всех.

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