Должен ли я регистрировать тривиальные исправления?

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

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

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

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

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

В подавляющем большинстве случаев вы правы, и никто не будет смотреть на это когда-либо снова, но в 1 из 100 случаев, когда что-то пойдет не так, эта информация будет неоценимой - особенно если проблема возникнет только через 6 месяцев.

ОБНОВИТЬ

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

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

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

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

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

С метрической точки зрения, это все еще может быть полезным.

Эта информация может быть использована, чтобы показать боссу несколько вещей:

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

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

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

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

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

Войти их.

Ответ на это действительно зависит от того, где вы находитесь в процессе.

Они могут применяться к новому проекту или новому разрабатываемому набору функций.

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

тестирование

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

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

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

Выпуск

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

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

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

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

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

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

Джон Арид Торресдал: Почему вы не должны отслеживать ошибки - исправьте их.

1. Во время разработки: вы столкнулись с ошибкой для функции; Вы добавляете тестовый пример, который нарушает сборку , а затем проверяете исправление на соответствие этой функции.

2. После выпуска: документально оформить поведение . Если вы планируете выпускать обновление, перейдите к 1. Если вы не отвечаете за этот выпуск, сохраните тест + исправление в частной ветке.

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

Зависит, насколько тривиально, я использую эту меру:

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