Skräpkod och trassel i mobila projekt — tecken och refaktorisering

Vad är skräpkod i utveckling

Skräpkod (även spaghetti code, trassel, big ball of mud) — är en metafor för en kodbas som förlorat sin struktur och förvandlats till en härva av beroenden. I sådan kod förstör varje ändring på ett ställe något annat, och att lägga till ny funktionalitet blir en riskabel uppgift.

I mobilutveckling är skräpkod särskilt kritisk: en app byggd på "trassel" börjar bli långsam, kraschar på äldre enheter och kommer knappt igenom kodgranskning. Ett iOS-projekt utan arkitektur kanske inte klarar App Review på grund av instabilitet.

Enligt Stripe lägger utvecklare upp till 42% av arbetstiden på att läsa och förstå befintlig kod. I projekt med skräpkod överstiger denna siffra 60%, vilket gör utvecklingen extremt ineffektiv.

Termernas ursprung

Spaghetti code (spagettikod) — den äldsta termen, uppstod på 1970-talet. Den beskriver kod med kaotiska kontrollflöden, som påminner om trasslig spaghetti.

Big ball of mud (stor lerboll) — term introducerad av Brian Foot och Joseph Yoder 1997 för att beskriva system utan tydlig arkitektur som "växer" kaotiskt.

Varför skräpkod är farligt för verksamheten

Skräpkod saktar ner lanseringen av nya funktioner till marknaden. Teamet lägger tid inte på att skapa värde, utan på att försöka förstå hur befintlig kod fungerar och inte förstöra något.

Enligt McKinsey lägger företag med låg kodkvalitet 20-40% mer på produktunderhåll, och hastigheten för lansering av nya funktioner är 2-3 gånger lägre jämfört med företag med hög kodkvalitet.

Tecken på skräpkod och hur man känner igen det

Känna igen skräpkod kan göras genom en uppsättning objektiva tecken, varav en del mäts automatiskt. Ju fler tecken som stämmer — desto allvarligare är problemet.

I industrin används kodkvalitetsmått som Halstead Complexity, Maintainability Index och Technical Debt Ratio. Kunskap om dessa mått hjälper till att objektivt bedöma kodbasens tillstånd.

Copy-paste (kodduplicering)

Vanligaste tecknet på skräpkod — upprepande kodblock. Istället för att extrahera en gemensam funktion kopierar utvecklare kod från en plats till en annan med minimala ändringar.

Normal nivå av duplicering anses vara upp till 5%. Om dupliceringen överstiger 15% — är det en allvarlig signal. Verktyg som Simian och PMD Copy Paste Detector hjälper till att automatiskt upptäcka copy-paste.

Långa metoder och klasser

En metod längre än 100 rader — ett tydligt tecken på skräpkod. En sådan metod gör vanligtvis för många saker och bryter mot principen om ensamt ansvar (Single Responsibility).

Klasser med över 1000 rader kod är också problematiska. De innehåller orelaterad funktionalitet, vilket försvårar testning, förståelse och modifiering av koden.

Hög cyklomatisk komplexitet

Cyklomatisk komplexitet enligt McCabe (Cyclomatic Complexity) — ett mått som visar antalet oberoende vägar i koden. Ett värde över 15 anses problematiskt.

Metoder med komplexitet över 30 — "katastrofzon". De innehåller för många förgreningar och kan inte testas eller förstås utan djupgående analys.

Orsaker till skräpkod

Skräpkod uppstår inte "av sig självt" — det är alltid resultatet av specifika processer och beslut i teamet. Att förstå orsakerna gör det möjligt att förhindra dess uppkomst i framtiden.

Enligt JetBrains Developer Ecosystem 2024 erkänner 67% av utvecklarna att de skriver sämre kod än de skulle kunna på grund av tidsbrist. Detta är den främsta orsaken till ackumulering av teknisk skuld.

Stress och deadlines

Vanligaste orsaken — tighta deadlines. Teamet skriver kod "hur det än blir", bara för att hinna till deadline. Refaktorisering, tester och kodgranskning skjuts upp "till senare".

Problemet är att "senare" aldrig kommer — i nästa sprint dyker nya deadlines upp och teknisk skuld ackumuleras som en snöboll.

Brist på kodgranskning

Utan kodgranskning skriver varje utvecklare i sin egen stil, använder sina egna mönster och lämnar sina egna "fällor". Med tiden förlorar kodbasen sin enhetlighet.

Team som tillämpar obligatorisk kodgranskning för varje pull-förfrågan har enligt SmartBear 2024 60% färre defekter i produktion.

Svag arkitektur från början

Om ett projekt startar utan tydlig arkitektur är skräpkod oundvikligt. De första "snabba lösningarna" lägger en grund på vilken det senare är svårt att bygga något kvalitativt.

I mobil utveckling bör valet av arkitektur (MVC, MVP, MVVM, Clean Architecture) vara ett medvetet beslut som fattas innan kodskrivningen påbörjas, inte ett resultat av evolution.

Metoder för att bekämpa skräpkod

Bekämpning av skräpkod kräver ett systematiskt tillvägagångssätt och disciplin från hela teamet. Det finns inget enskilt verktyg eller praxis som löser problemet — en uppsättning åtgärder behövs.

Huvudprincipen — tillåt inte skräpkod i skrivfasen, istället för att fixa det senare. Förebyggande är alltid billigare än refaktorisering av befintligt "trassel".

Kodningsstandarder

Enhetlig kodstil — grunden för att förebygga skräpkod. Kodningsstandarder (Code Style) bör dokumenteras och automatiskt kontrolleras av linters.

För iOS används SwiftLint, för Android — Ktlint och Detekt. Att konfigurera regler i en konfigurationsfil gör det möjligt att automatiskt avvisa pull-förfrågningar som bryter mot standarderna.

Regelbunden refaktorisering

Refaktorisering — är inte att fixa buggar, utan att förbättra kodstrukturen utan att ändra dess beteende. Det bör vara en regelbunden del av utvecklingsprocessen, inte ett separat projekt.

Det rekommenderas att avsätta 20% av tiden i varje sprint för refaktorisering och betalning av teknisk skuld. Detta förhindrar ansamling av "trassel" och bibehåller teamets hastighet på lång sikt.

Obligatorisk kodgranskning

Varje pull-förfrågan bör granskas av minst en utvecklare. Kodgranskning upptäcker inte bara buggar, utan även arkitekturöverträdelser, stilproblem och potentiella källor till skräpkod.

God praxis — en checklista för kodgranskning som inkluderar kontroll av copy-paste, metodlängd, cyklomatisk komplexitet och testtäckning. Utan checklista missar granskare upp till 50% av problemen.

Verktyg för att rensa kodbasen

Moderna kodanalysverktyg gör det möjligt att automatiskt upptäcka skräpkod, mäta teknisk skuld och övervaka kvalitet. Integrering av dessa verktyg i CI/CD-pipelinen säkerställer kontinuerlig övervakning.

Det rekommenderas att använda minst en statisk analysator och ett verktyg för mätning av mått. Dessutom kan en plattform för aggregering av kodkvalitetsdata anslutas.

Statiska analysatorer

• SonarQube — ledande plattform för kodkvalitetsanalys, stöder 30+ språk och ger mått som Technical Debt Ratio
• ESLint — standard för JavaScript och TypeScript, konfigurerbar via konfigurationsfiler och integrerad i IDE
• SwiftLint — obligatoriskt verktyg för iOS-projekt, kontrollerar överensstämmelse med Swift Style Guide

Enligt SonarSource minskar team som använder statisk analys antalet buggar i produktion med 30% redan under första kvartalet efter implementering.

Verktyg för mätning av mått

CodeClimate och Codacy — plattformar som aggregerar kodkvalitetsmått, spårar dynamik och visar "heta punkter" — filer med störst teknisk skuld.

För Android-projekt erbjuder Detekt över 100 inbyggda analysregler, inklusive kontroller av cyklomatisk komplexitet, metodlängd och kodduplicering.