Szemétkód és rendetlenség mobil projektekben — jelek és refaktorálás

Mi a szemétkód a fejlesztésben

Szemétkód (továbbá spaghetti code, rendetlenség, big ball of mud) — metafora egy olyan kódbázisra, amely elvesztette struktúráját és összegubancolódott függőségek halmazává vált. Egy ilyen kódban minden változtatás az egyik helyen elront valami mást, és az új funkcionalitás hozzáadása kockázatos feladattá válik.

Mobilfejlesztésben a szemétkód különösen kritikus: a "rendetlenségre" épített alkalmazás lassulni kezd, összeomlik régebbi eszközökön és nehezen megy át a code review-n. Egy architektúra nélküli iOS projekt instabilitás miatt nem biztos, hogy átmegy az App Review-n.

A Stripe adatai szerint a fejlesztők munkaidejük akár 42%-át töltik a meglévő kód olvasásával és megértésével. A szemétkóddal rendelkező projektekben ez az arány meghaladja a 60%-ot, ami rendkívül hatástalanná teszi a fejlesztést.

A kifejezések eredete

Spaghetti code (spagetti kód) — a legrégebbi kifejezés, az 1970-es években jelent meg. Kaotikus vezérlési átmenetekkel rendelkező kódot ír le, amely összegubancolódott spagettire emlékeztet.

Big ball of mud (nagy sárgolyó) — Brian Foot és Joseph Yoder által 1997-ben bevezetett kifejezés azon rendszerek leírására, amelyek egyértelmű architektúra nélkül, kaotikusan "nőnek".

Miért veszélyes a szemétkód az üzletre

Szemétkód lelassítja az új funkciók piacra vitelét. A csapat idejét nem értékteremtésre, hanem a meglévő kód működésének megértésére és annak biztosítására fordítja, hogy semmit ne törjön el.

A McKinsey adatai szerint az alacsony kódminőséggel rendelkező cégek 20-40%-kal többet költenek a termék karbantartására, és az új funkciók piacra vitelének sebessége 2-3-szor alacsonyabb a magas kódminőségű cégekhez képest.

A szemétkód jelei és hogyan ismerjük fel

Felismerni a szemétkódot objektív jelek alapján lehet, amelyek egy részét automatikusan mérik. Minél több jel egyezik — annál súlyosabb a probléma.

Az iparban olyan kódminőségi mérőszámokat használnak, mint a Halstead Complexity, Maintainability Index és Technical Debt Ratio. E mérőszámok ismerete segít a kódbázis állapotának objektív felmérésében.

Copy-paste (kódduplikáció)

Leggyakoribb jel — ismétlődő kódblokkok. A közös függvény kiemelése helyett a fejlesztők minimális változtatásokkal másolják a kódot egyik helyről a másikra.

Normális szintnek az 5%-ig terjedő duplikáció számít. Ha a duplikáció meghaladja a 15%-ot — ez komoly jelzés. Az olyan eszközök, mint a Simian és a PMD Copy Paste Detector segítenek a copy-paste automatikus felderítésében.

Hosszú metódusok és osztályok

Egy metódus 100 sornál hosszabb — a szemétkód egyértelmű jele. Az ilyen metódus általában túl sok mindent csinál és megsérti az egyszeri felelősség elvét (Single Responsibility).

Az osztályok 1000 sornál több kóddal szintén problémásak. Nem kapcsolódó funkcionalitást tartalmaznak, ami megnehezíti a tesztelést, a kód megértését és módosítását.

Magas ciklomatikus komplexitás

Ciklomatikus komplexitás McCabe szerint (Cyclomatic Complexity) — mérőszám, amely a kódban lévő független útvonalak számát mutatja. A 15 feletti érték problémásnak számít.

A 30 feletti komplexitású metódusok — "katasztrófazóna". Túl sok elágazást tartalmaznak, mélyreható elemzés nélkül nem tesztelhetők és nem érthetők meg.

A szemétkód megjelenésének okai

Szemétkód nem "magától" jelenik meg — mindig meghatározott folyamatok és döntések eredménye a csapatban. Az okok megértése lehetővé teszi a jövőbeli megjelenés megelőzését.

A JetBrains Developer Ecosystem 2024 adatai szerint a fejlesztők 67%-a elismeri, hogy időhiány miatt rosszabb kódot ír, mint amire képes lenne. Ez a technikai adósság felhalmozódásának fő oka.

Kapkodás és határidők

Leggyakoribb ok — szoros határidők. A csapat "ahogy jön" írja a kódot, csak hogy határidőre elkészüljön. A refaktorálás, tesztek és code review "későbbre" halasztódik.

A probléma az, hogy a "később" soha nem jön el — a következő sprintben új határidők jelennek meg, és a technikai adósság hógolyóként halmozódik fel.

Code review hiánya

Code review nélkül minden fejlesztő a saját stílusában ír, saját mintákat használ és saját "csapdáit" hagyja maga után. Idővel a kódbázis elveszti egységességét.

Azok a csapatok, amelyek kötelező code review-t alkalmaznak minden pull request-hez, a SmartBear 2024 kutatása szerint 60%-kal kevesebb hibával rendelkeznek éles környezetben.

Gyenge architektúra a kezdetektől

Ha egy projekt egyértelmű architektúra nélkül indul, a szemétkód elkerülhetetlen. Az első "gyors megoldások" olyan alapot raknak le, amelyre később nehéz minőségi dolgot építeni.

Mobil fejlesztésben az architektúra (MVC, MVP, MVVM, Clean Architecture) kiválasztása tudatos döntés kell legyen, amelyet a kódírás megkezdése előtt hoznak meg, nem az evolúció eredménye.

A szemétkód elleni küzdelem módszerei

Küzdelem a szemétkód ellen szisztematikus megközelítést és az egész csapat fegyelmét igényli. Nincs egyetlen eszköz vagy gyakorlat, amely megoldja a problémát — intézkedések összessége szükséges.

A fő elv — ne engedjük meg a szemétkódot az írás fázisában, ahelyett hogy később javítanánk. A megelőzés mindig olcsóbb, mint a meglévő "rendetlenség" refaktorálása.

Kódolási szabványok

Egységes kódstílus — a szemétkód megelőzésének alapja. A kódolási szabványokat (Code Style) dokumentálni kell és automatikusan ellenőrizni linterekkel.

iOS esetén SwiftLint, Android esetén Ktlint és Detekt használatos. A szabályok konfigurációs fájlban történő beállítása lehetővé teszi a szabványokat sértő pull request-ek automatikus elutasítását.

Rendszeres refaktorálás

Refaktorálás — nem hibajavítás, hanem a kód struktúrájának javítása a viselkedés megváltoztatása nélkül. A fejlesztési folyamat rendszeres részének kell lennie, nem külön projektnek.

Javasolt különíteni az egyes sprintek idejének 20%-át refaktorálásra és a technikai adósság törlesztésére. Ez megakadályozza a "rendetlenség" felhalmozódását és hosszú távon fenntartja a csapat sebességét.

Kötelező code review

Minden pull request-nek át kell esnie legalább egy fejlesztő általi review-n. A code review nemcsak hibákat, hanem architekturális sérelmeket, stílusproblémákat és potenciális szemétkód-forrásokat is feltár.

Jó gyakorlat — egy code review ellenőrzőlista, amely magában foglalja a copy-paste, metódushossz, ciklomatikus komplexitás és tesztlefedettség ellenőrzését. Ellenőrzőlista nélkül a bírálók a problémák akár 50%-át is kihagyják.

Ezközök a kódbázis tisztításához

Modern kódelemző eszközök lehetővé teszik a szemétkód automatikus felderítését, a technikai adósság mérését és a minőség ellenőrzését. Ezen eszközök CI/CD pipeline-ba történő integrálása folyamatos monitorozást biztosít.

Javasolt használni legalább egy statikus elemzőt és egy mérőszám-mérő eszközt. Ezen felül egy platform is csatlakoztatható a kódminőségi adatok aggregálására.

Statikus elemzők

• SonarQube — vezető kódminőség-elemző platform, 30+ nyelvet támogat és Technical Debt Ratio mérőszámokat ad
• ESLint — szabvány JavaScript és TypeScript számára, konfigurációs fájlokon keresztül állítható be és IDE-be integrálható
• SwiftLint — kötelező eszköz iOS projektekhez, ellenőrzi a Swift Style Guide-nak való megfelelést

A SonarSource adatai szerint a statikus elemzést használó csapatok a bevezetést követő első negyedévben már 30%-kal csökkentik a hibák számát éles környezetben.

Mérőszám-mérő eszközök

CodeClimate és Codacy — platformok, amelyek összesítik a kódminőségi mérőszámokat, nyomon követik a dinamikát és megmutatják a "forró pontokat" — a legnagyobb technikai adóssággal rendelkező fájlokat.

Android projektekhez a Detekt több mint 100 beépített elemzési szabályt kínál, beleértve a ciklomatikus komplexitás, metódushossz és kódduplikáció ellenőrzését.