Антипатерн

Антипа́терн, або антишабло́н — загальний спосіб розв'язання проблеми, що часто виникає під час проєктування програмного забезпечення, який, як правило, неефективний та зменшує продуктивність комп'ютерної програми. Інакше кажучи, антипатерн — шкідливий і неефективний патерн.

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

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

Найважливіша мета документування антипатернів — полегшити можливість розпізнавання шкідливого рішення і успішного виправлення помилок ще на ранніх етапах роботи^[1]. Антипатерн не просто застерігає «Не роби цього!», а вказує інженеру на те, що він, можливо, не усвідомлює, що рішення такого типу принесе набагато більше шкоди, ніж користі.

Існує 3 ключових правила, коли рішення вважають антипатерном:

Загальноприйнятий процес, структура чи план дій, який на перший погляд дає ефективне рішення, найчастіше дає більше негативних наслідків, ніж позитивних.
Цей процес (структура, план), попри шкідливість, достатньо поширений на практиці.
Правильне рішення вже існує, його задокументовано та перевірено на ефективність.

Історія

З розвитком ІТ-індустрії масштаби програмних проєктів та витрати ресурсів на них нестримно росли, що породжувало багато проблем, які поставали перед програмістами. Більшість цих проблем були типовими і зустрічались практично в кожному великому проєкті. На початку 1990-х років набули значної популярності каталоги шаблонів проєктування (англ. design patterns) — елегантних і перевірених на практиці способів розв'язання типових проблем. Патерни і нині є потужними і надзвичайно популярними, проте багато розробників, використовуючи популярні патерни в ситуаціях, до яких вони не пристосовані, робили програми вкрай неефективними, чи породжували набагато більше проблем, ніж було в проєкті до використання патерну. Крім того, в ІТ-інженерів, як і у працівників будь-якої сфери діяльності, можна виокремити типові помилки, зумовлені недостатньою базою знань чи відсутністю досвіду, стислими термінами здачі проєкту, фінансовими обмеженнями та іншим.

Вперше термін «антипатерн» у розумінні формальної моделі типового невдалого рішення використав 1996 року Майкл Ейкройд (англ. Michael Akroyd) на конференції «Object World West Conference», посвяченій аспектам об'єктно-орієнтованого програмування^[1]. У своїй презентації «Антипатерни: запобігання неправильному використанню об'єктів», Ейкройд звернув увагу на шкідливі, але часті програмні конструкції, зокрема, ті, що суперечать принципам ООП. До того ж, для кожної такої конструкції він пропонував ефективну заміну.

Термін (у розумінні: «погана ідея») зустрічався і до Ейкройда, але не публікувався і особливої популярності не мав. На думку Вільяма Брауна, автора книги «Антипатерни: рефакторинг програм, архітектур та проєктів», антипатерн — це етап еволюції поняття патерну проєктування, розширення їх моделі.

Приклади

Комерційні та соціальні

Організаційні

Паралізоване мислення (Analysis paralysis): Проєкт зупиняється на стадії аналізу та специфікацій, які менеджмент хоче виконати якнайкраще.
Велосипедний навіс (Bicycle shed): Надання великого значення неважливим питанням. Походить від історії обговорень будівництва атомної електростанції, коли більше уваги приділялося деталям навісу для велосипедів, а не самій станції.
Вбивча технологія (Bleeding edge): Ризик застосування технології, яка ще не пройшла належного випробування. В результаті така технологія може призвести до надвитрат, низьких результатів, відкладення термінів завершення проєкту. Походить від алюзії подібних термінів leading edge / cutting edge.
Ефект свідка (Bystander apathy): Феномен, коли ймовірність допомоги людині в біді від свідків знижується пропорційно кількості свідків. Всі вважають, що допомогти має хтось інший.
Дійна корова (Cash cow): Негативний вплив історії успішного продукту на незадоволеність новими продуктами, які ще розвиваються.
Дизайн від комітету (Design by committee): Участь багатьох в обговоренні та прийнятті рішень щодо дизайну, що призводить до розмитого бачення продукту / дизайну.
Ескалація прив'язаності (Escalation of commitment): Відмова й неможливість скасувати попереднє неправильне рішення. Походить від феномену названого оманою неповоротних витрат.
Групове/стадне мислення (Groupthink): Прийняття думки одного учасника групи як основної та небажання брати до уваги думки інших учасників.
Управління за цілями (Management by objectives): Надмірне значення надається цифрам, які не мають значення для проєкту або отримання цих даних дорого коштує.
Мікроменеджмент (Micromanagement): Зловживання контролем в управлінні підлеглими.
Моральний ризик (Moral hazard): Ізоляція людини, що приймає рішення, від наслідків її / його рішення.
Грибне управління (Mushroom management): Викривлені комунікації між управлінцем і працівниками, коли працівникам надається тільки обмежена інформація («ростуть у темряві, харчуються гноєм»).
Принцип Пітера (Peter principle): Просування працівників вгору кар'єрною драбиною, засноване на поточних показниках, а не їх здатності розвиватися на новій посаді. Внаслідок цього успішний працівник не справляється із новим завданням / посадою.
Чайка-менеджмент (Seagull management): Керівник звертається до працівників лише, коли виникає проблема, перед здачею роботи, або просто «прибігає, багато галасує, не вирішує проблему й зникає».
Силос (Stovepipe або Silos): Створення структури із малих розрізнених команд, які працюють кожна над своїм завданням і їх результати роботи неможливо поєднати.
Рольове кліше (Typecasting): Доручення одноманітних завдань спеціалісту, який успішний у певному питанні, що обмежує його/її розвиток.
Залежність від постачальника (Vendor lock-in): Створення системи надмірно залежної від одного постачальника, якого неможливо або важко замінити.