Обзор до или после принятия кода, что лучше?

Традиционно мы выполняли проверку кода перед фиксацией, сегодня я поспорил со своим коллегой, который предпочел проверку кода после фиксации.

Во-первых, вот немного предыстории,

1. У нас есть опытные разработчики, и у нас также есть новые сотрудники с практически нулевым опытом программирования.
2. Мы хотели бы выполнить быстрые и короткие итерации, чтобы выпустить наш продукт.
3. Все члены команды находятся на одном сайте.

Преимущества проверки кода перед коммитом, которые я узнал:

1. Наставник новых сотрудников
2. Старайтесь не допускать ошибок, сбоев, неправильных проектов на ранних этапах цикла разработки.
3. Учиться у других
4. Резервное копирование знаний, если кто-то выходит

Но у меня также были некоторые неудачные опыты:

1. Низкая эффективность, некоторые изменения могут быть пересмотрены в течение нескольких дней
2. Трудно сбалансировать скорость и качество, особенно для новичков
3. Один член команды чувствовал недоверие

Что касается проверки после фиксации, я мало что знаю об этом, но больше всего меня беспокоит риск потери контроля из-за отсутствия проверки. Есть мнения?

ОБНОВИТЬ:

1. Мы используем Perforce для VCS
2. Мы кодируем и фиксируем в одних и тех же ветках (стволы или ветки исправления ошибок)
3. Чтобы повысить эффективность, мы постарались разбить код на небольшие изменения. Мы также попробовали обзор в реальном времени, но не все следовали этому правилу. Это еще одна проблема.

Как упоминает Саймон Уайтхед в своем комментарии , это зависит от вашей стратегии ветвления.

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

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

Существует мантра, которую, кажется, еще никто не цитировал: регистрируйтесь рано и часто :

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

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

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

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

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

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

Есть также утверждение Джеффа Этвуда: не бойтесь ломать вещи :

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

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

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

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

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

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

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

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

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

Сделать оба:

• pre commit - делайте такого рода обзоры, когда это что-то очень важное, например, очень многократно используемый фрагмент кода или важное дизайнерское решение
• post commit - делайте такие обзоры, когда вы хотите узнать мнение о куске кода, который может быть улучшен

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

Это исключает любые аргументы типа «у вас нет последнего файла» и гарантирует, что все проверяют одну и ту же копию исходного кода.

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

За сам пересмотр кода мой голос за «во время» коммита.

Система, подобная gerrit или clover (я думаю), может внести изменения, а затем заставить рецензента передать их в систему управления версиями (push git), если это хорошо. Это лучшее из мира.

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

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

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

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

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

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

Отзывы полезны как до, так и после коммитов.

Предварительная проверка коммита

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

Во время обзора не работает коммитов

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

После проверки ревизий

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

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

Пост-обзорный коммит

• Дает модератору и другим рецензентам точку данных для сравнения с коммитом перед рецензированием.
• Предоставляет метрики, позволяющие судить о значении и успешности проверки при удалении дефектов и улучшении кода.

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

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

Я и мои коллеги недавно провели некоторые научные исследования по этой теме, поэтому я хотел бы добавить некоторые из наших идей, несмотря на то, что это довольно старый вопрос. Мы построили имитационную модель гибкого процесса / команды разработки Kanban и сравнили анализ перед фиксацией и после фиксации для большого количества различных ситуаций (разное количество членов команды, разные уровни квалификации, ...). Мы смотрели на результаты после 3 лет (смоделированного) времени разработки и искали различия в отношении эффективности (законченные сюжетные точки), качества (ошибки, найденные клиентами) и времени цикла (время от начала до выдачи пользовательской истории) , Наши выводы заключаются в следующем:

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

Из них мы получили следующие эвристические правила:

• Если у вас есть установленный процесс проверки кода, не пытайтесь изменить, это, вероятно, не стоит усилий
  • если у вас нет проблем с временем цикла => Переключиться на сообщение
  • Или проблемы с ошибками слишком часто мешают вашим разработчикам => Переключиться на Pre
• Если вы еще не делаете отзывы
  • Используйте предварительную фиксацию, если для вас применимо одно из этих преимуществ
    • Предварительная проверка коммитов позволяет посторонним лицам без права коммитов участвовать в проектах с открытым исходным кодом.
    • Если анализ основан на инструментах, предварительная фиксация навязывает некоторую дисциплину проверки в командах с иным слабым соблюдением процесса
    • Проверка перед фиксацией легко предотвращает доставку непредвиденных изменений, что очень удобно для непрерывного развертывания / очень коротких циклов выпуска
  • Используйте pre commit, если ваша команда большая, и вы можете жить или обходить проблемы во время цикла
  • В противном случае (например, небольшая, квалифицированная производственная команда) используйте post commit
• Ищите комбинации, которые дают вам преимущества обоих миров (мы не изучали их формально)

Полная исследовательская работа доступна здесь: http://dx.doi.org/10.1145/2904354.2904362 или на моем сайте: http://tobias-baum.de

На мой взгляд, рецензирование кода работает лучше всего, если сделано после фиксации.

Я бы порекомендовал скорректировать вашу стратегию ветвления. Использование ветки разработчика или ветки функций имеет ряд преимуществ ... и не в последнюю очередь это облегчает проверку кода после фиксации.

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

http://www.atlassian.com/software/crucible/overview

Некоторые другие преимущества пользовательских / функциональных веток:

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

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

Обе. (Что-то вроде.)

Вы должны пересмотреть свой собственный код вкратце перед его фиксацией. Я думаю, что в Git отличная сцена. После того, как я поставил свои изменения, я бегу, git diff --cachedчтобы увидеть все, что поставлено. Я использую это как возможность убедиться, что я не проверяю какие-либо файлы, которые не принадлежат (сборка артефактов, журналы и т. Д.), И что у меня нет отладочного кода или каких-либо важных комментариев. вне. (Если я делаю то, что, как я знаю, я не хочу регистрировать, я обычно оставляю комментарий во всех заглавных буквах, чтобы распознать его во время постановки.)

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

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

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

100% парное программирование (независимо от того, какой возраст вы считаете своим старым) с большим количеством небольших коммитов и системой CI, основанной на КАЖДОМ коммите (с автоматическим тестированием, включающим модули, интеграцию и функционирование, где это возможно). Пост-фиксация обзоров для больших или рискованных изменений. Если у вас должен быть какой-то закрытый / предварительный обзор, Геррит работает.

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

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

Что делает это более трудным, так это то, что не все разработчики одинаковы. Простые решения не работают для всех программистов . Простые решения:

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

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

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

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

На практике вы делаете эту работу, делая ее еще проще и сложнее одновременно. Вы устанавливаете простые рекомендации и позволяете каждой группе разработчиков выяснить, как они должны делать, чтобы следовать этим рекомендациям. Пример таких рекомендаций:

• Работа разбита на задачи, которые должны занимать менее суток.
• Задача не завершена, если код (если есть) не был зарегистрирован.
• Задача не завершена, если код (если есть) не был просмотрен.

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

мы на самом деле делаем гибрид на LedgerSMB. Коммиттеры фиксируют изменения, которые проверяются после. Лица, не являющиеся коммиттерами, передают изменения коммиттерам, которые должны быть рассмотрены ранее. Это имеет тенденцию означать два уровня обзора. Сначала вы получаете наставника, чтобы рассмотреть и наставить вас. Затем этот наставник проверяет код во второй раз после того, как он или она подписали его и распространяет обратную связь. Новые коммиттеры обычно сначала тратят много времени на просмотр коммитов других людей.

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

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

Рецензент рецензирует, очевидно, после того, как я связался со своей веткой Он не сидит за моим столом, поэтому не может просмотреть его, пока я не отправлюсь на свою ветку. И он рассматривает перед слиянием и передает в разработку ветку.

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

Вовлечение людей в то, что должно быть автоматическим процессом, просто расточительно.