Когда исправление ошибок становится излишним, если вообще?

128

Представьте, что вы создаете видеоплеер на JavaScript. Этот видеопроигрыватель многократно зацикливает видео пользователя, используя рекурсивную функцию, и поэтому браузер too much recursion RangeErrorв какой-то момент запускает .

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

  • Исправить ошибку

  • Оставь ошибку

Разве вы не должны только исправлять ошибки, с которыми люди могут столкнуться? Когда исправление ошибок становится излишним, если это когда-либо происходит?

РЕДАКТИРОВАТЬ:

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

Тьяго Мариньо
источник
95
Не связывайтесь с моим партнером по сценарию примера
Тьяго Мариньо
15
@PlasmaHH Я использую этот гипотетический сценарий, чтобы объяснить мой вопрос. Если ошибка существует или нет, это не имеет значения
Tiago Marinho
13
@TiagoMarinho: я пытаюсь сказать следующее: иногда правильно определить такой сценарий как предполагаемое поведение.
PlasmaHH
23
С какой стати вы запускаете такой цикл, используя рекурсию в первую очередь? Возможно, вы не захотите исправлять ошибку, но вам обязательно следует пересмотреть процесс проектирования :-)
jamesqf
28
Это больше похоже на деловой вопрос. Вы должны расставить приоритеты исходя из стоимости исправления и влияния / частоты ошибок.
Кейси Кубалл

Ответы:

164

Вы должны быть прагматичными.

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

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

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

mcottle
источник
119
Полностью согласен с «Вы будете удивлены тем, насколько хорошо конечные пользователи преодолевают границы и выявляют дефекты».
Пятнистый
74
Конечные пользователи никоим образом не ограничены тем, что вы считаете разумным использованием вашего программного обеспечения. Будут пользователи, которые хотят зациклить видео навсегда. Это функция, которую предоставляет ваше программное обеспечение, поэтому они будут ее использовать.
gnasher729
36
@ gnasher729 Видео «10-часовой XXXX» на Youtube является хорошим идентификатором, который, действительно, некоторые люди просто хотят зациклить что-то навсегда.
Крис Cirefice
23
Другая проблема: если ваше программное обеспечение популярно, то кто-то сталкивается с ошибкой, которая действительно возникает только в редких ситуациях, публикует ее в Интернете, и вдруг все и их собака говорят: «Это программное обеспечение - мусор, оно вылетает, если я зацикливаю видео для день". Или конкурент использует его, чтобы продемонстрировать, как легко вывести из строя ваше приложение.
gnasher729
4
Акцент на последнем абзаце. Знаете ли вы, что MacOS Classic потерпит крах, если он получит 32 768 последовательных событий «нажатия мыши» без промежуточного события «отпускания мыши»?
Mark
79

В Windows 95 была похожая ошибка, приводившая к сбою компьютеров через 49,7 дня . Это было замечено только через несколько лет после выпуска, так как очень немногие системы Win95 так долго работали. Таким образом, есть один момент: ошибки могут быть признаны не относящимися к другим, более важным ошибкам.

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

  • Это программное обеспечение на границе безопасности?
  • Если да, может ли эта ошибка привести к эксплойту?
  • Является ли это программное обеспечение «критически важным» для предполагаемых пользователей? (Смотрите список вещей, которые Java EULA запрещает вам использовать )
  • Может ли ошибка привести к потере данных? Финансовый убыток? Репутационные потери?
  • Насколько вероятна эта ошибка? (Вы включили это в свой сценарий)

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

pjc50
источник
2
Я также вспоминаю (аппаратную) ошибку в некоторых процессорах Intel, когда определенное значение с плавающей запятой пошло не так.
5
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug - это то, на что, я полагаю, вы ссылаетесь. Проснулся за год, прежде чем кто-нибудь это заметил.
Jeutnarg
10
@ gnasher729 - Не совсем, они уже были внизу и все еще копали :) Большинству людей приходилось переустанавливать Win 95 чаще, чем за 49,7 дней IIRC.
Макоттл
4
@Luaan Комментарий был задуман как легкомысленный раскоп в M $, отсюда и смайлик после первого предложения. Они были за восьмым мячом с '95, потому что он вышел очень поздно в 95 году (вероятно, потому что выпуск Win95 в 1996 году был бы плохим видом), наполовину испеченным (Помните USB BSOD?) И склонным становиться нестабильным и требовать регулярной переустановки отсюда мое второе предложение - в котором никогда не упоминалось о запуске сервера в Windows 95, я не знаю, откуда вы это взяли (воспоминания?). Второй релиз CD улучшил ситуацию, но первоначальный выпуск '95 был ошеломительным.
Маккоттл
5
Т.Б. Я думаю, что фиаско «Windows for Warships» нанесло больший ущерб репутации ( archive.wired.com/science/discoveries/news/1998/07/13987 ) и использовало NT. Машины Unix того времени могли справляться с многолетним простоем даже при использовании (очень ранних) версий Linux. Все домашние компьютеры также были способны работать без перебоев, хотя редко использовались таким образом. Я видел микросхемы BBC, встроенные в образовательные экспонаты спустя десятилетие после того, как они устарели.
pjc50
33

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

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

Глядя на ваш пример, я вижу пару предположений:

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

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

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

Неопознанные предположения являются огромным источником ошибок.

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

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

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

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

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

Кевин Воркман
источник
Очень хороший момент, Кевин. Обратите внимание на мой комментарий к выбранному ответу выше, который фокусируется на вопросе анализаWhat's the worst thing that could happen?
OMY
Другое предположение здесь состоит в том, что постоянно растущий стек приведет к проблемам только тогда, когда он достигнет размера переполнения. Фактически, стек может быть нормальным ресурсом, этот баг постоянно пропускает. Весь браузер может становиться все медленнее и медленнее крошечными битами на каждой итерации ^ H ^ H ^ H ^ H ^ H ^ Hrecursion.
Alfe
1. ОП никогда не говорил, что проблема вызвана растущим стеком. Это также легко может быть вызвано ошибкой в ​​подпрограмме счетчика (dec -> div / 0?). 2. Если проблема не является проблема переполнения стека , то не следует ли этот вопрос отвечала в StackOverflow? <rimshot!> ;-D
OMY
@OMY Кому направлен этот комментарий?
Кевин Воркман
13

Я бы порекомендовал вам прочитать следующую статью:

Надежность и ее угрозы: таксономия

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

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

Описав это, все сводится к соотношению затрат и выгод. Стоимость будет состоять из трех параметров:

  • Как часто эта проблема возникает сама собой?
  • Каковы будут последствия?
  • Насколько это вас беспокоит лично?

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

Это не личное. Это бизнес.

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

Владимир Стокич
источник
«Это не личное. Это бизнес »от Майкла, я думаю, а не от Вито. (Вы были бы удивлены, насколько хорошо конечные пользователи способны
преодолевать
На самом деле, это Вито, если вы читаете книгу. Даже в фильме именно Том Хаген сначала говорит, когда спорит с Сонни о том, стоит ли им ходить на матрасы, и только после этого Майкл впервые произносит знаменитую цитату: «Это не личное, Сонни. Это сугубо бизнес». . ". Но Хаген узнал об этом от Вито.
Владимир Стокич
11

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

Ответ на что вы делаете? это действительно деловое, а не инженерное решение:

  • Если ошибка затрагивает только 1% ваших пользователей, а у вашего плеера отсутствует поддержка функции, которая требуется еще на 20%, выбор очевиден. Документируйте ошибку, затем продолжайте.
  • Если исправление присутствует в вашем списке задач, часто лучше его исправить, прежде чем начинать добавлять новые функции. Вы получите преимущества процесса разработки программного обеспечения без дефектов, и вы не потеряете много времени, так как он в любом случае находится в вашем списке.
Дмитрий Григорьев
источник
5

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

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

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

JoulinRouge
источник
6
Окупаемость инвестиций в исправление ошибки оценивается редко - обычно вам приходится полагаться на свое мнение.
Ant P
Возврат, который принесет исправление, - это в основном репутация, которую практически невозможно определить количественно. Если я единственный, кто даже знает, что может быть ошибка, а затем через год или два я поменяю работу, и новая компания подумывает о внедрении видеоплеера в свой продукт (возможно, продавая миллионы единиц), я бы порекомендовал использовать этот?
Джерри Иеремия
@JerryJeremiah, если ошибка мешает запуску бизнес-процесса, речь идет не о репутации, это зависит от важности бизнес-процесса. И в каждом случае и в каждой политике, которую вы применяете для исправления ошибок или нет, вы должны делать субъективную оценку на основе вашего опыта и знаний. Даже если вы знаете точное число пользователей, которые столкнутся с ошибкой, вам все равно придется сделать человеческий выбор (также политика ROI может также включать статистику попаданий ошибок для оценки затрат). Поскольку сегодня нет никакого механического способа узнать априори, что нужно делать.
JoulinRouge
5

tl; dr Вот почему RESOLVED/WONTFIXэто вещь. Только не злоупотребляйте этим - технический долг может накапливаться, если вы не будете осторожны. Это фундаментальная проблема с вашим дизайном, которая может вызвать другие проблемы в будущем? Тогда исправь это. В противном случае? Оставьте это, пока это не станет приоритетом (если это когда-либо будет).

Гонки легкости на орбите
источник
5

На самом деле в описываемой вами ситуации есть три ошибки:

  1. Отсутствие процесса для оценки всех зарегистрированных ошибок (вы записали ошибку в свой тикет / журнал невыполненных работ / какую бы систему вы ни установили, верно?), Чтобы определить, следует ли ее исправить или нет. Это управленческое решение.

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

  3. Проблема в том, что видео может перестать отображаться через очень долгое время.

Только из трех ошибок (3), возможно, нет необходимости исправлять.

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

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

Buhb
источник
2

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

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

Aleksandra
источник
2

Здесь есть три вещи:

принципы

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

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

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

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

Прагматизм

Это другая сторона. Из Конечно , вы, скорее всего, в данном конкретном случае, не исправить ошибку. Но будьте осторожны - прагматизм, а затем прагматизм. Хороший прагматизм - это если вы найдете быстрое, но надежное и обоснованное решение проблемы. То есть вы избегаете чрезмерного проектирования, но то, что вы на самом деле реализуете, все еще хорошо продумано. Плохой прагматизм - это когда вы просто взламываете что-то вместе, что работает «просто так» и сломается при первой же возможности.

Терпеть неудачу быстро, терпеть неудачу сильно

Если вы сомневаетесь, терпите неудачу быстро и терпите неудачу.

Это означает, среди прочего, что ваш код замечает состояние ошибки, а не среду.

В этом примере, по крайней мере, вы можете сделать так, чтобы не возникала жесткая ошибка времени выполнения («превышена глубина стека» или что-то в этом роде), заменив ее жестким исключением из ваших собственных. Вы можете, например, иметь глобальный счетчик и произвольно решить, что вы должны помочь после 1000 видео (или любого другого числа, которое достаточно велико, чтобы его нельзя было использовать при обычном использовании, и достаточно мало, чтобы работать в большинстве браузеров). Затем дайте этому исключению (которое может быть общим исключением, например, RuntimeExceptionв Java или простую строку в JavaScript или Ruby) значимое сообщение. Вам не нужно идти на то, чтобы создать новый тип исключений или что-то еще, что вы делаете на вашем конкретном языке программирования.

Таким образом, у вас есть

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

Мое соглашение состоит в том, чтобы префикс таких сообщений об ошибках со словом «Паранойя:». Это явный признак для меня и всех остальных, что я никогда не ожидаю, что эта ошибка всплывет. Я могу четко отделить их от «настоящих» исключений. Если я вижу такой в ​​графическом интерфейсе или в лог-файле, я точно знаю, что у меня серьезная проблема - в конце концов, я никогда не ожидал, что они возникнут. На этом этапе я перехожу в режим анализа (с хорошим шансом решить его быстро и довольно легко, так как я точно знаю, где возникла проблема, избавив меня от многих ложных отладок).

Anoe
источник
2
Извините, если вы так думаете о том, как скоро я принял ответ. В свою защиту я просто не знал, что вопрос будет иметь> 10 000 просмотров и столько ответов на момент принятия. Во всяком случае, я все еще не передумала на лучший ответ.
Тьяго Мариньо
@TiagoMarinho, нет проблем, комментарий не был направлен в первую очередь на вас лично, и я не ожидал, что вы пересмотрите его. ;) Меня больше озадачивает мотивация того, кто бы ни проголосовал за фактическое удаление моего ответа ... Кроме того, здесь есть некоторое отрицательное голосование за несколько ответов без каких-либо комментариев. Не уверен, так ли это в конкретной области ЮВ.
AnoE
Я полностью согласен о странном понижении голосов
Tiago Marinho
Интересно, если, по крайней мере, в этом случае лечение лучше лечения. Если вы решаете, следует ли выполнять специальную обработку для дефекта проектирования, который вы уже определили, имеет смысл сравнить полную стоимость жизненного цикла: а) реализации обработки ошибок и потенциального воздействия на ошибку, когда она возникает, путем исправления ошибки. дизайн, или б) просто исправление дизайна в первую очередь.
Jaxter
@ Джакстер, точно. Отсюда мой подход: открыть разум для исправления ошибки (даже если это кажется излишним), но когда вы решаете не исправлять ошибку, тогда, по крайней мере, реализуйте отказоустойчивую вещь. Очевидно, что если отказоустойчивое решение в первую очередь дороже, чем «реальное» исправление, то избегайте его и исправьте.
AnoE
1

Пост-это на столе старшего разработчика на моем рабочем месте говорит

Это кому-нибудь помогает?

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

топо морто
источник
0

На ум приходят три вещи:

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

Во-вторых , ошибки имеют тенденцию оказывать большее влияние, чем кажется на первый взгляд. Мы все хорошо знакомы с рабочим кодом, потому что это «нормальный» случай. Ошибки, с другой стороны, являются «исключением». Конечно, мы все видели много ошибок, но в целом мы видели гораздо больше работающего кода. Поэтому у нас больше опыта работы с рабочим кодом, чем с ошибками в работе кода. Существует множество книг о рабочем коде и о том, что он будет делать в каких ситуациях. Есть почти ничего о поведении глючного кода.

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

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

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

Альфей
источник
2
Пожалуйста, оставьте комментарий, когда вы понижаете. Мы должны знать, что такое критика, чтобы улучшить ответ.
Alfe
0

Низкая вероятность / Легкие последствия = Низкое исправление приорты

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

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

  • Что вообще означает "очень низкое вхождение"?
  • Какие "легкие последствия" вообще значат?

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

Большинство разработчиков удивляются, что то, о чем они изначально думали, никогда не случится, на самом деле многое случается

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

Сопоставьте свою интуицию с данными реального мира

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

Мой пример легкой проблемы и меры контроля

На сайте электронной коммерции, где я работал давным-давно, другой программист допустил ошибку: в некоторых неясных условиях система списывала клиента на один цент меньше, чем было зарегистрировано в журналах. Я обнаружил ошибку, потому что сделал отчеты, чтобы выявить различия между журналами и балансами счетов, чтобы сделать систему учета более устойчивой. Я никогда не исправлял эту ошибку, потому что разница была очень маленькой. Разница рассчитывалась ежедневно и была ниже 2,00 долларов США в месяц. Так получилось, что мы разрабатывали совершенно новую систему, которая через год должна заменить нынешнюю. Не имеет смысла отвлекать ресурсы от потенциально прибыльного проекта, чтобы исправить что-то, что стоит 2 доллара США в месяц и подвергалось соответствующей мере контроля.

Заключение

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

Лукас
источник
-1

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

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

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

gnasher729
источник
Не уверен, что утилитарная метрика лучше всего работает здесь. Понятно, что пример видеоплеера был спроектирован так, чтобы быть малоэффективным, но даже это не надежно. Один из них уже процитировал промо-цикл 24/7 в лобби-прецеденте, а другой мог бы быть киоском на конференции по продажам и технологиям, которая проходит неделю. И то и другое будет стоить репутации и / или денег для бизнеса, так что нетривиально.
Jaxter
Это означало бы, что исправление ошибки дает больше преимуществ, чем первоначально ожидалось, поэтому она должна быть выше в приоритетах. Таким образом , вы будете иметь больше успеха в жизни , если ваше мнение о том, что является наиболее полезным согласуется с реальностью как можно больше.
gnasher729
-2

Исправление ошибок всегда является излишним

Давайте сначала классифицируем ошибку .

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

Однако, если это на самом деле недостаток дизайна, как и в вашем случае, вам следует переоценить дизайн или, в худшем случае, отключить эту функцию.

Поэтому, пожалуйста, не пытайтесь просто исправить это.

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

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

PS извиняюсь за крайний взгляд.

PPS Примечание по терминологии: вы не можете «исправить» ошибку. Ну, может ветеринар может, но давайте не будем идти туда ;-). Проблемы решаются или «исправляются», а ошибки удаляются или обходятся.

Дима Тиснек
источник
Вы действительно хотели сказать, что это всегда "перебор"? Я думаю, вы могли где-то перепутать определения. Overkill означает «работать сверх того, что требовалось», или, другими словами, это больше, чем кто-либо должен делать. Вы утверждаете, что исправление ошибок всегда чрезмерно, но одновременно с умением просить людей недостаточно работы, и мы должны выполнять больше работы, что не имеет смысла.
Doppelgreener
@doppelgreener Я вижу, как это может сбить с толку. исправление ошибок - ужасная практика, и ее никогда не следует делать. С другой стороны, адаптация дизайна или архитектуры программного обеспечения к изменяющимся требованиям является хорошей практикой, которой необходимо следовать. То же самое для исправления честных ошибок при условии, что все сделано правильно.
Дима Тиснек
2
Я не знаю, о каком исправлении ошибок вы говорите, но в моем повседневном мире «изменение архитектуры» - это метод исправления ошибок. Вы можете определить, что вы собираете, под термином «исправление ошибок».
Doppelgreener
@doppelgreener - Термин «исправить» имеет особое значение в некоторых формах управления качеством, и это специальное использование было принято многими менеджерами по программированию. « Исправление » - это только временное решение или обходной путь, тогда как истинное « решение » проблемы требует выявления и устранения « первопричины ». В программном обеспечении ошибка , может быть столь же просто , как неуместная запятая , где исправление (исправление запятой) IS решения, но если ошибка вызвана чем - то больше , то исправить (например: петля ограничители) будут не быть таким же , как решение (редизайн / переписывание).
OMY
2
@OMY Спасибо за объяснение. Я чувствую , что , поскольку такое определение «исправить» не используется вопросом, ответ должен реагировать на смысл этого слова, это используется.
Doppelgreener