Должны ли мы исправить эту ошибку?

Ответ 1

Каноническая статья об этом Моя жизнь как экономист кодов, Эрик Синк.

Это действительно стоит прочитать статью, но если вы хотите, чтобы она была подведена для вас в контрольном списке:

• Когда эта ошибка возникает, насколько плохим является воздействие? - Уровень важности
• Как часто происходит эта ошибка? - Частота
• Сколько усилий потребуется для исправления этой ошибки? - Стоимость
• В чем заключается риск исправления этой ошибки? - Риск

Ответ 2

• Значимость воздействия на пользователя
• Частота появления
• Доступен ли обходной путь?
• Стоимость исправления
• Время исправления
• Время, оставшееся до истечения срока выпуска
• Доступность ресурсов, которые могут исправить

Ответ 3

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

Дайте спящим собакам принцип лжи.

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

Грустно, но верно.

Ответ 4

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

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

Ответ 5

Критичность, влияние и деньги обычно.

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

Ответ 6

Это определенно вопрос, связанный с доменом. Я пишу крупные торговые приложения для хедж-фондов, торговых торговых столов, взаимных фондов и т.д. Так:

• Вещи, которые нарушают соблюдение или вызывают другие юридические проблемы, очень плохи <4 >
• Вещи, которые могут вызвать чрезмерную торговлю (вы хотели купить 100 000 акций DTE, но мы получили вас 100,200), очень плохо 3%
• Вещи, которые мешают клиенту торговать, когда они хотят, очень плохие.
• Вещи, которые неудобства для клиента очень плохие

На днях я разговаривал с менеджером Bug Triage, который работает в другой области. Он просто сказал:

Сначала я исправляю сбой, затем я исправляю то, что заставляет нас терять деньги, тогда я исправляю то, что заставляет нас выглядеть плохо, затем я исправляю все остальное.

Ответ 7

Вещи, которые влияют на серьезность, я еще не видел в этом посте.

• SLA - влияет ли это на SLA?
• Внутреннее (техническое обслуживание) и внешнее преимущество. Внешняя выгода почти всегда получает более высокий приоритет.
• Visual vs Functional - функционал обычно получает более высокий приоритет
• Кто нашел? (клиент и коллега) - Клиент получает более высокий приоритет

Ответ 8

По моему опыту, это просто:

• Тяжесть ошибки
• Количество свободного времени разработки до релиза.

Ответ 9

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

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

Ответ 10

Как правило, мы исправляем любую ошибку, которая приводит к сбою системы за пределами цикла выпуска.

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

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

Ответ 11

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

Ответ 12

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

Однако я нашел следующие две метрики полезным ориентиром.

• Сколько пользователей затронуто?
• Насколько сильно они затронуты?

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

Ответ 13

Я согласен с @Chris Upchurch, но я думаю, что ключевым фактором является согласие всех сторон, прежде чем вы попадете в хруст. Таким образом, вы можете сбивать свой контрольный список с минимальным скрежетом зубов и грудным обстрелом.

Ответ 14

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

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

• Если вы обнаружите ошибку, сообщите об ошибке.
• Если вы можете исправить это, сделайте это. (отчет выражается, поскольку наличие ошибки может потребовать отчет)
• Если руководитель группы понимает ошибку, приоритет должен быть назначен (или другие меры, используемые командой). Добавьте "что это действительно значит". Важно, чтобы руководитель команды (некоторые) контролировал список ошибок.
• Исправлены ошибки/приоритеты на уровне управления. Неиспользуемые ошибки - это зияющий риск, и полномочия, которые должны иметь возможность понять риск.
• В любом случае, у вас есть проект с широким представлением о том, что такое верхние ошибки (это может быть раздельно для приоритета, например, списка из 5)
• Поощряйте программистов исправлять ошибки вместе с задачами разработки.

THEN, когда вы рассматриваете выпуск.

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