Источник проверки часто или редко?

Question

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

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

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

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

Answer 1

Проверка должна проводиться часто.

Регистрация должна быть

• Atomic. Содержит все необходимые изменения, но не более. Что также означает, что
• Изменения пробелов выполняются сами по себе.
• изменить только одну функциональность. Это может изменить несколько функций, но не должно изменять функциональность несколькими способами и / или местами.
• комментировал. Проверка в комментарии должна позволить вам быстро найти коммит, даже если ему 2 года, и вы больше не работаете над этим конкретным источником (или даже проектом).
• рабочий. Только коммит, если код на самом деле строит и делает то, что, как он утверждает, делает.

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

Answer 2

Я могу порекомендовать следующие рекомендации:

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

Answer 3

Регистрируйся рано и часто, как голосование.

Одно замечание: это немного меняет работу вашего процесса интеграции. Если у вас есть непрерывная интеграция, вы не хотите возвращать вещи обратно в trunk , если вы не запускаете модульные тесты и не уверены, что это сработает.

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

Answer 4

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

• В гибкой среде обычные проверки меньший риск сборки нарушение или слияния конфликтует с другими программистами;

• Более частые проверки означают больше детальная регистрация, что означает, что вы собирать много больше информация --- это полезно для получать статистику о состоянии проекта и для охоты на жуков;

• Гранулированный регистрация означает, что регистрация комментариев более сфокусированы, а меньше вероятность недооценки изменений которые были сделаны;

• Детальная регистрация убедитесь, что inter-version diffs стало легче ориентироваться .

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

Answer 5

Я часто проверяю.

Управление исходными кодами дает вам две вещи, которые вы теряете из-за частой регистрации:

• упрощение совместной работы
• отслеживание истории изменений во времени

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

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

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

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

Answer 6

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

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

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

Answer 7

Насколько это практически возможно, я стараюсь делать свои проверки как можно более детальными, с условием, что я не буду / не проверять что-либо, что а) не компилируется, б) прерывает юнит-тесты или c) нарушить обратную совместимость (если это не запрошено / не спроектировано таким образом).

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

Answer 8

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

Answer 9

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

Answer 10

Вопрос: какой тип VCS вы используете? Ваш комментарий на то, что ваш начальник жаловался, когда вы оставляли проверенный код во время отпуска, кажется странным. Я всегда проверял код, используя Subversion, и никого не волнует.

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

Это может не зависеть от вас, но если вы используете античный VCS, это может повлиять на ответы.