Есть ли какая-то причина, почему вы все хотите получать уведомления, когда кто-то фиксирует какие-то коды?
Я знаю, что есть такие вещи, как ручная проверка, чтобы убедиться, что принятые коды в основном верны. Но кроме этого? Причина, по которой я спрашиваю, заключается в том, что в большом проекте каждый день так много коммитов.
9 ответов
Вообще говоря, уведомления о коммитах полезны для того, чтобы вы имели представление о том, что происходит в коде ежедневно. Например, я знаю, когда была реализована новая функция, или зафиксировано исправление ошибки. Если коммитов так много, что он теряется в шуме, то, возможно, стоит отфильтровать или уменьшить количество сообщений о коммитах, которые вы видите (возможно, например, вы можете ограничить его только определенными модулями, над которыми вы работаете).
При этом, помимо предоставления другим разработчикам возможности по крайней мере кратко просмотреть код, он также может уведомлять людей о том, что:
- самое время запустить обновление из системы контроля версий и объединить все новые изменения, если это необходимо
- Эй, кто-то нашел ошибку в синтаксическом анализе регулярных выражений в Foo, но забыл обновить Bar этим
- О, Боб работает над модулем Baz, я должен попросить его взглянуть на это тоже
Вы поняли идею. По сути, это призвано помочь прозрачности всей группы, а не просто привлечь внимание к коммиту, а улучшить цикл разработки для команды в целом.
Многие из упомянутых выше вещей полезны при получении уведомлений о регистрации. Я обычно использую это для нескольких вещей:
- Если проект каким-то образом ломается, иногда я могу более быстро решить проблему, потому что я знал о проверках, которые были в системе. Это может указывать мне на решение быстрее
- Он предоставляет легко проверяемый набор чеков (хотя бы потому, что я получаю их по электронной почте). Да, ваша система контроля версий имеет всю эту информацию, но может быть нелегко найти весь комментарий о регистрации. С электронной почтой для меня довольно тривиально вернуться назад и найти пользователя, модуль, ключевое слово и т. Д. И заставить Outlook выкашливать соответствующие письма.
- Я могу легко отслеживать молодых разработчиков и то, что они делают. Это дает мне возможность увидеть, когда они проверяют код и что они делают с кодом. Это дает постоянные шансы наставника вне других регулярно запланированных вещей, таких как проверки кода.
- Это дает возможность команде отслеживать прогресс и отмечать, когда они могут проверять конфликты.
Даже если есть много уведомлений, я не чувствую, что они должны быть прочитаны полностью. Я просматриваю их кучу, но этого достаточно, чтобы вернуть меня к соответствующим коммитам, когда мне нужно больше информации.
Это может быть полезно, если кто-то вносит изменения в одну или несколько программ, над которыми вы, возможно, сами работаете. Если хотите, вы можете решить некоторые конфликты, которые могут потребовать дальнейшего общения.
Я видел ситуацию, когда программист А совершил некоторые изменения и через пару дней ушел в отпуск. Программист B также работал над теми же программами, и в то время, когда программист B отправлял свои изменения, возникали некоторые конфликты. Обычно это не важная вещь, плюс общение между членами команды всегда должно быть открытым. В этом случае у Программиста B были некоторые вопросы об изменениях, внесенных Программистом A, но ему пришлось ждать неделю, пока этот программист не вернулся. В этой ситуации было бы полезно электронное письмо, даже автоматически сгенерированное.
Просто мои два цента.
Конечно, вы хотите посмотреть на вводимый код, чтобы иметь представление о том, что делают другие люди в вашей команде, и вы не застряли в пещере, просто пишущей свой код.
Даже если вы не отслеживаете код качества, вы можете понять, над чем работают другие люди.
Это помогает создать команду.
Во многих компаниях проверки кода являются обязательными, но выполняются по системе чести. Отправленные по электронной почте уведомления о фиксации реализуют механизм "доверяй, но проверяй" для этих сред.
Обычно у нас есть обновления, чтобы все знали, что что-то было обновлено и нуждается в рецензировании. Если вам не нужно назначать одного пользователя, вы можете получить его и иметь дело с ним, когда у вас есть время.
Я видел, как кто-то опубликовал систему, которая отправляет сообщения в стиле твиттера в Yammer, когда они фиксируют быстрое и простое "что меняется" в журнале комментариев в стиле кода. Ухоженная. Не могу найти ссылку сейчас.
Насколько я понимаю, главная причина того, что CCing сообщает о фиксации разработчикам, заключается в том, чтобы избежать конфликта: вы видите фиксацию в файле, с которым работаете, так что вы знаете, что у вас проблемы даже до того, как вы зафиксировали. Однако это довольно отвлекает, поэтому есть инструменты (например, Palantir, старый IBM Jazz), которые фактически покажут вам, какие файлы редактируются одновременно.
Я использую это главным образом, чтобы измерить сердцебиение проекта. Каждое сообщение фиксации является импульсом. Со временем вы получите некоторое представление о том, как "нормальный" пульс "звучит".
В обычный день мы получаем от 4 до 6 сообщений коммитов. Это замедляется до 1 или 2, так как дата итерации наступает и останавливается примерно за пару дней до выпуска итерации. Через день или два после итерации она снова начинает подниматься, и, если найдены ошибки, мы можем получать 1 сообщение о фиксации в час, поскольку ошибки исправляются. Обычный день с небольшим количеством коммитов может означать, что разработчик испытывает трудности с некоторыми функциями или тратит слишком много времени на стекопоток.
Я также считаю информативные сообщения о коммите очень полезными. Иногда менеджеру или тестировщику даже не нужно спрашивать разработчиков о статусе функции или ошибке - просто посмотрите на сообщения коммита, чтобы увидеть, есть ли какая-либо работа над этим.
Я нахожу это в первую очередь полезным для отслеживания. В общем, такие автоматические уведомления отфильтровываются в корзину в моем почтовом ящике вместе с электронной почтой типа "проверено, пройдено, провалено"... тогда, когда происходит сбой, вы можете довольно просто отследить его до набора проверок.
Обратите внимание, что зрелость проекта также можно интуитивно представить по форме кривой чеков - количество строк кода, изменяемых за день, как функция общего размера базы кода. Это действительно дает разумное представление о том, когда вы собираетесь "сделать"...
Надеюсь это поможет!