Уявіть такий сценарій:

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

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

Для мене накладення пов’язки було б абсолютно неприйнятним. Якщо код поводиться на цьому вкладі несподівано, на який інший вхід, який ви пропустили, буде реагувати дивно? Це зовсім не здається виправленням - ви просто перекопуєте проблему під килим.

Оскільки я б навіть не думав це робити, я здивований тим, як часто професори та книги постійно нагадують нам про те, як застосовувати виправлення «пов’язки» - це не дуже гарна ідея. Тож це змушує мене замислитися: наскільки поширені такі види "виправлень"?

Час / термін тиску є однією з причин.

Якщо ви проти строгого терміну, і у вас начальник дихає шиєю (можливо, буквально!), То робити це і думати: "Я повернусь і виправлю це пізніше", це дуже спокусливо, і це може бути єдине, що ти можна зробити.

Звичайно, кількість разів, коли ви насправді повертаєтесь назад і правильно виправляєте їх, дуже мало і далеко між ними, тому що у вас є нова проблема, яка потребує виправлення вчора.

Наскільки ми, як програмісти, не любимо цього визнавати, гарно закодоване програмне забезпечення не завжди перетворюється на більшу цінність для компанії чи клієнтів. Це вдвічі вірно в ситуації стихійного лиха, наприклад, програмне забезпечення подвійно стягує кредитні картки людей. Іноді, як бинт, потрібно просто зупинити кровотечу будь-якими необхідними засобами і обіцяти повернутися після стабілізації пацієнта і фактично виправити основну проблему.

Хитрість полягає в тому, що після того, як терміновість пропаде, насправді важко переконати когось у пріоритеті заміни пов’язки справжнім виправленням. Особливо враховуючи, що за чергою завжди чекає ще одна нагальна проблема. Ви просто повинні бути пильними щодо того, щоб залишатися з проблемою поза швидким вирішенням.

Час

Чи є причиною №1 на мій погляд. Хоча якщо проблема є кодовою базою, я можу зайняти більше часу, щоб її дослідити. Часто мої виправлення "пов’язки" стосуються налаштувань CSS чи інтерфейсу користувача. Я написав кілька неприємних вбудованих CSS та JavaScript, щоб швидко з ними боротися. Повернення та виправлення - це завжди варіант, якщо ви знайдете час.

Ми робимо їх винятково.

Для виправлень під час розробки ми переконуємося, що жодне виправлення не робиться, не знаючи першопричини. Однак:

• За винятком пошуків першопричини почнуть затягуватися чи затримуватися І настає жорсткий термін,
• За винятком змін коду, щоб виправити першопричину, тактично недоцільно (зміна триватиме занадто довго і наближається термін)

У таких випадках ми вибираємо "бандажні" виправлення. Потім ми відкриваємо внутрішні дефекти для вирішення першопричини. Так, найчастіше ці внутрішні дефекти трактуються з дуже низьким пріоритетом.

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

• Дуже винятково пошук першопричини зупиниться,
• Винятком може статися так, що виправити першопричину тактично не представляється можливим (зміни нетривіальні, і клієнт потребував виправлення вчора).

У таких випадках ми спочатку вибираємо тимчасове виправлення "перев'язки", і коли клієнт задоволений, ми працюємо над правильним виправленням, і лише тоді дефект буде усунений

Однозначність.

• Враховуючи певну помилку, є значні труднощі в об'єктивному визначенні того, чи є конкретна фіксація «пов’язкою», оскільки: «правильне рішення» може бути «пов’язкою» іншої людини.
• Отже, я використовую таке визначення: щоб виправити дефект способом, який є менш елегантним і менш вивченим, ніж я б хотів, що зробив би професійно.

По-перше, щодо частоти виправлень "пов’язки":

• Новий код: майже немає.
• Старий код:
  • Ви знайдете деякі, хоча вони, як правило, написані досить елегантно (див. "Пом'якшення даних, спричинене даними" нижче) що вони не схожі на пов’язки і переживуть усі огляди коду.
  • Також зверніть увагу на "невидимий бандаж": просто не викликайте цю функцію. При відсутності коду не залишається навіть сліду натяку на наявність помилки.
• Старий код з багатьма зовнішніми залежностями:
  • Майже повно.
  • Він майже завжди писався для застарілої версії залежності, і ніхто насправді не читав "примітки до звільнення" залежності, перш ніж оновити залежність до нової версії.

По-друге, моя порада:

Якщо помилка трапляється у власному вихідному коді команди розробника:

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

Якщо помилка трапляється у вихідному коді іншої команди:

• Натисніть на цю команду, щоб виправити свою помилку.
• Завжди подайте цю помилку в систему відстеження дефектів іншої команди .

Якщо помилка трапляється в продукті іншої компанії (або немає):

• У цьому випадку виправлення канальних стрічок (або керованих даними обхідних шляхів) ) можуть бути єдиним способом виправити помилку.
• Якщо це відкритий код, все-таки подайте помилку в будь-яку (можливо, загальнодоступну) систему відстеження дефектів , щоб хтось міг її переглянути.

Дуже багато що залежить від віку кодової бази, на яку я думаю. Щодо старого коду, я думаю, що це дуже часто, переписуючи, що 20-річна програма COBOL не є цікавою. Навіть для помірно нового коду, який є у виробництві, він все ще досить поширений.

Я б сказав, що це дуже часто.

Перегляньте допис у блозі Джоела Спольського: Програміст стрічки

Я можу з легкістю сказати, що майже для кожного проекту, в якому я коли-небудь був, мені довелося застосувати якусь пов’язку або клейку стрічку, щоб виконати терміни та виконати завдання. Це не дуже, це не чисто, але він робить роботу, щоб бізнес міг продовжувати свою діяльність, і проект певним чином може рухатися вперед.

Існує різниця між академічним світом та реальним світом, де програмне забезпечення насправді потрібно поставляти під час та ділових контрактів.

Якимось чином це кладе його під килим, щоб відкласти виправлення, поки, сподіваємось, пізніше. На жаль, занадто часто відкладене виправлення ніколи не відбувається, і цей код знаходить свій шлях у виробництві.

Це важко сказати без більшого контексту - у вашому прикладі, чому додавання оператора if не є правильним виправленням? Це тому, що нібито там є якийсь інший блок коду, який повинен мати справу з цим входом?

Те, як часто використовуються виправлення пов’язок, залежить від ряду речей, таких як складність коду, доступна особа, яка найвідоміша з кодом (людина, відповідальна за 20-річну процедуру Крейга COBOL, може піти з компанії років тому ) та часові шкали.

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

Бувають випадки, коли подібне виправлення дійсно добре і, ймовірно, ідеальне (що стосується часу, необхідного для налагодження).

Уявіть собі сценарій, коли у вас є 20 DLL-файлів, які повинні діяти як певні модулі для вашого основного виконуваного файлу, але також вимагають деякої інформації від головного виконуваного файлу для запуску.

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

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

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