Как заставить разработчиков делать обзоры кода своевременно

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

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

Посмотрите, как это делает Facebook со своим собственным приложением под названием phabricator: http://phabricator.org/

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

Я думаю, это делает его веселее.

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

Хотя, возможно, ваши товарищи по команде не верят в этот обзор.

Лично, в отсутствие рецензентов, я использовал модульные тесты для функций более низкого уровня и «тест уборщика» для всех остальных: тест уборщика называется так, потому что даже уборщик должен уметь понимать ваш код.

Я обычно удалял некоторые второстепенные части, такие как скобки области блока / функции, нотации видимости, иногда даже типы, и показывал это менеджерам, экспертам по доменам, партнерам, кто бы ни запрашивал код: «это то, что вы хотите?»

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

Или, если вам не нравится команда или вам не нравится, вы знаете, «если вы можете« изменить компанию, сменить компанию »...

Я собираюсь основывать это на нескольких предположениях:

1. Кажется, что каждый хочет написать код (если нет, у вас есть люди, которым нужно идти).
2. Каждый хочет, чтобы его собственный код был зарегистрирован.

Только те, кто завершил свои обзоры, могут проверить свой код.

Может быть, определенное время может быть посвящено проверке кода в надежде избежать проблемы прерывания.

Цель должна заключаться в проверке качества кода. Вы не хотите наказывать / форсировать рецензии до такой степени, чтобы все просто давали им «резиновый штамп».

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

У нескольких предыдущих работодателей мы проверяли, кто был на Code Review ежедневно. Обычно 3 человека делят день CR, и каждый CR должен был быть подписан двумя из рецензентов. Это обеспечило то, что когда был ваш день, вы знали, что от вас ожидают CR, независимо от других ваших проектов. Итак, каждые пять дней или около того, была ваша очередь, и вы могли соответствующим образом корректировать свои задачи по разработке.

В настоящее время у нас есть команда Team Lead, которая делает краткий обзор кода своей команды. В зависимости от того, какая область приложения была обновлена, после завершения CR, она может быть передана в Глобальную группу проверки, где мы проверяем вещи, которые оказывают глобальное влияние на приложение (я), вместо того, чтобы связанные с одной функцией. Когда требуется выполнить большой обзор, мы обычно разбиваем его на несколько человек, чтобы никому не приходилось иметь дело с изменениями в смешном количестве файлов.

Тем не менее, мы только пересматриваем код, который был добавлен в текущую ветку / вариант разработки. Код должен пройти проверку кода, глобальную проверку, проверку базы данных и проверку пользовательского интерфейса (каждый при необходимости), прежде чем он может быть переведен в следующую (например, альфа) среду.

Наконец, мы соглашаемся с SLA о том, как быстро проверяются отзывы. Вряд ли что-либо находится в очереди более 48 часов, и большинство проверок выполняется менее чем за 24 часа.

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

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

• ^{Идея, лежащая в основе требований вашей компании, на первый взгляд звучит разумно (100% проверенный код), но средства, которые они решили использовать, контрпродуктивны - потому что, как вы указываете, это приводит к разочарованию разработчиков.}

Вначале я хотел бы указать руководству, что проверки кода после фиксации считаются такими же респектабельными, как и проверки перед фиксацией . Эти термины доступны для поиска в Интернете - при необходимости найдите там ссылки для резервного копирования. Для получения 100% проверенного кода необязательно требовать предварительной проверки.

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

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

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

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

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

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

В большинстве компаний, в которых я работал, у вас есть 3 дня, чтобы завершить обзор. Недопустимо не делать отзывы. Это часть твоей работы. Если вы вовремя не делаете достойных обзоров, это влияет на вашу оценку производительности. И да, обзоры всегда бывают в самые неподходящие времена. Слишком плохо, учитесь включать время обзора в свои оценки. В любом случае, если руководство действительно считает, что проверки важны (т. Е. Они требуют, чтобы весь код проверялся), тогда они будут придерживаться аналогичной политики. Кроме того, если люди не завершают обзор в отведенное время, это означает, что они согласились с материалом.

Подумайте об использовании такого инструмента, как Review Board . Это очень полезно, особенно для длинных обзоров.

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

Несколько моментов, которые нужно добавить, которых нет в других ответах.

Код для проверки должен быть проверен в

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

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

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

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