Боклук код и развалина в мобилни проекти — признаци и рефакториране

Какво е боклук код в разработката

Боклук код (също 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 се счита за проблематична.

Методи с complexity над 30 — „зона на бедствие". Те съдържат твърде много разклонения, не могат да бъдат тествани или разбрани без задълбочен анализ.

Причини за поява на боклук код

Боклук код не се появява „от само себе си" — винаги е резултат от определени процеси и решения в екипа. Разбирането на причините позволява предотвратяване на появата му в бъдеще.

Според данни на JetBrains Developer Ecosystem 2024, 67% от разработчиците признават, че пишат по-лош код, отколкото биха могли, поради липса на време. Това е основната причина за натрупване на технически дълг.

Бързане и крайни срокове

Най-честата причина — кратки срокове. Екипът пише код „както се получи", само за да спази крайния срок. Рефакторирането, тестовете и код-ревюто се отлагат „за по-късно".

Проблемът е, че „по-късно" никога не идва — в следващия спринт се появяват нови крайни срокове и техническият дълг се трупа като снежна топка.

Липса на код-ревю

Без код-ревю всеки разработчик пише в свой стил, използва свои модели и оставя свои „капани". С времето кодовата база губи еднородност.

Екипите, които практикуват задължително код-ревю за всяка pull заявка, имат 60% по-малко дефекти в продукцията според изследване на SmartBear 2024.

Слаба архитектура от самото начало

Ако проектът започва без ясна архитектура, боклук кодът е неизбежен. Първите „бързи решения" поставят основа, върху която по-късно е трудно да се изгради нещо качествено.

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

Методи за борба с боклук код

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

Основният принцип — да не се допуска боклук код на етапа на писане, вместо да се поправя по-късно. Профилактиката винаги е по-евтина от рефакторирането на съществуваща „развалина".

Стандарти за кодиране

Единен стил на код — основа за предотвратяване на боклук код. Стандартите за кодиране (Code Style) трябва да бъдат документирани и автоматично проверявани от линтери.

За iOS се използва SwiftLint, за Android — Ktlint и Detekt. Настройването на правила в конфигурационен файл позволява автоматично отхвърляне на pull заявки, нарушаващи стандартите.

Редовно рефакториране

Рефакторирането — не е поправяне на грешки, а подобряване на структурата на код без промяна на поведението му. Трябва да бъде редовна част от процеса на разработка, а не отделен проект.

Препоръчва се отделяне на 20% от времето на всеки спринт за рефакториране и погасяване на технически дълг. Това предотвратява натрупването на „развалина" и поддържа скоростта на екипа в дългосрочен план.

Задължително код-ревю

Всяка pull заявка трябва да премине ревю от поне един разработчик. Код-ревюто открива не само грешки, но и нарушения на архитектурата, стила и потенциални източници на боклук код.

Добра практика — контролен списък за код-ревю, включващ проверка за копи-пейст, дължина на методи, цикломатична сложност и покритие с тестове. Без контролен списък рецензентите пропускат до 50% от проблемите.

Инструменти за почистване на кодова база

Съвременните инструменти за анализ на код позволяват автоматично откриване на боклук код, измерване на технически дълг и контрол на качеството. Интегрирането на тези инструменти в CI/CD тръбопровод осигурява непрекъснат мониторинг.

Препоръчва се използване на поне един статичен анализатор и един инструмент за измерване на показатели. Допълнително може да се свърже платформа за агрегиране на данни за качеството на код.

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

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

Според данни на SonarSource, екипите, използващи статичен анализ, намаляват броя на грешките в продукция с 30% още в първото тримесечие след внедряване.

Инструменти за измерване на показатели

CodeClimate и Codacy — платформи, които агрегират показатели за качество на код, следят динамиката и показват „горещи точки" — файлове с най-голям технически дълг.

За Android проекти Detekt предоставя над 100 вградени правила за анализ, включително проверки за цикломатична сложност, дължина на методи и дублиране на код.