Исправлять ошибки или ждать, пока клиент их найдет?

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

Пример 1

 Customer customer = null;
 ...
 customer.Save();

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

Но также немыслимо исправление кода:

Customer customer = null;
...
customer = new Customer();
try
   ...
   customer.Save();
   ...
finally
   customer.Free();
end;

может ввести аварии; один не обнаружен в модульных тестах с полным охватом и ручным тестированием пользователя.

Пример 2

float speed = 0.5 * ((G * mass1 * mass2) / R) * Pow(time, 2);

Люди, знающие физику, поймут, что в знаменателе должен быть R ² .

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

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

float speed = 0.5 * ((G * mass1 * mass2) / Pow(R, 2)) * Pow(time, 2);

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

Пример 3

Вот пример, который я недавно имел, проверяя, содержит ли строка недопустимые символы:

if (StrPos(Address, "PO BOX") >= 0)
{
   //Do something
}

Что если окажется, что в Do somethingветке есть ошибка ? Исправление заведомо неверного кода:

if (StrPos("PO BOX", Address) >= 0)
{
   //Do something
}

Исправляет код, но вносит ошибку.

На мой взгляд, есть две возможности:

• исправить код и обвинить в его нарушении
• дождаться сбоя кода и обвинить в ошибке

Что ты политически делаешь?

Пример 4 - Сегодняшняя ошибка в реальном мире

Я создаю объект, но вызываю неправильный конструктор:

Customer customer = new Customer();

Оказывается, что конструктор «без параметров» на самом деле является параметризованным конструктором из глубины цепочки наследования:

public Customer(SomeObjectThatNobodyShouldBeUsingDirectly thingy = null)
public Customer(InjectedDependancy depends)

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

Я мог бы изменить происхождение объекта, чтобы не показывать такой опасный конструктор, но теперь я должен изменить код на:

Customer customer = new Customer(depends);

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

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

Я не могу поставить на это жизнь твоей жены.

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

Должен ли я:

• Исправить код и получить вину за его нарушение? или
• Оставить ошибку и получить вину, когда клиент ее обнаружит?

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

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

1. Зарегистрируйте дефект в системе отслеживания выбора. Обсудите с руководством / коллегами, если это необходимо.
2. Если это дефект с потенциально тяжелыми последствиями (например, ваш пример №2), бегите, кричите, прыгайте вверх и вниз, пока кто-то с полномочиями не заметит, и определите соответствующий порядок действий, который уменьшит риски, связанные с исправлением ошибки. Это может отодвинуть дату выпуска, спасти жизни, помыть окна и т. Д.
3. Если это неисправимый дефект или существует обходной путь, оцените, перевешивает ли риск его исправления выгоду от исправления. В некоторых ситуациях будет лучше подождать, пока клиент не сообщит об этом, поскольку вы знаете, что не тратите время на исправление / повторное тестирование, когда это не требуется на 100%.

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

Клиенты ВСЕГДА найдут ошибки . Там нет скрытых ошибок от клиентов, никогда. В конце концов, ошибки, которые вы вносите, всегда возвращаются к вам. Не исправлять их - это просто плохая профессиональная практика. Профессионалы не делают этого.

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

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

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

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

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

Что скажет клиент?

Вот как я представляю себе эту игру:

Клиент: он падает, когда я делаю х.

Программист: О да! Я помню, что видел это некоторое время назад. Я подумал, что это не имеет большого значения, поэтому я оставил это там.

Заказчик: [тянется к тупому предмету]

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

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

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

Я бы сказал, что это, вероятно, огромная ошибка, и, как пишет Бен Лори , не исправляйте ошибку, которую вы не понимаете . В этом знаменитом примере команда Debian взломала шифрование для OpenSSL для Debian и его производных, таких как Ubuntu, когда они следовали результатам анализа.

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

Начните отыгрывать свой технический долг, как только сможете .

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

В Примере 1, если Save()нет доступа к каким-либо данным экземпляра, какие данные клиента они точно сохраняют? Начните исправлять и тестировать это.

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

В примере 3 существует опасность возвращения мертвого кода к жизни. Должен ли этот код быть полностью исключен? Каково намерение логического условия под этим если? Чтобы убедиться, что строка не содержит недопустимых символов? Или убедиться, что в нем есть «PO BOX»? Чем раньше вы начнете отвечать на такие вопросы, тем лучше.

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

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

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

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

Решение этого двоякое:

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

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

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

Несколько моментов актуальны:

1. Контроль версий абсолютно необходим для этого процесса.
2. Этап рефакторинга и этап исправления ошибок лучше подходят для управления версиями в виде отдельных коммитов, поэтому каждый из них имеет четко определенные исторические функции.
3. Не зацикливайтесь на возможности сделать еще одну ошибку, вы ничего не сделаете. Скорее подумайте о том, как сделать ваш код лучше. Другими словами, если вы не знаете, что вы увеличиваете количество ошибок, а не уменьшаете их, вы должны это сделать.
4. В связи с последним пунктом: не пытайтесь предсказать будущее. Люди склонны думать, что они очень хороши в прогнозировании. На самом деле наши способности прогнозирования являются краткосрочными. Так что не беспокойтесь о неопределенной неопределенной будущей ошибке. Это также принцип ЯГНИ .
5. Соответствующим инструментом для контроля версий в мире ошибок является средство отслеживания ошибок . Вам это тоже понадобится.
6. Вам необходимо исправить ошибки по двум причинам: чтобы удовлетворить клиента; и для того, чтобы иметь возможность прогрессировать в своем развитии. Чтобы использовать пример 3 (физический): если программа удовлетворяет клиента таким нарушенным уравнением, то есть много других частей программного обеспечения, которые были неправильно разработаны для смягчения этой ошибки (например, развертывание подушки безопасности). Если для этого программного обеспечения требуется версия 2 (или 1.1), то вам будет все труднее разрабатывать правильный код на основе этого неисправного. Затем вы либо идете к большому переписыванию, либо к большому провалу. Оба из которых вы должны избегать.

Это уже больше, чем несколько пунктов, так что я думаю, что я остановлюсь здесь.

Сначала вы должны рассмотреть определение ошибки:

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

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

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

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

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

1. Код, который вы просматриваете, является мертвым кодом. Возможно, потому что, как сказал есолик, клиенты всегда находят ошибки. Если они этого не сделали, возможно, код никогда не будет выполнен.
2. Была ситуация WTF, где очевидная ошибка имела свое значение. (Мы говорим о производственном коде, все могло произойти, верно?)
3. Бизнес / клиенты уже знали о проблеме, но не чувствуют необходимости исправления.
4. Может быть, больше...

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

Должен ли я:

• исправить код и получить вину за его нарушение? или
• оставить ошибку и получить вину, когда клиент ее обнаружит?

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

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

Исправьте их, если они являются ошибками сбоя / потери данных. Поставка программы с известной ошибкой потери данных совершенно зловредна и непростительна.

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

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

Знать ошибки и НЕ сообщать о них ИМХО приемлемо только для действительно незначительных / косметических ошибок.

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

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

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

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

Правильный курс действий - ни игнорировать ошибку, ни «исправлять» ее на месте; по тем самым причинам, которые вы указали в своем вопросе.

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

• История : Используйте ваше программное обеспечение для контроля версий, чтобы ответить на вопросы: Кто коснулся кода? Что они изменили? И с какими сообщениями фиксации они проверяли это? Можете ли вы определить причину, по которой код выглядит так?

• Использование : Какой код использует ошибочный код? И как? Код мертв? Есть ли другой код, который полагается на ошибочное поведение?

• Автор . Если вы не можете быстро прийти к заключению, используя приведенную выше информацию, спросите автора кода (по крайней мере, если это возможно), почему код выглядит так, как он. Обычно вы получаете либо «Ой, это должно быть исправлено!» или "Нет! Не меняй это !!! Так нужно!" сразу.