Есть ли незначительная выгода в исправлении ошибок [закрыто]

27

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

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

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

Гекхан Курт
источник
2
Ваш вопрос довольно неясен. «не все ошибки нужно быть исправлены» означает Есть некоторые , которые не стоит быть фиксированы. «Есть ли действительно незначительная выгода в исправлении ошибок», для меня это звучит как нечто другое. Не могли бы вы объяснить?
Док Браун
2
Разве это не для владельца продукта, чтобы выяснить? Почему вы думаете, что вам нужно убедить их в этом?
Прекратить причинять вред Монике
@Goyo Я не задаю этот вопрос специально, чтобы убедить их. С этой концепцией я столкнулся некоторое время назад, но не могу найти больше ресурсов. Кроме того, разработчик программного обеспечения нередко занимает руководящую должность. Так что я сам могу нуждаться в этой информации в будущем.
Гекхан Курт,
2
@ GökhanKurt: Из «Все ошибки необходимо исправить» не следует, что все они одинаково важны. Некоторые могут быть более разрушительными, чем другие, и поэтому имеют более высокий приоритет.
JacquesB

Ответы:

66

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

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

Все эти факторы должны быть приняты во внимание при расстановке приоритетов.

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

JacquesB
источник
Мне нравится этот ответ, но я бы не сказал, что новая функция не требует постоянных затрат. Обычно требуется сделать код более общим, чтобы приспособиться к новой функциональности, и вам придется жить с более высоким уровнем абстракции, независимо от того, какую ценность на самом деле обеспечивает функция.
Довал
25
@Doval Вы неправильно поняли. То, что сказал Жак, - функция, которая еще не написана, не имеет эксплуатационных расходов. Или, другими словами, отсутствие функции не затрудняет реализацию другой функции (если, конечно, последняя не зависит от первой). Ошибка, с другой стороны, затрудняет выполнение чего-либо еще, кроме исправления. Таким образом, «неписанные функции» и «нефиксированные ошибки» различаются тем, что первое не влияет на вашу кодовую базу, а второе - влияет.
Себастьян Редл
3
Я бы добавил, что ошибка также может оказать большое влияние на имидж программы (и, следовательно, продукта в целом и компании, которая его произвела) ... Это следует учитывать: делать, кто хочет оставить ошибку, когда, если найден, может стоить компании некоторых клиентов и / или бизнеса?
Оливье Дюлак
2
В качестве примера заражения багов: в одном из моих проектов все работало нормально, за исключением того, что память освобождалась фрагментом кода, который не всегда работал. Как это случилось, во всем коде, который я написал до того, это всегда было; У меня не было ни утечек памяти, ни двойных освобождений, только некоторые журналы отладки, которые казались не в порядке. Так как все работало, я не исправил это. Затем я добавил еще немного кода, который больше не выстраивался в линию, и у меня начались утечки памяти. Подобные ошибки незначительны, но их стоит исправить; к сожалению, их также трудно отличить от незначительных ошибок.
Фонд Моника иск
5
Просто чтобы расширить точку зрения @ OlivierDulac, ошибка может заставить конечного пользователя подумать: «Я не могу доверять этому программному обеспечению как надежному» и отказаться от него, несмотря на его особенности. Я уверен, что мы все установили какое-то программное обеспечение, которое показалось мне действительно полезным только для того, чтобы удалить его через несколько минут, потому что оно показалось сбойным. Принимая во внимание, что отсутствующая функция может быть замечена, но оставьте конечного пользователя, думая: «Я собираюсь продолжать использовать это, потому что мне нравятся функции, которые у него есть». Я не думаю, что ошибки и функции должны рассматриваться как эквивалентные с точки зрения бизнеса.
Джон Бентли,
12

Вот хорошая ссылка

http://www.joelonsoftware.com/articles/fog0000000043.html

Вы исправляете ошибки перед написанием нового кода? Самая первая версия Microsoft Word для Windows считалась проектом «марша смерти». [...] потому что фаза исправления ошибок не была частью формального графика [...]

Microsoft универсально приняла что-то [...], и наивысшим приоритетом является устранение ошибок перед написанием любого нового кода [...]. В общем, чем дольше вы ждете, пока исправляете ошибку, тем дороже (по времени и деньгам) ее исправление ,

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

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

Walfrat
источник
3

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

Предполагая, что вы работаете в коммерческой организации, наверняка найдется кто-то, кто знает об анализе затрат и выгод .

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

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

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

Смотрите также эти два сообщения здесь по разработке программного обеспечения:

Решение каких ошибок даст наибольшую экономическую выгоду

Почти каждая обнаруженная ошибка является ошибкой высокого приоритета

AakashM
источник
2

Не все непреднамеренные или нежелательные аспекты поведения программного обеспечения являются ошибками. Важно обеспечить, чтобы программное обеспечение имело полезный и задокументированный диапазон условий, в которых можно положительно работать. Рассмотрим, например, программу, которая должна принимать два числа, умножать их и выводить результаты, и которая выдает фиктивное число, если результат больше 9,95, но меньше 10,00, больше 99,95, но меньше 100,00 и т. Д. Если программа была написана с целью обработки чисел, произведение которых было между 3 и 7, и никогда не будет вызываться для обработки каких-либо других, исправление ее поведения с 9,95 не сделает ее более полезной для ее предполагаемой цели. Однако это может сделать программу более подходящей для других целей.

В ситуации, подобной приведенной выше, возможны два разумных варианта действий:

  1. Исправьте проблему, если это целесообразно.

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

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

Даже если неспособность правильно обрабатывать значения от 99,95 до 100,0 является результатом ошибки программирования (например, решение вывести две цифры слева от десятичной точки перед округлением до одного места после, получая, таким образом, значение 00,00), это следует рассматривать только как ошибка, если в противном случае программа будет указана как производящая значимый вывод. [Между прочим, вышеупомянутая проблема возникла в коде печати Turbo C 2.00; в этом контексте это явно ошибка, но код, который вызывает неисправный printf, будет ошибочным только в том случае, если он выдаст выходные данные в проблемных диапазонах].

Supercat
источник
0

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

Обычно происходит то, что бизнес встречается с техническими лидерами и заинтересованными сторонами, чтобы обсудить ошибки, которые явно не находятся в «необходимости исправления». Они решат, стоит ли время (= деньги), потраченное на исправление ошибки, для бизнеса.

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

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

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

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

Korthalion
источник
-4

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

Таким образом, их «аргумент» на самом деле

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

Ошибки должны быть расположены по приоритетам и обрабатываться «по порядку» точно так же, как новые функциональные запросы (но, возможно, сверх всех последних).

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