Ілюстрація до статті
Андрій Губін
Журналіст
Я роздумував над тим, що може викликати занепокоєння у досвідченого розробника. І це антипатерни в програмному коді. Розповім про найпоширеніші з них та поясню, як їх уникати.
Код-спагеті
Код-спагеті — це програмний код, позбавлений чіткої структури. У ньому панує повний безлад: функції, цикли та інші елементи переплітаються без будь-якої логічної послідовності. Уявіть собі миску спагеті: всі макаронини настільки збиті докупи, що знайти початок чи кінець практично неможливо. На відміну від структурованого коду, де потік плавно переходить від однієї частини до іншої, код-спагеті хаотично стрибає між різними блоками через надмірну кількість умов.
Зазвичай такий “спагеті-монстр” виникає через непродуману архітектуру. Розробник поспішає написати код, швидко його протестувати, не надто дотримуючись правил написання. Програма розростається, і ви спостерігаєте неохайну структуру: розкидані глобальні змінні, перевантажені методи, хаотичні послідовності. Це схоже на читання роману, де розділи розташовані в неправильному порядку.
Підтримувати програму зі спагеті-кодом майже нереально, а спроба додати нові можливості до заплутаної бази даних є справжнім кошмаром. Зміна одного елемента може випадково призвести до збою іншого. Крім того, чим складнішим є код, тим важче виявити помилки.
Шляхи уникнення:
Пишіть код лише після ретельного обдумування дизайну та архітектури програмного забезпечення. Це допоможе уникнути плутанини та накопичення технічного боргу — дрібних недоліків та “сміття”, які зрештою доведеться виправляти або видаляти.
Регулярно проводьте рев’ю коду. Це дозволить виявити проблеми до того, як код перетвориться на спагеті.
Спробуйте парне програмування — метод, за якого один розробник пише код, коментуючи свої дії вголос, а його колега одразу ж проводить рев’ю.
Об’єкт-бог
Якщо значна частина коду залежить від одного об’єкта, ви маєте справу з “об’єктом-богом”. Це явище виникає, коли один клас “відповідає за все одразу”, наприклад, за ім’я, прізвище, ідентифікатор користувача, суму переказу та список покупок. В результаті в системі починає діяти сутність, яка контролює все і всіх.
Теоретично це може здаватися зручним: ви призначаєте нові функції одному об’єкту, замість створення нового. Однак на практиці, з “об’єктом-богом”, система стає повністю залежною від громіздкого коду, де всі частини тісно пов’язані.
Через це стає важко виділити та протестувати конкретну функцію. Без цього архітектура додатку стає тендітною та вразливою до помилок. Ще один недолік полягає в тому, що окремі компоненти коду “об’єкта-бога” практично неможливо використовувати повторно, їх занадто складно витягти.
Шляхи уникнення:
- Дотримуйтесь принципу єдиної відповідальності (Single Responsibility Principle, SRP), згідно з яким кожен клас повинен вирішувати лише одне завдання.
- Розбивайте ваш код на окремі компоненти, де різними людьми можуть працювати над підзадачами. Це зменшить ймовірність того, що на один об’єкт буде покладено надмірну кількість обов’язків.
- Підтримуйте документацію в актуальному стані. Пишіть коментарі у своєму коді. Таким чином, інші розробники розумітимуть, що об’єкти повинні, а що не повинні робити.
- Проводьте рев’ю коду. Це допоможе швидко помітити, якщо один об’єкт відповідає за занадто багато завдань.
- Якщо “об’єкт-бог” вже існує, проведіть рефакторинг. Це дозволить визначити конкретні обов’язки об’єкта та розподілити їх між різними методами.
Корабельний якір
Корабельний якір утворюється, коли програмісти залишають непотрібний код у базі даних. Логіка така: “А раптом колись знадобиться?”. Спочатку ідея може здаватися слушною, але час минає, а бажаний момент для цього рішення так і не настає. В результаті розробники тягнуть цей “іржавий спадок” з нульовою користю для продукту.
Такий підхід завдає більше шкоди, ніж користі: корабельний якір сповільнює роботу та заплутує інших розробників. Незрозуміло, який код слід використовувати, а який не варто чіпати. Можна годинами читати та налагоджувати непотрібні рядки.
Як наслідок, збільшується час компіляції. А найгірший сценарій — якщо код, написаний “про всяк випадок”, помилково потрапить у продакшн. Це підвищить технічні ризики в додатку.
Шляхи уникнення:
- Рефакторинг. Найкращий спосіб боротьби з якорем — це просто видалити нерелевантні фрагменти.
- Виділіть час на усунення таких “хвостів”. Враховуйте це при плануванні розробки.
Золотий молоток
Золотий молоток виникає, коли програмісти застосовують одне й те саме “ідеальне” рішення до різноманітних проблем. Все починається з того, що розробник знаходить вдале рішення для однієї задачі, наприклад, універсальний шаблон для створення додатків, і використовує його ще кілька разів. Все виходить чудово, і тепер розробник намагається вирішувати всі подібні проблеми цим же способом.
Проблема полягає в тому, що один і той самий інструмент може дати абсолютно різні результати. Обране рішення може не відповідати логіці, ускладнювати код, призводити до помилок та невідповідностей, які потребують виправлення. Розробник буде обмежений своїми інструментами, які можуть не відповідати потребам проекту. Як наслідок, багато вимог не будуть виконані.
І остання пастка “золотого молотка”: якщо ви багаторазово використовуєте одне й те саме рішення, ви можете припинити досліджувати нові методи та технології. В результаті “золотий молоток” не спрощує роботу, а лише додає нових труднощів.
Шляхи уникнення:
- Вивчіть декілька варіантів рішень. Порівняйте їх і оберіть найбільш ефективний варіант.
- Проводьте рев’ю коду. Так ви зможете помітити, що застосовуєте метод надмірно часто.
Копіпаст
Виникає, коли програміст копіює раніше написаний код — власний чи чужий — і бездумно вставляє його у файл. Зазвичай таким методом користуються початківці або стажери, яким складно писати код з нуля або створювати певні функції.
Тому вони “позичають” потрібні фрагменти у колег або шукають приклади в інтернеті. Іноді до копіпасту вдаються й більш досвідчені розробники, яким потрібно швидше завершити проект.
Проблема полягає в тому, що оригінальний код може містити помилку, яка потім дублюється у всій програмі. Її доводиться виправляти у всіх частинах, де з’являються “клони”. Крім того, якщо над проектом працює ціла команда, дефекти часто виявляються лише в одному місці, і тільки його “виправляють”.
Ще один наслідок копіпасту — поява надлишкових гілок коду, які збільшують його обсяг без жодної користі. Читати та підтримувати такий “колос” буде вкрай незручно.
Шляхи уникнення:
- Проводьте рев’ю коду. Чим раніше ви зможете виявити копії фрагментів коду, тим менше шансів, що вони поширяться по всій системі.
- Дотримуйтесь принципу Don’t Repeat Yourself (DRY). Іншими словами, уникайте повторення одного й того ж коду. Натомість використовуйте універсальні властивості та функції.
- Рефакторинг. Якщо ви бачите дубльований код, винесіть його в окрему функцію. Таким чином, будь-які зміни або виправлення помилок можна буде вносити лише в одному місці.
Загальні рекомендації проти антипатернів
Антипатерн у програмі — це не вирок. Якщо ви помітили проблеми на ранніх етапах, то, як правило, код можна виправити. Існує багато способів та інструментів, щоб захистити свою роботу та уникнути помилок. Ось декілька прикладів:
Використовуйте послідовний формат та синтаксис у всьому коді. Це зробить його більш читабельним для вас та всіх, хто працює над проектом.
Використовуйте лише необхідні дані. Це допоможе уникнути помилок, які можуть виникнути через зайву інформацію в коді.
Використовуйте зрозумілі назви для методів та змінних. І краще не скорочуйте їх, інакше ваші колеги можуть не зрозуміти і написати той самий код, але з іншими назвами.
Головна > Добірки > Головні лиходії в програмуванні