Сміттєвий код і безлад у мобільних проектах — ознаки та рефакторинг

Що таке сміттєвий код у розробці

Сміттєвий код (також spaghetti code, безлад, big ball of mud) — це метафора для кодової бази, яка втратила структуру та перетворилася на заплутаний клубок залежностей. У такому коді будь-яка зміна в одному місці ламає інше, а додавання нової функціональності перетворюється на ризикований квест.

У мобільній розробці сміттєвий код особливо критичний: додаток, зібраний на «безладі», починає гальмувати, крашитися на старих пристроях і важко проходить код-рев’ю. iOS-проект без архітектури може не пройти App Review через нестабільність.

За даними Stripe, розробники витрачають до 42% робочого часу на читання та розуміння існуючого коду. У проектах зі сміттєвим кодом цей показник перевищує 60%, що робить розробку вкрай неефективною.

Походження термінів

Spaghetti code (спагеті-код) — найстаріший термін, що з’явився у 1970-х роках. Він описує код із хаотичними переходами управління, що нагадує переплетені макаронини.

Big ball of mud (великий брудний ком) — термін, введений Брайаном Футом і Джозефом Йодером у 1997 році для опису систем без чіткої архітектури, які «ростуть» хаотично.

Чому сміттєвий код небезпечний для бізнесу

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

За даними McKinsey, компанії з низькою якістю коду витрачають на 20-40% більше на підтримку продукту, а швидкість виведення нових функцій у 2-3 рази нижча порівняно з компаніями з високою якістю коду.

Ознаки сміттєвого коду та як його розпізнати

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

В індустрії використовуються метрики якості коду, такі як Halstead Complexity, Maintainability Index і Technical Debt Ratio. Знання цих метрик допомагає об’єктивно оцінювати стан кодової бази.

Копіпаста (дублювання коду)

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

Нормальним вважається рівень дублювання до 5%. Якщо дублювання перевищує 15% — це серйозний сигнал. Інструменти на кшталт Simian і PMD Copy Paste Detector допомагають виявляти копіпасту автоматично.

Довгі методи та класи

Метод довжиною понад 100 рядків — явна ознака сміттєвого коду. Такий метод зазвичай робить занадто багато та порушує принцип єдиної відповідальності (Single Responsibility).

Класи з більш ніж 1000 рядків коду також проблемні. Вони містять непов’язану функціональність, що ускладнює тестування, розуміння та модифікацію коду.

Висока циклічна складність

Циклічна складність за Маккейбом (Cyclomatic Complexity) — метрика, що показує кількість незалежних шляхів у коді. Значення вище 15 вважається проблемним.

Методи зі складністю вище 30 — «зона лиха». Вони містять занадто багато розгалужень, їх неможливо протестувати та зрозуміти без глибокого аналізу.

Причини появи сміттєвого коду

Сміттєвий код не з’являється «сам по собі» — він завжди результат певних процесів і рішень у команді. Розуміння причин дозволяє запобігти його появі в майбутньому.

За даними JetBrains Developer Ecosystem 2024, 67% розробників визнають, що пишуть код гірше, ніж могли б, через брак часу. Це головна причина накопичення технічного боргу.

Поспіх і дедлайни

Найчастіша причина — стислі терміни. Команда пише код «як вийде», аби встигнути до дедлайну. Рефакторинг, тести та код-рев’ю відкладаються «на потім».

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

Відсутність код-рев’ю

Без код-рев’ю кожен розробник пише у своєму стилі, використовує свої патерни та залишає свої «закладки». З часом кодова база втрачає єдність.

Команди, що практикують обов’язкове код-рев’ю для кожного пул-реквесту, мають на 60% менше дефектів у продакшені, за даними дослідження SmartBear 2024.

Слабка архітектура з самого початку

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

У мобільній розробці вибір архітектури (MVC, MVP, MVVM, Clean Architecture) має бути усвідомленим рішенням, прийнятим до початку написання коду, а не результатом еволюції.

Методи боротьби зі сміттєвим кодом

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

Головний принцип — не допускати сміттєвий код на етапі написання, а не виправляти його потім. Профілактика завжди дешевша, ніж рефакторинг уже існуючого «безладу».

Стандарти кодування

Єдиний стиль коду — база для запобігання сміттєвому коду. Стандарти кодування (Code Style) мають бути задокументовані та автоматично перевірятися лінтерами.

Для iOS використовується SwiftLint, для Android — Ktlint і Detekt. Налаштування правил у конфігураційному файлі дозволяє автоматично відхиляти пул-реквести, що порушують стандарти.

Регулярний рефакторинг

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

Рекомендується виділяти 20% часу кожного спринту на рефакторинг і погашення технічного боргу. Це запобігає накопиченню «безладу» і зберігає швидкість команди в довгостроковій перспективі.

Обов’язкове код-рев’ю

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

Хороша практика — чек-лист для код-рев’ю, що включає перевірку на копіпасту, довжину методів, циклічну складність і покриття тестами. Без чек-листа рев’юери пропускають до 50% проблем.

Інструменти для чищення кодової бази

Сучасні інструменти аналізу коду дозволяють автоматично виявляти сміттєвий код, вимірювати технічний борг і контролювати якість. Інтеграція цих інструментів у CI/CD пайплайн дає постійний моніторинг.

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

Статичні аналізатори

• SonarQube — провідна платформа аналізу якості коду, підтримує 30+ мов і дає метрики Technical Debt Ratio
• ESLint — стандарт для JavaScript і TypeScript, налаштовується через конфігураційні файли та інтегрується в IDE
• SwiftLint — обов’язковий інструмент для iOS-проектів, перевіряє відповідність Swift Style Guide

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

Інструменти вимірювання метрик

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

Для Android-проектів Detekt надає понад 100 вбудованих правил аналізу, включаючи перевірки на циклічну складність, довжину методів і дублювання коду.