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

68

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

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

Дэвид Д
источник
4
Зависит от размера вашей компании и команды, а также от характеристик ошибки. В небольших и быстрых командах это просто не нужно, поскольку вы можете общаться со своими коллегами-разработчиками, просто крича на них. В больших командах, крупных организациях, в распределенной среде разработки полезно регистрировать свою работу, но это также накладные расходы, которые снижают уровень производства, если вы работаете с несколькими небольшими ошибками. Если это не серьезная ошибка, которую всегда приятно документировать, тестировать модульно, чтобы избежать регрессии и закрывать.
Мачадо
15
Не забывайте, что некоторые ошибки не остаются исправленными - они самопроизвольно перевоплощаются, если вы игнорируете их некоторое время. Знание того, как кто-то пытался это исправить в прошлый раз, может быть ценным. По крайней мере, должна быть некоторая документация, рассказывающая, что вы сделали с кодом и почему, даже если это только в комментариях в коде.
алефзеро
5
В дополнение к предыдущим комментариям, это также зависит от того, была ли ошибка обнаружена, но вам повезло, что ни один из клиентов не столкнулся с ней, или она была введена и исправлена ​​в течение одного цикла выпуска.
whatsisname
3
Если сомневаешься, кричи. Мне никогда не помешает открыть и закрыть отчет об ошибке. В некоторых случаях хорошо, чтобы такие вещи были задокументированы и официальны.
Френель
1
Относительно комментария @ alephzero, кое-что, что случилось со мной недавно: исправление ошибки в одной части кода выявило ошибки в другом месте. Они непреднамеренно уничтожили друг друга в той части, которой я не коснулся, и первым инстинктом сопровождающего было отменить мое исправление.
Изката

Ответы:

71

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

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

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

  • Примечания к выпуску включают информацию об исправленных ошибках (до некоторого порогового значения, с которым встречается эта ошибка), особенно если существует уязвимость, обнаруженная этой ошибкой
  • Руководству требуется понятие «Время, потраченное на исправление ошибок» / «Количество обнаруженных ошибок» и т. Д.
  • Клиенты могут видеть текущее состояние средства отслеживания ошибок (чтобы узнать, известна ли их проблема и т. Д.)
  • Тестеры получают информацию об изменениях, которые они должны проверить.
Caleth
источник
56
Наиболее вероятное место возникновения ошибки - это место, где ошибка ранее возникла. Я бы рекомендовал записывать его практически в каждом сценарии.
CorsiKa
18
# 4: Тестеры используют систему отслеживания ошибок, чтобы направлять их тестирование. Они проверит, что исправление работает и что оно не вызывает новых ошибок или регрессий.
jpmc26
2
@corsiKa Когда лекарство хуже болезни? ;-)
hBy2Py
1
@ hBy2Py Найдите нового доктора и запишите его.
CorsiKa
2
@BradThomas, чтобы перефразировать то, что вы цитировали: «Багтрекер используется как список TODO, и ничего более» + «Исправленная ошибка» -> «нет TODO». Я согласен почти во всех других ситуациях, вы хотите запись
Caleth
52

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

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

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

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

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

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

gnasher729
источник
9

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

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

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

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

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

Восстановить Монику
источник
2
Конечно, вы должны упомянуть исправление в сообщении о коммите и, предпочтительно, сделать отдельный коммит для изменения, которое исправило ошибку. (И, может быть, отдельный запрос или серия исправлений, если это изменение само по себе). Единственным исключением из этого является то, что ошибка исправлена ​​как побочный эффект изменения чего-либо по другой причине (но все равно упоминайте об этом в сообщении фиксации). Единственный вопрос - стоит ли беспокоиться об отслеживателе ошибок, а не связывать ли изменения с другими вещами в одном коммите!
Питер Кордес
3

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

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

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

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

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

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

Anoe
источник
2

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

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

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

Рассел Хэнкинс
источник
1

Да .


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

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

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

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

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


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

Матье М.
источник
0

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

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

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

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

Vality
источник