Представьте себе следующий сценарий:

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

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

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

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

Время / крайний срок давления являются одной из причин.

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

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

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

Хитрость заключается в том, что после того, как срочность исчезла, действительно трудно убедить кого-либо отдать приоритет замене бандажа истинным исправлением. Особенно с учетом того, что за первым всегда стоит другая неотложная проблема. Вы просто должны быть бдительны, чтобы оставаться в стороне от проблемы, которую нельзя быстро исправить.

Время

Является ли причина № 1 на мой взгляд. Хотя, если проблема в кодовой базе, я мог бы потратить больше времени на ее изучение. Часто мои "бинтовые" исправления включают в себя настройки CSS или UI. Я написал несколько довольно неприятных встроенных CSS и JavaScript, чтобы быстро с ними справиться. Возвращаясь и исправляя это всегда вариант, если у вас есть время.

Мы делаем их исключительно.

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

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

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

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

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

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

Disambiguation.

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

Во-первых, относительно частоты исправлений «повязки»:

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

Во-вторых, мой совет:

Если ошибка происходит в собственном исходном коде команды разработчиков:

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

Если ошибка возникает в исходном коде другой команды:

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

Если ошибка возникает в продукте другой компании (или не компании):

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

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

Я бы сказал, что это очень распространено.

Ознакомьтесь с постом Джоэла Спольски в блоге: Программатор магнитофонов

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

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

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

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

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

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

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

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

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

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

Вместо того, чтобы помещать ifвнутрь чью-то функцию, я бы поставил функцию {$ifdef}вокруг - таким образом, никто не путает ее с чем-то, что должно быть там.