Формула исправления ошибки

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

(Я предупреждал вас… вы все еще успеваете…)

Невоспроизводимый сценарий

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

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

Он не сдается! Он должен увидеть проблему. Его глаза - единственная надежная вещь ... что бы ни говорили другие люди: он должен это видеть, потому что, очевидно, другие люди могут быть сбиты с толку.

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

Но… бывают случаи, когда заказчик сообщает о проблеме и… ее невозможно воспроизвести. Тем не менее заказчик настаивает на том, что проблема существует, и поэтому похоже, что разработчик виноват, если он не может ее воспроизвести.

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

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

Поэтому, уважаемый разработчик, перестаньте болтать: просто сконцентрируйтесь на устранении проблемы, которую вы никогда не видели и которую не можете воспроизвести!

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

Патч лучшего предположения

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

Таким образом, работа разработчика начинается во имя «наилучшего предположения».

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

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

В большинстве случаев это лучшая попытка внести исправление.

Это игра на ставки.

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

Главный вопрос здесь…. Будет ли это работать?
Что нужно перевести на: «исправлен ли код - для проблемы, которую вы никогда не могли воспроизвести - правильной?».

Формула исправления ошибки

Я выяснил, что это вопрос вероятности, и уточнил формулу.

Следует учитывать несколько аспектов.

Количество изменений

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

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

Существование:

  • lch количество измененных, добавленных или удаленных строк кода в одном файле (без учета комментариев);
  • ltot общее количество строк кода в этом файле;
  • fch общее количество измененных файлов;
  • f1… fn файл 1, файл 2… до файла N

У нас есть:

[(1 - lch / ltot) f1 + (1 - lch / ltot) f2 +… .. + (1 - lch / ltot) fn] / fch

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

Выравнивание планет

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

Наиболее важным из них, вероятно, является выравнивание планет.

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

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

Что касается более позднего, существует две точки зрения: первая утверждает, что важно время, когда будет произведена последняя двоичная сборка.

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

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

С этого веб-сайта (http://www.theplanetstoday.com/) можно узнать углы между Землей и двумя ближайшими планетами. Первый ракурс - время начала, второй - время окончания.

Существование:

  • sa начальный угол (например, между Ураном, Землей и Меркурием)
  • fa окончательный угол (опять же между ними тремя)

Соответствующая часть формулы:

1 — (fa — sa) /100

Важность ИП

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

Окончательная формула

Теперь, сложив все биты вместе, мы можем получить bfp, что означает вероятность исправления ошибки:

bfp = 1/2 * {[(1 - lch / ltot) f1 + (1 - lch / ltot) f2 +… .. + (1 - lch / ltot) fn] / fch} +1/2 * {1 - (fa - sa) / 100}

Выводы (с примером)

Давайте представим реальный случайный сценарий. Данный:

  • Всего изменено 3 файла (fch)
  • Изменены соответственно 3, 1, 4 строки (lch)
  • И общее количество строк в этих файлах: 127, 201, 216 (ltot).
  • Для исправления, которое заняло 10 дней, когда угол наклона планет составлял от 137 до 98 градусов,

У нас есть:

bfp = 1/2 {[(1–3 / 127) f1 + (1–1 / 201) f2 + (1–4 / 216) fn] / 3} +1/2 {1 - (137–98) / 100}

bfp = 1/2 {[0,976 + 0,995 + 0,981] / 3} +1/2 {1–0,124}

bfp = 1/2 {0,984} +1/2 {0,876}

bfp = 0,93

Таким образом, вероятность исправления этой ошибки составляет: 93%, что довольно здорово!

Что делать, если не работает? Что ж…. это просто вероятность!