Треш-код и прљавштина у мобилним пројектима — знаци и рефакторисање

Шта је треш-код у развоју

Треш-код (такође 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 уграђених правила анализе, укључујући проверу цикломатске сложености, дужине метода и дуплирања кода.