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

При разработке (либо функций, либо исправлений ошибок) я иногда обнаруживаю ошибки, которые не имеют прямого отношения к тому, над чем я работаю. Что мне делать в такой ситуации. Просто исправить это? Попробуйте вспомнить, чтобы исправить это позже? Запишите это где-нибудь? Или введите его в систему отслеживания ошибок?

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

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

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

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

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

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

Вы должны ввести ошибки в систему отслеживания ошибок в обоих случаях:

• когда ошибка касается непосредственно кода, над которым вы работаете,

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

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

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

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

Причины не въезда:

• Процесс измеряет и наказывает на основе сообщений о дефектах - не сообщает, не получает наказание. В этом случае покинуть организацию
• Процесс является обременительным - он требует слишком много усилий и времени для того, чтобы обнаружить дефект и прийти к точке его устранения. Процесс должен быть изменен, чтобы позволить разработчикам быстро отследить небольшую ошибку в процессе сортировки / принятия / исправления.
• Некоторые разработчики - ленивые / неаккуратные / хакеры, которым все равно, какое влияние могут оказать их действия на других. Привлекать профессиональных разработчиков.
• Я группа одного человека, не вижу смысла. Иди работать на группу из 2 человек, и вы будете ....

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

Решение не является четким и предполагает компромиссы.

(некоторые) ПРОФИ

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

• Часто ошибки легче всего исправить, пока вы уже находитесь в части кода и работаете над его пониманием.
• Даже в небольших командах можно получить большую пользу, если уметь составлять список ошибок и прогресс в их исправлении - иногда моральное преимущество имеет решающее значение даже для проектов с одним человеком.
• Точное обнаружение ошибок может быть очень трудным после факта - обнаружение ошибки в коде может спасти большую часть дальнейшей работы, играя детективом, пытаясь выяснить, где проблема возникла изначально.
• Для вашего общего развития, как разработчика, полезно обращать внимание на ошибки так, как вы их видите, и приобретать привычку критически улучшать / очищать / читать код.

Ведение журнала ошибок по мере их появления, вообще говоря, хорошая привычка.

(некоторые)

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

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

Иногда отслеживание ошибок - не самое эффективное использование вашего времени.

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

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

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

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

Со временем я нашел все виды твиков как полезные. Например:

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

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

Я считаю, что если разработчик сталкивается с ошибкой, которая не связана с тем, что он работает, и что он не будет исправлять, он должен ввести ее в систему просто для того, чтобы иметь некоторую запись об этом. Таким образом, когда QA начинает тестирование (а они все еще не исправлены), вы можете указать им этот список ошибок как «известные дефекты», чтобы они не начали сообщать об одних и тех же ошибках.

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

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

Таким образом, если в будущем проблема возникнет снова (случится регрессия!), Относительно легко распознать проблему как «уже решенную» и прочитать, как она была исправлена ​​в первый раз.

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

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

А как насчет других разработчиков? Что если они исправят это по-другому одновременно? Что, если они найдут подобную ошибку позже, и все, что вы можете сделать, это сказать: «О, черт, я знаю, что у нас было что-то подобное раньше - теперь, что это было?»

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

Программирование - сложная работа в корне. Ошибки сложные. поэтому я использовал для оценки ошибки по двум факторам:

1. Как часто такие ошибки могут появиться снова в будущем? Является ли эта оценка точной или нет, продолжайте оценивать.
2. Когда такие ошибки появляются снова, это легко понять? Это верно, когда вы анализируете эту ошибку и исправляете ее.

Я бы классифицировал ошибку в один из следующих типов:

1. Вероятно, появятся снова в будущем, и легко понять
2. Скорее всего, появится снова в будущем, но трудно понять
3. Редко появляются снова в будущем и легко понять
4. Редко появляются снова в будущем, но трудно понять

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

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

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

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

Конечно, вы должны войти в него. Или, по крайней мере, сообщите об этом вашим специалистам по обеспечению качества, если это ваш обычный процесс.

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

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

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

Тогда, ударись однажды, Нирвана! Почему мы не используем багтрекер, даже если вы нашли что-то похожее на ошибку и возможно, что это не так (ваша мысль о процессе неверна / ошибочна). Это, по крайней мере, входит в список, который затем можно проверить, и, что самое важное, из всех отзывов о том, почему это важно, или же с другой стороны, это идеально, и именно так это должно работать по причинам 1 ... 2 ... ,

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

Предполагая его уже проверенный (и особенно если выпущен) код абсолютно.

Есть ряд причин для этого:

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

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

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

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

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

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

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

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

1. Инструмент и / или процесс обработки ошибок воспринимается как слишком тяжелый для разработки
2. Разработчики считают, что проблема исправления ошибки интереснее, чем то, над чем они сейчас работают.

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

Пункт 2 должен быть полезным предупреждающим знаком для руководства разработки о распределении текущих задач.

Я в основном согласен с FrustratedWithFormsDesign, но думаю, что еще яснее, если вся проблема разбита на две области:

• Отчет об ошибках.
• Исправление ошибок.

Они часто рассматриваются как одинаковые, и их разделение почти наверняка поможет.

Они могут быть обработаны с помощью: Bug Reporting: - поместите это в систему, как все говорят.

Исправление ошибок: - Каждую неделю или две (подстраивайтесь под ваш график разработки и т. Д.) Все собираются вместе в проекте и решают, что нужно исправить, кем и т. Д. Все были на одной странице и могут видеть, что нужно быть сделано В Agile Development это встреча по планированию спринта.

Хороший инструмент, который люди хотят использовать, также имеет большое значение. Мне нравится Pivotal Tracker, и он прошел мой тест «действительно полезного инструмента», когда я начал использовать его, просто чтобы отслеживать то, что я хочу сделать или исправить в моих собственных частных проектах!

Если ты что-то видишь, то скажи что-нибудь!

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

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

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

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

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

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

• это действительно ошибка, а не особенность
• Кто-то еще может протестировать исправление и убедиться, что исправление не представляет новую ошибку в другом месте (регрессия)