АнтипаттерниАнтипаттерни – загальне рішення проблеми, що часто виникає, яке, як правило, неефективне та зменшує продуктивність програми. Термін був придуманий у 1995 році Андрієм Кенігом та вжитий у книзі “Паттерни проектування” (Design Patterns),  у якій автор підкреслює низку шаблонів проектування, що роблять розробку програм більш продуктивною та надійною.

Термін набув популярності через 3 роки в книзі Антипаттерни, яка розширила його використання за межами лише розробки програм. Так стали називати будь-яке загальне заново винайдене рішення, яке є поганою розв’язкою проблеми.

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

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

Приклади Антипаттернів в розробці програм

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

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

Об’єктно-орієнтоване програмування

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

Прогрумування

  • Випадкова складність (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): Програма, структура якої містить забагато рівнів

Методології

  • Програмування копіпастом (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): Залежність від версій необхідних бібліотек і програм
  • DLL пекло (DLL hell): Неадекватне управління динамічними бібліотеками (DLLs), особливо на Microsoft Windows

 

 

Напишіть відгук

Ваша пошт@ не публікуватиметься. Обов’язкові поля позначені *