Kryckor i programmering — vad är det, orsaker och när är de berättigade

Vad är en “krycka” i programmering

Krycka (crutch) — en mjukvarulösning som fungerar, men är gjord “i hast”: den stänger ett specifikt problem, men eliminerar inte orsaken, följer inte projektets arkitektur och kan gå sönder vid de minsta förändringar i miljön. Metaforen är träffande — som en riktig krycka hjälper sådan kod att “gå”, men botar inte “benet”.

Utvecklare “stöttar med kryckor” buggar, versionsinkompatibiliteter, plattformsegenskaper och brådskande kundkrav. En typisk krycka — krycka-villkor: om iOS 15, lägg till ett mellanrum; om Huawei — dölj knappen. Sådana kontroller förökas och förvandlar koden till en “lagerkaka” av plattforms- och versionsförgreningar.

Kryckor kan vara av olika omfattning: från en rad med krycka-villkor till en hel mellanmodul som “rättar” ett biblioteks beteende. Det är viktigt att förstå att en krycka inte alltid är ond: i rätta händer är det ett verktyg som gör det möjligt att släppa produkten i tid. Problemet börjar när kryckan förblir i koden för alltid.

Varför uppstår kryckor: orsaker och sammanhang

Huvudorsaken till uppkomsten av kryckor är konflikten mellan den ideala lösningen och projektets verkliga begränsningar. Utvecklaren vet hur man gör rätt, men tid, pengar eller tekniska begränsningar tillåter inte detta. Resultatet blir en kompromisslösning som “bara fungerar”.

Låt oss titta på fyra huvudorsaker till varför utvecklare medvetet tar till kryckor. Att förstå dessa orsaker hjälper till att se kryckor inte som ett misstag, utan som ett pragmatiskt verktyg som kräver hantering.

Deadlines

Den vanligaste orsaken. Släppet är imorgon, buggen reproduceras bara på en specifik modell, arkitekturfixningen tar två veckor. Krycka-villkor tar en timme och stänger problemet. Efter släppet lovar teamet att komma tillbaka och skriva om korrekt. “Inget är mer permanent än en tillfällig lösning” — precis om sådana kryckor.

Versionsinkompatibilitet

Bibliotek A kräver Android 12, men din applikation stöder Android 10. Lösningen — skriv ett mellanlager som kontrollerar OS-versionen och väljer exekveringsväg. Detta är en krycka, eftersom mellanlagret måste skrivas om när biblioteket uppdateras. Men alternativet — att avstå från biblioteket eller stöd för gamla enheter — kan vara värre.

// Krycka för API 29-kompatibilitet
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Externa beroenden med buggar

Ett bibliotek som projektet är beroende av innehåller en bugg, men dess uppdatering kan ta veckor (PR, kodgranskning, publicering krävs). Istället för att vänta skriver teamet en wrapper som lappar bibliotekets beteende i farten. Efter att den korrigerade versionen av biblioteket släppts tas wrappern bort. Om den inte tas bort — är det redan ett arkitekturproblem.

Ofullständig förståelse av systemet

En ny utvecklare i ett legacy-projekt förstår inte varför koden fungerar precis så. Istället för att ta reda på det lägger han till ett nytt villkor ovanpå det befintliga. Detta är den farligaste typen av krycka, eftersom författaren inte är medveten om att det är en krycka. Det enda botemedlet — kodgranskning och parprogrammering för nya teammedlemmar.

När är en krycka berättigad: pragmatisk metod

Inte varje krycka är ond. I verklig utveckling är absolut kodrenhet ouppnåelig och ofta inte ändamålsenlig. Den pragmatiska metoden erkänner att tillfälliga lösningar är en del av processen, men kräver medvetenhet, dokumentation och planering av borttagning. En krycka är berättigad när den löser en affärsuppgift snabbare än en ren arkitekturlösning.

Kriterier för en berättigad krycka: den stänger ett specifikt problem, har en ägare (vem som ansvarar för dess borttagning) och det finns en refaktoreringsplan. Om minst ett av tre villkor inte uppfylls — förvandlas kryckan till teknisk skuld. Verktyg som TODO-kommentarer med ticket i spåraren — det minimala sättet att dokumentera.

Exempel på en berättigad krycka

En kritisk bugg i releasegrenen som måste stängas innan morgondagens driftsättning. Den rena lösningen kräver arkitekturrefaktorering och tar två veckor. Krycka — lägg till en nil-kontroll och skicka fixen som hotfix. Villkor för berättigande: en ticket för refaktorering har skapats i spåraren, en ansvarig person har utsetts, kryckan har markerats med en kommentar. Om två veckor återvänder teamet till uppgiften.

// TODO: IT-1234 — ta bort denna krycka efter refaktorering av AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Hur skiljer man en tillfällig krycka från ett arkitekturproblem

Gränsen mellan en medveten krycka och ett arkitekturproblem (teknisk skuld) går genom två parametrar: medvetenhet om beslutet och förekomsten av en borttagningsplan. En krycka är alltid en tillfällig lösning med känd livslängd. Teknisk skuld — konsekvensen av många kryckor som lämnats utan uppmärksamhet.

När blir en krycka ett problem

Situationen förvärras när antalet kryckor överstiger kritisk massa. Varje ny krycka ökar systemets “bräcklighet”: en förändring på ett ställe förstör något annat. Som ett resultat saktar utvecklingen ner, buggar förökas och en ny utvecklare kan inte förstå koden utan författarens hjälp. I detta ögonblick upphör kryckor att vara tillfälliga lösningar och blir ett arkitekturproblem.

Tecken på kryckkris

Om det i koden finns fem nästlade kontroller för OS-version, enhetstillverkare och förekomst av ett specifikt bibliotek — är detta inte en krycka, det är ett arkitekturproblem. Om tillägget av en fix orsakar tre regressioner i angränsande moduler — har kryckorna upphört att vara lokala. Om kodgranskning regelbundet avvisas på grund av “ännu en krycka” — är det dags att planera refaktorering.

• Samma krycka upprepas på tre eller fler ställen — dags för en enhetlig lösning
• En krycka lever längre än tre sprintar utan borttagningsplan — detta är redan teknisk skuld
• En ny utvecklare förstår inte varför koden fungerar precis så — kryckan är inte dokumenterad
• Borttagning av kryckan orsakar en kedjereaktion av fel — beroendet av kryckan har blivit arkitekturellt

Refaktorering av kryckor: strategi och praktik

Refaktorering av kryckor — processen att ersätta tillfälliga lösningar med arkitekturellt korrekta. Detta kräver tid, därför behövs en prioriteringsstrategi: inte alla kryckor behöver tas bort omedelbart. En bra strategi — utvärdera varje krycka efter två parametrar: förändringsfrekvens i det kodområdet och påverkan på användare.

Prioriteringsstrategi

Hög prioritet — kryckor i ofta ändrade moduler (affärslogik, allmän UI) som saktar ner utveckling och orsakar regressioner. Medel prioritet — kryckor i sällan ändrade moduler, men med potentiell påverkan på användare (betalningshantering, auktorisering). Låg prioritet — kryckor i legacy-kod som fungerar stabilt och inte är planerad för modifiering.

Steg-för-steg-borttagningsprocess

Steg 1: inventering — hitta alla TODO och FIXME relaterade till kryckor. Steg 2: bedömning — avgör vilka som fortfarande är relevanta. Steg 3: planering — tilldela refaktorering av kryckor i en sprint, börja med hög prioritet. Steg 4: ersättning — implementera den rena lösningen, ta bort kryckan och dess TODO-kommentar. Steg 5: verifiering — säkerställ att testerna går och att det inte finns några regressioner.

# Hitta alla TODO-kryckor i projektet
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Förebyggande av nya kryckor

Det bästa sättet att bekämpa kryckor är att inte skapa dem i onödan. Innan du skriver en krycka, ställ dig själv tre frågor: kan en ren lösning göras inom rimlig tid? Finns det ett alternativ som inte är en krycka? Kommer teamet att ha tid att komma tillbaka och skriva om detta? Om minst en fråga besvaras med “nej” — tänk igen innan du “stöttar” koden.