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

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

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

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

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

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

EDIT:

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

128 голосов | спросил Tiago Marinho 17 +03002016-10-17T08:16:30+03:00312016bEurope/MoscowMon, 17 Oct 2016 08:16:30 +0300 2016, 08:16:30

16 ответов


164

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

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

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

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

ответил mcottle 17 +03002016-10-17T08:36:29+03:00312016bEurope/MoscowMon, 17 Oct 2016 08:36:29 +0300 2016, 08:36:29
80

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

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

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

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

ответил pjc50 17 +03002016-10-17T18:40:41+03:00312016bEurope/MoscowMon, 17 Oct 2016 18:40:41 +0300 2016, 18:40:41
33

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

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

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

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

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

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

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

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

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

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

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

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

ответил Kevin Workman 17 +03002016-10-17T18:32:10+03:00312016bEurope/MoscowMon, 17 Oct 2016 18:32:10 +0300 2016, 18:32:10
13

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

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

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

  

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

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

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

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

  

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

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

ответил Vladimir Stokic 17 +03002016-10-17T10:10:43+03:00312016bEurope/MoscowMon, 17 Oct 2016 10:10:43 +0300 2016, 10:10:43
12

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

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

  • Если ошибка затрагивает только 1% ваших пользователей, а вашему игроку не хватает поддержки для функции, требуемой еще на 20%, выбор очевиден. Документируйте ошибку, затем продолжайте.
  • Если исправление включено в список todo, часто бывает лучше исправить его, прежде чем вы начнете добавлять новые функции. Вы получите преимущества процесса разработки программного обеспечения с нулевым дефектом, и вы не потеряете много времени, так как все равно в вашем списке.
ответил Dmitry Grigoryev 17 +03002016-10-17T17:34:04+03:00312016bEurope/MoscowMon, 17 Oct 2016 17:34:04 +0300 2016, 17:34:04
5

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

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

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

ответил JoulinRouge 17 +03002016-10-17T14:58:26+03:00312016bEurope/MoscowMon, 17 Oct 2016 14:58:26 +0300 2016, 14:58:26
5

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

ответил Lightness Races in Orbit 17 +03002016-10-17T19:26:55+03:00312016bEurope/MoscowMon, 17 Oct 2016 19:26:55 +0300 2016, 19:26:55
5

В описанной ситуации на самом деле три ошибки:

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

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

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

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

ответил Bent 17 +03002016-10-17T12:56:10+03:00312016bEurope/MoscowMon, 17 Oct 2016 12:56:10 +0300 2016, 12:56:10
4

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

ответил Buhb 17 +03002016-10-17T23:14:17+03:00312016bEurope/MoscowMon, 17 Oct 2016 23:14:17 +0300 2016, 23:14:17
2

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

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

ответил Aleksandra 18 +03002016-10-18T10:39:39+03:00312016bEurope/MoscowTue, 18 Oct 2016 10:39:39 +0300 2016, 10:39:39
1

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

  

Помогает ли кто-нибудь?

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

ответил topo morto 18 +03002016-10-18T01:46:07+03:00312016bEurope/MoscowTue, 18 Oct 2016 01:46:07 +0300 2016, 01:46:07
1

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

Принципы

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

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

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

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

Прагматизм

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

Сбой быстро, не работает

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

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

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

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

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

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

ответил AnoE 19 +03002016-10-19T16:08:44+03:00312016bEurope/MoscowWed, 19 Oct 2016 16:08:44 +0300 2016, 16:08:44
0

Приходят на ум три вещи:

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

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

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

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

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

ответил Alfe 19 +03002016-10-19T16:04:48+03:00312016bEurope/MoscowWed, 19 Oct 2016 16:04:48 +0300 2016, 16:04:48
0

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

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

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

  • Что означает «очень низкая скорость»?
  • Что означают «умеренные последствия»?

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

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

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

Препятствуйте вашей интуиции реальным данным мира

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

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

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

Заключение

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

ответил Lucas 2 32016vEurope/Moscow11bEurope/MoscowWed, 02 Nov 2016 12:08:42 +0300 2016, 12:08:42
-1

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

Вопрос не в том, «должен ли я исправить эту ошибку или не исправить эту ошибку». У любого разработчика ограниченное количество времени. Поэтому возникает вопрос: «Какая самая полезная вещь, которую я могу сделать за один час, четыре часа или неделю».

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

ответил gnasher729 21 +03002016-10-21T00:50:13+03:00312016bEurope/MoscowFri, 21 Oct 2016 00:50:13 +0300 2016, 00:50:13
-2

Исправление ошибок всегда overkill

Сначала классифицируем ошибку .

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

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

Итак, не пытайтесь просто исправить .

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

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

P.S. извинения за крайний взгляд.

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

ответил Dima Tisnek 19 +03002016-10-19T14:46:51+03:00312016bEurope/MoscowWed, 19 Oct 2016 14:46:51 +0300 2016, 14:46:51

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132