"Fungerar — rör inte" — vad det är, principens kärna och risker

Vad är principen "fungerar — rör inte"?

Principen "Fungerar — rör inte" (engelska: "If it ain't broke, don't fix it") — är en empirisk regel som varnar programmerare från att göra ändringar i fungerande kod utan tillräckliga skäl. I grunden av principen ligger enkel statistik: den överväldigande majoriteten av defekter introduceras just vid modifiering av befintlig kod.

Principen är inte ett dogm — det är snarare en heuristik som hjälper till att fatta beslut under osäkerhet. Ju mer komplex och trasslig kodbasen är, desto högre är sannolikheten att en "oskyldig" förändring sabbar något som ingen förväntade sig skulle sabba.

Enligt forskning från Microsoft Corporation (2024) är cirka 60% av alla kritiska incidenter i produktion kopplade till senaste kodändringar som gjordes i god tro men inte testades tillräckligt under verklig belastning.

Principens historia och ursprung

Idiomet "If it ain't broke, don't fix it" härstammar från den amerikanska ingenjörskulturen i mitten av 1900-talet. Den tidigaste dokumenterade användningen tillskrivs Bert Lance (1977), som arbetade i USAs senats finanskommitté och motsatte sig överdriven reglering.

In i programmeringen kom principen från hårdvaruteknik, där utbyte av ett fungerande chip mot ett nytt kunde leda till oförutsägbara konsekvenser. I mjukvarusammanhang fick denna princip särskild spridning med ökad komplexitet hos mjukvarusystem och uppkomsten av äldre kod.

Intressant nog har principen inom programmering också en baksida — "det fungerar, men bättre att inte röra" blir ofta en ursäkt för att vägra refaktorisering, vilket på lång sikt leder till kritisk ackumulering av teknisk skuld. Enligt konsultföretaget Thoughtworks (2023) stöter cirka 40% av projekt på allvarliga problem på grund av överdriven konservatism inför förändringar.

När principen ska tillämpas

Principen "Fungerar — rör inte" är särskilt relevant i vissa situationer när priset för ett fel överstiger den potentiella nyttan av förändringar.

Äldre projekt utan tester

I äldre kod som inte täcks av tester är varje förändring ett spel med rysk roulett. Om en programmerare inte kan kontrollera att förändringen inte saboterade angränsande moduler, är den bästa strategin att inte röra fungerande kod. Undantag — endast kritiska buggar eller säkerhetskrav.

Kritiska system

I system där driftstopp är oacceptabelt eller priset för ett fel är enormt — medicinsk mjukvara, avionik, finansiella transaktioner — är principen "fungerar — rör inte" de facto-standard. Varje förändring går igenom flera steg av godkännande och testning.

Strama deadlines

Om release är i morgon och koden fungerar — försök inte förbättra arkitekturen. Ändra bara det som direkt påverkar release-funktionaliteten. Skjut upp refaktorisering till nästa sprint (men glöm inte bort den).

Risker med att följa principen

Blint följande av principen "fungerar — rör inte" medför inte mindre risker än oändlig refaktorisering. Låt oss titta på de främsta farorna.

Ackumulering av teknisk skuld

Om varje programmerare följer denna princip, förvandlas kodbasen snabbt till en "lagerkaka" av föråldrade lösningar, kryckor och suboptimala algoritmer. Förr eller senare blir den tekniska skulden outhärdlig — varje förändring kräver veckors analys.

Missad optimering

Ibland visar sig en förändring som verkar riskfylld faktiskt avsevärt förbättra prestanda eller säkerhet. Principen "fungerar — rör inte" bör inte blockera förändringar som ger mätbara fördelar — minskar serverkostnader, snabbar upp sidladdning, ökar säkerheten.

Förlust av kompetens

När teamet under åratal inte rör vissa delar av koden, förlorar det förståelsen för hur de fungerar. Nyckelprogrammeraren slutar — och koden blir äldre kod utan underhållsmöjlighet. Principen bör tillämpas med hänsyn till långsiktigt underhåll av projektet.

Gyllene medelvägen: refaktorisering utan fanatism

Den optimala strategin — följ inte principen blint, utan tillämpa den medvetet med hänsyn till sammanhanget. Refaktorisering är nödvändig, men måste vara säker.

Scoutregeln

Scoutregeln inom programmering: "Lämna koden renare än du fann den". Om en programmerare gör en förändring i en modul, bör han förbättra dess struktur, men inom rimliga gränser. Inte skriva om allt från början, men åtminstone byta namn på oläsbara variabler och lägga till kommentarer.

Refaktorisering under tests skydd

Tester — det enda sättet att säkert tillämpa principen "fungerar — rör inte". Om kod täcks av tester blir varje refaktorisering förutsägbar: programmeraren ändrar koden, kör testerna och ser om något gick sönder. Utan tester — rör inte. Med tester — refaktorisera med tillförsikt.

// Exempel: säker refaktorisering under testtäckning
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Gammal men fungerande kod
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test som skyddar mot regression
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Detta exempel visar rätt tillvägagångssätt: först testet, sedan refaktorisering. Om testet passerar — är förändringen säker. Principen "fungerar — rör inte" omvandlas till "fungerar under tester — refaktorisera djärvt".

Verkliga exempel från praktiken

Låt oss titta på verkliga scenarier där principen "fungerar — rör inte" visade sig vara både räddande och destruktiv.

Räddande fall: Y2K-liknande problem

En programmerare upptäckte att i koden för datumhantering användes formatet DD/MM/YY istället för YYYY. Koden fungerade korrekt från 2000 till 2025. Trots önskan att "åtgärda" det — lämnade han koden som den var, nöjd med en kommentar. 2026 uppdaterade företaget systemet och den nya lösningen hanterade redan århundraden korrekt. En förtida förändring skulle ha saboterat den fungerande logiken.

Destruktivt fall: dataförlust på grund av "förbättring"

En ingenjör beslutade att "förbättra" den gamla men fungerande koden för dataimport genom att ersätta den med ett modernt bibliotek. Han tog inte hänsyn till att det gamla biblioteket hanterade ett specifikt gränsfall som inte var dokumenterat. Efter releasen — massiv dataförlust. Principen "fungerar — rör inte" bröts och priset för felet var två veckors teamarbete för återställning.