Антипатерни

1. Знайомство з антипатернами

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

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

Розглянемо кілька антипатернів, що поширені серед новачків:

• Магічні числа та рядки
• Клас бога
• Передчасна оптимізація
• Винахід велосипеда
• Винахід велосипеда з квадратними колесами

2. Магічні числа та рядки

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

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

Числа ускладнюють розуміння коду та його рефакторинг. Головні причини цієї помилки – поспіх під час розробки та відсутність практики програмування. Цей антипатерн треба зупиняти одразу: обумовлювати використання числових констант ще перед початком розробки.

Для вирішення такої проблеми потрібно створити змінну, ім'я якої пояснює призначення числової константи, і надати їй необхідне значення.

Клас бога

Божественний об'єкт — антипаттерн, який досить часто зустрічається у розробників ОВП. Такий об'єкт перебирає на себе занадто багато функцій та/або зберігає практично всі дані. У результаті ми маємо нестерпний код, в якому, до того ж, важко розібратися.

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

Боротися з таким підходом треба: розбивати завдання на підзавдання, якими зможуть займатися різні розробники.

3. Передчасна оптимізація

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

Насправді складно передбачити, де буде вузьке місце. Спроби налаштувати оптимізацію до отримання емпіричних результатів призведуть до ускладнення коду та появи помилок, а користі не принесуть.

Як уникнути? Спочатку пиши чистий, робочий код, який легко читати, за допомогою відомих та перевірених алгоритмів та інструментів. За потреби використовуй інструменти для профілювання для пошуку вузьких місць. Покладайся на вимірювання, а не на припущення.

Приклади та ознаки

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

У чому складність

Непросто визначити, коли оптимізація буде передчасною. Важливо заздалегідь залишати місце для зростання. Потрібно обирати рішення та платформи, які дозволять легко оптимізувати та зростати. Також іноді передчасну оптимізацію використовують як виправдання за поганий код. Наприклад, беруть алгоритм O(n2) лише через те, що алгоритм був би O(n) складнішим.

4. Винахід велосипеда

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

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

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

Найчастіше причиною цього антипатерну є банальна нестача часу. А час – це гроші.

5. Винахід велосипеда з квадратними колесами

Цей антипатерн дуже тісно пов'язаний із простим винаходом велосипеда — це створення власного поганого рішення, коли існує вдале рішення.

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

Програміст повинен знати про існування різних рішень для певних кіл завдань, орієнтуватися у їхніх перевагах та недоліках.

Усі проблеми, з якими ти стикнешся як програміст, можна поділити на дві частини:

• цю проблему розумні люди вирішили 30 років тому;
• цю проблему розумні люди вирішили 50 років тому.

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

У 2023 році ми святкуємо такі дні народження:

• Мови програмування
  • Мові С виповнився 51 рік (1972)
  • Мові Java виповнилося 28 років (1995)
  • Мові Python виповнилося 32 роки (1991)
• Зв'язок
  • Інтернету виповнилося 40 років (1983)
  • Мобільному телефону виповнилося 50 років (1973)
  • Першу СМС надіслали 31 рік тому (1992)
• Патерни
  • Патерну MVC виповнилося 45 років (1978)
  • SQL придумали 49 років тому (1974)
  • Java Beans придумали 27 років тому (1996)
• Бібліотеки
  • Hibernate придумали 22 роки тому (2001)
  • Spring придумали 21 рік тому (2002)
  • Tomcat випустили 24 роки тому (1999)
• Операційні системи
  • Unix випустили 52 роки тому (1971)
  • Windows побачила світ 38 років тому (1985)
  • Mac OS випустили 22 роки тому (2001)

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