Моя команда использует Team Foundation Server для контроля исходного кода, и сегодня я исправил некоторые ошибки и приложение для тестирования дыма, прежде чем зарегистрировал его, но забыл прокомментировать некоторый код. (Этот код сделал интерфейс немного странным.)
Я хочу знать, какие передовые практики существуют, прежде чем регистрировать код - я не хочу повторять такую ошибку снова.
Ответы:
Одна привычка, которую я приобрел, - это всегда смотреть различия в каждом файле, который я собираюсь проверить, прямо перед тем, как я проверю их.
Вы никогда не должны регистрировать закомментированный код. Если у вас есть код, который нужно комментировать перед регистрацией, вы делаете это неправильно.
Что касается правил:
Сложение
3.1 Исправить ошибки сборки
Запустить тесты
4.1 Исправить неработающие тесты
Переходите к 1 (пока ничего нового не получите)
Регистрируйтесь только после завершения всех шагов.
Смотрите танец регистрации .
Другие хорошие практики:
rebase -iи очистите свою локальную историю, при необходимости уничтожив коммиты, чтобы на основной линии не было уродливых коммитов в процессе выполнения.
Я не пытаюсь быть слишком ласковым, но предположение в этом вопросе (и все ответы, кроме одного) в основном относится к централизованным VCS, таким как TFS, SVN, Perforce и т. Д.
Достаточно справедливо, это то, что ОП использует.
С другой стороны, однако, когда вы используете DVCS (например, Mercurial и Git), вам обычно не нужно ждать, чтобы зарегистрироваться, и большинство вещей, упомянутых в ответах - таких как diff, get latest, merge и т. Д. - не нужно , Даже такие вещи, как проверки кода и тесты, лучше выполнять после регистрации (хотя, возможно, до нажатия, в зависимости ...)
Единственное исключение, которое я видел здесь (до сих пор), связано с рабочим элементом. Конечно, комментировать регистрацию тоже хорошо ...
Три вещи, которые я не видел в других ответах:
Включить новые файлы
Восстановить неизмененные файлы
Проверьте отправленный коммит
Две вещи, когда я использую Git:
Атомные коммиты:
git add --patchчтобы разделить мои изменения на несколько частей, если это необходимо.Просмотр различий во время подведения итогов
git commit --verboseчтобы увидеть изменения в моих изменениях, пока я печатаю сообщение о коммите. (Или я использую свою пропатченную git-vim, чтобы показать разницу.)Несколько пунктов «хорошей практики», которые я применяю на серверах моей команды, довольно просты. Во-первых, прежде чем регистрироваться, вы всегда должны получить последнюю версию и запустить локальную сборку, чтобы убедиться, что никто другой не проверял ничего, с чем ваш код будет конфликтовать. Кроме того, позаботьтесь о любых конфликтах кода на локальном компьютере, а не на сервере. Как только ваш код с последней загруженной версией будет подтвержден для сборки и правильной работы, вы готовы к следующему шагу. Запустите все автоматизированные тесты, затем начните регистрацию, чтобы убедиться, что они по-прежнему функционируют должным образом. Тогда, просто чтобы быть уверенным, получите последнее снова.
Как администратор TFS, можно комментировать все проверки. Я бы порекомендовал всегда добавлять комментарии к вашей работе независимо от того, применяется она или нет. Если у вас есть возможность сделать это, используйте ее. Убедитесь, что комментарии, по крайней мере, представляют собой общую сводку того, что вы изменили с момента последней регистрации вашего кода. Таким образом, если что-то пойдет не так, вы можете просмотреть проверки и примерно увидеть, что было изменился в этой регистрации. Это значительно облегчает отладку сломанной сборки.
Кроме того, если у вас есть привилегии администратора TFS, принудительно выполняйте повторные сборки при регистрации (чтобы убедиться, что все сразу знают, что их регистрация что-то нарушает), и вы можете настроить сервер на выполнение закрытой регистрации ( если проверенный код нарушает сборку, сервер отклоняет ее), или вы можете просто заставить ее создать ошибку и назначить ее тому, кто нарушил сборку.
Есть несколько других опций, которые вы можете включить или выключить, чтобы все было в порядке, или предложить вашему TFS-Admin включить, чтобы все было хорошо и чисто ... но они в основном предпочтительнее
Если вы регистрируетесь из Windows, убедитесь, что в вашем коде нет этих невидимых символов ^ M - редакторы в UNIX часто выдают ошибки / предупреждения по этой причине.
Также попробуйте заменить вкладки - разные пользователи будут по-разному видеть табуляции, некоторые с 4 пробелами, некоторые с 8 и не очень удобные для чтения кода.
Наилучший подход IMHO - иметь заранее определенный скрипт, проверяющий ваш код на соответствие правилам кодирования вашей организации. Нагрузки систем контроля версий имеют эту функциональность.
В моей компании мы используем отзывы о регистрации. Они не должны быть детальными, но просто показав кому-то различия в вашем списке изменений и обсудив их, вы сможете выделить странную опечатку, которую вы пропустили при тестировании.
Наш сервер контроля версий не позволит вам зарегистрироваться, если вы не отметите имя рецензента в комментариях (в форме! Инициалы, например! BW, если Брюс Уэйн сделал ваш отзыв). Рецензент получает электронное письмо, отмечающее, что они помогли рецензировать. Это открыто для очевидной эксплуатации, но, кажется, работает довольно хорошо.
Когда бы ни было возможно, я хотел бы связать регистрацию с рабочим элементом. Это дает вам некоторую контекстную информацию о том, ПОЧЕМУ это было изменено, а не только ЧТО было изменено. TFS имеет довольно приличную систему отслеживания рабочих элементов, так что это довольно тривиально во время регистрации.
(это в дополнение к просмотру различий моих изменений)
Одна маленькая вещь, которую я делаю, это не проверяю файлы, которые на самом деле не изменились. Эти файлы могли быть изменены непреднамеренно, или могли быть вовлечены в рефакторинги, которые были либо откатаны, либо иным образом сделаны спорными.
Таким образом, ваш набор изменений (связанный с рабочим элементом) содержит именно те файлы, которые необходимы для удовлетворения рабочего элемента.
Чтобы объединить все ответы здесь и дать полный контрольный список
[регистрация / выписка] вы не должны регистрироваться непосредственно в потоке, в котором работают другие. У вас должна быть стратегия потока: например, для каждого разработчика - поток, в котором вы можете регистрироваться и извлекать самостоятельно, не мешая другим: ваша работа будет быть в безопасности, но в вашем собственном потоке разработки, так [только в вашем собственном потоке разработки]. С каждой проверкой вы связываете это с записью изменений, так что ваши изменения являются атомарными по отношению к тому изменению, называемому набором изменений (так что вы можете распространять отдельные rfc / ошибки и т. Д. ... без необходимости передавать «все»).
[затем перебазировать с потоком вашей команды] это означает, что вы получаете изменения от других в своем потоке. Во время этой операции вы можете видеть в диалоге слияния все "различия" и проходить их или ... если их тысячи, и / или вы используете не код, а также, например, модели данных / проекты siebel и т. Д. ... полагайтесь либо на нетривиальные слияния, тривиально-автоматические и тривиальные ручные слияния, последняя категория содержит сложные. Помните, что вы все еще работаете в своем потоке.
[полная перебазировка] Если все в порядке, отметьте все изменения, которые вы только что получили из группового потока: ваш собственный поток обновлен
[доставить] теперь доставить вашу работу в поток команды. Если вы не хотите поставлять все, что можете, вы также можете выбрать, например, 1 конкретный RFC с этими конкретными версиями файлов или набором разрешенных RFC / дефектов.
[проверить поставку] все должно пройти нормально, но поскольку существует вероятность того, что кто-то за это время также изменил: вы можете проверить, работает ли ваша работа с последними изменениями в групповом потоке. С одинаковыми диалогами слияния, показывающими различия.
[завершить доставку] завершить доставку и ваша работа теперь в командном потоке.
Чтобы сделать его более сложным: поскольку все еще есть вероятность того, что выполненная вами работа = нормально, НО вы уже работаете над дальнейшей версией, вы должны всегда проводить базовый уровень после доставки и указывать, какой базовый уровень тот, который предпочтительнее для других пользователей, чтобы выполнить ребазинг из , Это гарантирует, что другие разработчики получат рекомендованную, а не последнюю версию в потоке (если вы работаете в этом сценарии). Это также Тройная проверка, так что даже если последние версии в групповом потоке «плохие», они все равно не являются теми, на которые другие перезагружаются или на которые смотрят, и ваш менеджер конфигурации может затем объединить предыдущую версию с следующей версией, чтобы отменить Ваша доставка.
В вашем примере вы даете то, что забыли закомментированный код. Ошибки случаются. Система управления конфигурацией вокруг этого должна заботиться об этом. Действительно может случиться так, что, например, тысячи изменений вступают в силу, и «сборки» и «интеграции» происходят в иерархии потоков на разных серверах, связанных и обрабатываемых во времени. Таким образом, даже если через 5 месяцев ваш закомментированный код будет протестирован на сервере интеграции, поскольку ваш код нуждается в интеграции с другим кодом и системами, все равно должна быть возможность атомарно извлечь ваш набор изменений и продолжить работу. Таким образом, лучшая практика более или менее на более высоком уровне. Об этом должен позаботиться общий дизайн потоков управления конфигурацией. Для отдельных разработчиков наилучшей практикой является, конечно, проверка / модульное тестирование. Но от большой картины до "
Некоторые из следующих применений больше, чем другие (или в разных формах) в зависимости от вашего SCM, поэтому здесь они идут:
ПРИМЕЧАНИЕ : некоторые из вышеперечисленных элементов кажутся довольно очевидными, но вы не поверите, сколько людей на самом деле работают в основной ветке или вносят изменения в производство, а затем вручную создают дельты, чтобы перейти к управлению версиями ... непосредственно в основной ветке. .. и с этикетками. Сладкая, как сброженная желчь, смешанная с немытым соком подмышек ... да, вот так.
Есть личный контрольный список. Начните это пусто, когда вы запутались, в записи. Когда это станет второй натурой, удалите его из списка.
Запустите тесты. Если они пройдут, отметьте это. Если вы все испортили и что-то не прошло, тогда напишите тест.
Мы делаем следующее ...
Тест - Мы хотим убедиться, что это работает. По крайней мере, мы хотим знать, что это ничего не нарушает.
Проверка кода или, по крайней мере, проверка друзей - это отличный способ обеспечить распространение знаний и своевременное информирование людей. Это также помогает поймать ошибки, прежде чем проверять.
Отправить предварительное уведомление. Предварительное уведомление отправляется группе перед регистрацией. Цель состоит не только в том, чтобы дать другим знать, какие файлы или области изменяются, но и дает им предупреждение (если они захотят заметить) на случай, если эти изменения могут повлиять на них.
Через несколько часов после отправки предварительного уведомления выполняется регистрация, и группа уведомляется по электронной почте. Каждый в группе может знать, когда конкретная работа над ошибкой или функцией завершена.
Копия уведомления о регистрации вставляется в запись исправления, связанную с ошибкой или функцией. При поиске записей мы обнаруживаем, что очень удобно иметь представление о том, что влечет за собой исправление / функция.
Запустите свои юнит-тесты, над которыми вы так усердно работали. Зеленый это хорошо.
Убедитесь, что ваш код отформатирован правильно (например, для Java: выберите код и нажмите Ctrl-Shift-F в Eclipse). Но будьте осторожны, делая то же самое для всего документа.
Всегда, всегда, всегда , проверяйте, чтобы изменения, которые вы сделали, не нарушали сборку. Особенно незначительные изменения, которые могут показаться тривиальными.
Однажды я внес небольшое изменение, которое, как я думал, не вызовет никаких проблем прямо перед тем, как я уйду с работы на выходные. Конечно же, это небольшое изменение сломало сборку, и никаких ночных тестовых прогонов для нашего проекта не проводилось. Руководитель Q & A был не слишком доволен этим, и это правильно.
Ищите части ваших изменений, которые могут быть единичными.
Часто к тому времени, когда у меня появляется исправление или улучшение кода, изменений довольно много. Некоторые из них являются специфическими для изменения поведения, за которым я иду; другие - рефакторинг, который я сделал, чтобы сделать это изменение чище.
Я предпочитаю проверять каждый рефакторинг отдельно, с собственным описанием изменений, например:
УТОЧНЕНИЕ: переименовать X в Y
X имел смысл раньше, потому что ... но теперь это должен быть Y. Это связано с работой над проблемой № 9.
Затем, как только каждый хороший рефакторинг отмечен, окончательное изменение поведения часто бывает тривиальным.
Кроме того, некоторые изменения затрагивают многие строки кода, но не очень интересны, в то время как другие изменения очень локализованы, но оказывают важное влияние. Если эти изменения зарегистрированы вместе, может быть трудно прочитать различия. Итак, я держу их отдельно.
Позже, когда кто-то читает историю изменений, становится очевидным, как дела попали в текущее положение дел и почему они таковы. Это также тривиально, чтобы отменить мои изменения в поведении, потому что это не запутано с кучей других правок.
Делайте то, что вы делаете, когда возвращаете что-то, что вы одолжили у кого-то. Убедитесь, что он чистый и в хорошей форме. Если вы сделали беспорядок, обязательно очистите, прежде чем возвращать код его владельцу (в большинстве случаев, ваш работодатель).
Я держу местный репозиторий HG для моей работы.
Я не утверждаю, что это лучшие, но они работают на меня.
Тщательно проверьте все, что вы добавили или изменили. Попробуйте все возможные варианты. Не оставляйте тестирование на QA. Если бы у меня был бутерброд каждый раз, когда я вносил незначительные изменения, а затем пробовал несколько тестов, просто чтобы быть в безопасности, и сразу же видел проблемы, у меня было бы много бутербродов. Я обычно говорю вслух себе: «Я действительно рад, что попробовал это ...»
Вы говорите, что интерфейс стал странным после вашего изменения. Если бы вы только запустили программу и посмотрели на пользовательский интерфейс перед регистрацией, заметили ли вы проблему?