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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

принципы

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

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

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

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

Прагматизм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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