Користувач:And800/пісочниця

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

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

/////////////////////////////////////////

Для чого вони

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

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

Історія

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

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

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

/////////////////////////////////////////

Приклади

Антипаттерни проектування програмного забезпечення

• Інверсія абстракції (Abstraction inversion) – приховування частини функціональності від зовнішнього використання, в надії на те, що ніхто не буде її використовувати
• Неоднозначна точка зору (Ambiguous viewpoint) – представлення моделі без специфікації її точки розгляду
• Великий кусок багна (Big ball of mud) – система з нерозпізнаною структурою
• Database-as-IPC: Використання бази даних, як черги повідомлень для рутинних внутрішніх комунікацій, коли можна застосувати більш простіший механізм, наприклад сокети
• Золоте покриття (Gold plating): Продовження роботи над завданням чи проектом, коли вартість роботи перевищує вигоду від їх ефективності
• Внутрішньоплатформний ефект (Inner-platform effect): Система може так налаштовуватися, що стає бідною копією середовища розробки
• Ляп на вході: Неможливість визначити і реалізувати обробку помилки через неправильні вхідні дані
• Наворочений інтерфейс: Проектування наскільки потужного інтерфейсу, що його вкрай важко реалізовувати
• Магічна кнопка (Magic pushbutton): Кодування логіки реалізації класу безпосередньо в коді елементів інтерфейсу, без використання абстракції
• Гонка небезпеки (Race hazard): Результат програми залежить від послідовності неконтрольованих подій
• Димохід (Stovepipe system): Легкий супровід збірки погано зв'язаних елементів

Антипаттерни програмування

• Випадкова складність (Accidental complexity): Представлення необов’язкової складності в програмі
• Дії на відстані (Action at a distance): Неочікувана взаємодія між ізольованими частинами програми
• Сліпа віра (Blind faith): Не перевірка (a) виправлення помилки (b) чи результату підпрограми
• П’яте колесо (Boat anchor): Зберігання частин коду, що не використовуються
• Зайнятий очікуванням (Busy waiting): Використання CPU під час очкування якоїсь дії, зазвичай для тривалих циклів перевірки, замість використання повідомлень подій
• Кеш відмов (Caching failure): Забування скинути прапорець помилки, після її виправлення
• Культ вантажного програмування (Cargo cult programming): Використання паттернів та методів без розуміння для чого
• Кодування виключень (Coding by exception): Додавання нового коду для обробки кожної виняткової ситуації
• Паттерн проектування: Використання антипаттернів говорить про те, що система немає достатнього рівня абстракції
• Приховування помилок (Error hiding): Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
• Жорсткий код (Hard code): Вкладення припущень про середовище системи у її реалізації
• Послідовність циклів-розгалужень (Loop-switch sequence): Кодування послідовності кроків використовуючи розгалуження всередині циклів
• Магічні числа (Magic numbers): Включення непрокоментованих та незадокументованих даних в алгоритм
• Магічні рядки (Magic strings): Включення текстових рядків у код для порівняння, як от наприклад категорії.
• Повторення коду (Repeating yourself): Написання коду, який повторюється знову і знову, замість того щоб бути унікальним
• М'який код (Soft code): Зберігання бізнес логіки у конфігураційних файлах, а не у коді
• Код Спагеті (Spaghetti code): Програми, структури яких ледь зрозумілі через неправильне застосування структур коду
• Код Лазаньї (Lasagna code): Програма, структура якої містить забагато рівнів

Антипаттерни об'єктно-орієнтованого програмування

• BaseBean: Спадкування функціональності із службового класу, а не делегування йому вирішення проблем
• Супер виклик (Call super): Обов’язкові підкласи для виклику перевизначеного метода суперкласу
• Проблема коло-еліпс (Circle-ellipse problem): Використання підтипу змінної-типу чи базового підтипу-значення
• Кільцеві залежності (Circular dependency): Представлення не необхідних прямих чи непрямих взаємних залежностей між об’єктами та модулями програми
• Інтерфейс констант (Constant interface): Використання інтерфейсів для визначення констант
• Об’єкти Бога (God object): Концентрування функціоналу в одній частині проекту (класу, методі)
• Об’єкт вигрібної ями (Object cesspool): Повторне використання об’єкту, стан якого не допускає повторне використання
• Об’єкт оргії (Object orgy): Незмога належним чином інкапсулювати об’єкти даєнеобмежений доступ до його внутрішніх функцій
• Полтергейсти (Poltergeists): Об’єкти, єдиною метою яких є передача інформації на інші об’єкти
• Послідовне з’єднання (Sequential coupling): Клас вимагає, щоб його методи викликалися у певному порядку
• Проблема Йо-йо (Yo-yo problem): Структуру (наприклад, наслідування), важко зрозуміти,через надмірну фрагментацію

Антипаттерни методологій програмування

• Програмування копіпастом (Copy and paste programming): Копіювання (і зміна) існуючого коду, замість того, щоб створювати нове рішення
• Золотий молоток (Golden hammer): Припущення, що улюблене рішення є універсальним
• Коефіцієнт неймовірності (Improbability factor): Припущення, що малоймовірно, що виникне відома помилка
• Це придумав не я (Not Invented Here (NIH) syndrome): Тенденція винаходити колесо (Несприйняття існуючого, адекватного рішення)
• Придумано мною (Invented Here): Тенденція до несприйняття нових чи менш тривіальних рішень всередині організації, найчастіше через недовіру до персоналу
• Передчасна оптимізація (Premature optimization): Завчасне програмування для підвищення ефективності, жертвуючи хорошим дизайном, гнучкістю, а інколи навіть реальною ефективністю
• Програмування перестановкою (або “випадкове програмування), або “програмування за збігом обставин”)(Programming by permutation (or “programming by accident”, or “programming by coincidence”)): Спроба знайти рішення шляхом послідовної зміни коду і перевіряючи “чи воно працює”
• Винаходження велосипеду (Reinventing the square Wheel): При не змозі прийняти існуюче рішення, намагаєшся оптимізувати своє, яке працює набагато гірше
• Срібна куля (Silver bullet): Припущення, що улюбленим технічним рішенням можна вирішити більшу проблему
• Tester Driven Development: програмні проекти, в яких нові вимоги, зазначені в повідомленнях про помилки

Антипаттерни системного адміністрування

• Пекельна залежність (Dependency hell): Залежність від версій необхідних бібліотек і програм. Поширений в Unix-середовищах
• DLL пекло (DLL hell): Неадекватне управління динамічними бібліотеками (DLLs). Поширений в Microsoft Windows

Див. також

• Шаблони проектування програмного забезпечення
• Ефект другої системи

Література

Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, ltd. ISBN 978-0-471-19713-3.

Посилання

• Антипаттерни: як не треба робити
• Anti-patterns catalog
• Проломы проектно-дизориентированного проектирования