Должен ли я записать ошибку, которую я обнаружил и исправил?

Я предполагаю, что это обычная ситуация: я тестирую некоторый код, обнаруживаю ошибку, исправляю ее и фиксирую исправление ошибки в хранилище. Предполагая, что над этим проектом работает много людей, я должен сначала создать отчет об ошибке, назначить его себе и сослаться на него в сообщении о фиксации (например, «Исправить ошибку #XYZ. Ошибка произошла из-за X и Y. Исправлена Q и R ")? Кроме того, я могу пропустить отчет об ошибке и зафиксировать с помощью сообщения, такого как «Исправлена ​​ошибка, которая вызывала A, когда B. Ошибка была из-за X и Y. Исправлена ​​с помощью Q и R».

Что считается лучшей практикой?

Это зависит от того, кто является аудиторией сообщения об ошибке.

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

Неисчерпывающий список причин для входа в любом случае:

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

Я бы сказал, это зависит от того, был ли ваш продукт выпущен с ошибкой или нет.

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

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

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

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

Это зависит от нескольких факторов.

И Питер Б, и Калет перечисляют некоторых в своих ответах:

• Была ли ошибка частью официального релиза?
• Отслеживается ли количество ошибок / времени, потраченного на них?

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

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

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

Но позвольте мне спросить другой путь: почему бы вам не записать исправленную ошибку?

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

В этом случае проблема не в том, что ошибку так легко исправить, а в том, что оформление документов занимает слишком много времени. Это действительно не должно. Для меня накладные расходы на создание билета Jira - это нажать c, затем ввести краткую однострочную сводку и нажать Enter. В описании нет даже лишних затрат, так как я могу вырезать и вставить это в сообщение фиксации вместе с номером проблемы. В конце концов, . c <Enter>вопрос закрыт. Это сводится к 5 нажатий клавиш наверху.

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

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

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

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

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

Да .

Уже есть некоторые ответы, которые раскрывают ситуации, в которых стоит создать сообщение об ошибке. Некоторые ответы. И они отличаются.

Единственный ответ - никто не знает. Разные люди в разное время будут иметь разные мнения по этому вопросу.

Так что теперь, при обнаружении ошибки, у вас есть два решения:

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

Создание отчета быстрее, а если нет ... автоматизируйте его.

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

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

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

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

Что-то вроде минутного разговора в коридоре подойдет: «Эй, босс, если я исправлю небольшую ошибку, которая занимает всего несколько минут, стоит ли на нее претендовать или я должен упомянуть об этом в своем сообщении о коммите? " и ты будешь знать наверняка. Вся хорошая практика в мире бесполезна, если этот метод раздражает вашу команду и вашего менеджера.