Головні лиходії в програмуванні

Блогер та розробник Джозеф Круз продовжує вивчати темні сторони програмування. Цього разу він задумався про те, які лиходії існують у мультивсесвіті програмування.

Пропонуємо вам переклад його його авторського блогу від нашої редакції. Далі — слово автору.

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

Спагеті-код

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

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

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

Як уникнути:

Пишіть код тільки після того, як дизайн та архітектура програмного забезпечення повністю продумані. Так ви уникнете плутанини і не накопичите технічний борг — це дрібні недоліки і сміття, які рано чи пізно доведеться виправляти або видаляти.

Проводьте огляди коду. Це допоможе вам виявити проблему до того, як код розростеться в спагеті.

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

Об’єкт-бог

Якщо значна частина коду залежить від одного об’єкта, ви маєте справу з об’єктом-богом. Він з’являється, коли один клас «відповідає за все і одразу»,  наприклад, за ім’я, прізвище, ідентифікатор користувача, суму переказу та список покупок. В результаті в системі починає діяти сутність, яка відповідає за все і всіх.

В теорії все виглядає зручно: ви призначаєте нові функції одному об’єкту і не створюєте новий. Але на практиці, з Об’єктом-богом, система повністю залежить від громіздкого коду, де всі частини тісно пов’язані між собою.

Тому важко виокремити і протестувати конкретну функцію. А без цього архітектура додатку стане крихкою і вразливою до помилок. Ще один недолік полягає в тому, що окремі компоненти коду Об’єкту-богу практично неможливо використовувати повторно, їх занадто складно витягти.

Як уникнути:

• Дотримуйтесь принципу єдиної відповідальності (Single Responsibility Principle, SRP), коли кожен клас вирішує лише одну задачу.
• Розбивайте свій код на частини, де з підзадачами можуть працювати різні люди. Це зменшить ризик того, що на один об’єкт буде покладено занадто багато обов’язків.
• Підтримуйте свою документацію в актуальному стані. Пишіть коментарі у своєму коді. Таким чином, інші розробники будуть розуміти, що об’єкти повинні, а що не повинні робити.
• Проводьте огляди коду. Це допоможе вам швидко помітити, якщо один об’єкт відповідає за занадто багато.
• Якщо Об’єкт-бог вже існує, проведіть рефакторинг. Це дозволить визначити конкретні обов’язки об’єкта і розділити їх на різні методи.

Корабельний якір

Корабельний якір створюється, коли програмісти залишають непотрібний код у базі даних. Логіка така: «А раптом колись стане в нагоді?». Спочатку ідея може здатися гарною, але час іде, а зоряний час для цього рішення так і не настає. В результаті розробники тягнуть цей «іржавий спадок» з нульовою цінністю в продукт.

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

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

Як цього уникнути:

• Рефакторинг. Найкращий спосіб боротьби з якорем — це просто видалити нерелевантні фрагменти.
• Дайте час на підчищення таких хвостів. Враховуйте це при плануванні розробки.

Золотий молоток

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

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

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

Як уникнути:

• Вивчіть кілька рішень. Порівняйте їх і виберіть найбільш «робочий» варіант.
• Проводьте огляди коду. Так ви помітите, що використовуєте метод занадто часто.

Копіпаст

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

Тому вони «позичають» потрібні фрагменти у своїх колег або шукають приклади в інтернеті. Іноді до копіпасту вдаються і більш досвідчені розробники, яким потрібно швидше закінчити проект.

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

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

Як уникнути:

• Проводьте коду-рев’ю. Чим раніше ви зможете відловити копії фрагментів коду, тим менше шансів, що вони поширяться по всій системі.
• Дотримуйтесь принципу Don’t Repeat Yourself (DRY). Іншими словами, уникайте повторення одного і того ж коду. Натомість використовуйте універсальні властивості та функції.
• Рефакторинг. Якщо ви бачите дубльований код, винесіть його в окрему функцію. Таким чином, будь-які зміни або виправлення помилок можна буде вносити лише в одному місці.

Універсальні поради проти антипаттернів

Антипатерн у програмі — це не смертний вирок. Якщо ви помітили проблеми на самому початку, то, як правило, код можна виправити. Існує багато способів та інструментів, щоб захистити свою роботу та уникнути помилок. Ось кілька прикладів:

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

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

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

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