„Funguje — nešahej na to“ — co to je, podstata principu a rizika

Co je princip „funguje — nešahej na to“?

Princip „Funguje — nešahej na to“ (anglicky: „If it ain't broke, don't fix it“) — je empirické pravidlo, které varuje programátory před prováděním změn ve funkčním kódu bez dostatečných důvodů. V základu principu leží jednoduchá statistika: drtivá většina defektů je zavedena právě při modifikaci stávajícího kódu.

Princip není dogma — je to spíše heuristika, která pomáhá při rozhodování v podmínkách nejistoty. Čím složitější a zamotanější je kódová základna, tím vyšší je pravděpodobnost, že „nevinná“ změna rozbije něco, co nikdo nečekal, že se rozbije.

Podle výzkumu společnosti Microsoft (2024) souvisí přibližně 60 % všech kritických incidentů v produkci s nedávnými změnami kódu, které byly provedeny s dobrými úmysly, ale nebyly dostatečně otestovány v podmínkách reálné zátěže.

Historie a původ principu

Idiom „If it ain't broke, don't fix it“ sahá do americké inženýrské kultury poloviny 20. století. Nejdříve zdokumentované použití je připisováno Bertu Lanceovi (1977), který pracoval ve Finančním výboru Senátu USA a stavěl se proti nadměrné regulaci.

Do programování princip přišel z hardwarového inženýrství, kde výměna fungujícího čipu za nový mohla vést k nepředvídatelným následkům. V kontextu softwaru tento princip získal zvláštní rozšíření s růstem složitosti softwarových systémů a vznikem legacy kódu.

Zajímavé je, že v programování má princip i odvrácenou stranu — „funguje, ale raději na to nešahej“ se často stává záminkou k odmítnutí refaktorizace, což dlouhodobě vede ke kritickému hromadění technického dluhu. Podle poradenské společnosti Thoughtworks (2023) se přibližně 40 % projektů potýká s vážnými problémy kvůli nadměrnému konzervatismu vůči změnám.

Kdy princip použít

Princip „Funguje — nešahej na to“ je obzvláště aktuální v určitých situacích, kdy cena chyby převyšuje potenciální přínos změn.

Legacy projekty bez testů

V legacy kódu, který není pokryt testy, je každá změna hrou v ruskou ruletu. Pokud programátor nemůže zkontrolovat, že změna nerozbila sousední moduly, nejlepší strategií je nechat funkční kód být. Výjimka — pouze kritické chyby nebo bezpečnostní požadavky.

Kritické systémy

V systémech, kde je prostoj nepřijatelný nebo cena chyby obrovská — medicínský software, avionika, finanční transakce — je princip „funguje — nešahej na to“ de facto standardem. Každá změna prochází vícestupňovým schvalováním a testováním.

Přísné termíny

Pokud je release zítra a kód funguje — nesnažte se vylepšit jeho architekturu. Změňte jen to, co přímo ovlivňuje funkcionalitu release. Refaktorizaci odložte na další sprint (ale nezapomeňte na ni).

Rizika dodržování principu

Slepé dodržování principu „funguje — nešahej na to“ přináší neméně rizik než nekonečná refaktorizace. Podívejme se na hlavní nebezpečí.

Hromadění technického dluhu

Pokud se každý programátor řídí tímto principem, kódová základna se rychle promění ve „vrstvený dort“ ze zastaralých řešení, berliček a neoptimálních algoritmů. Dříve či později se technický dluh stane neúnosným — každá změna vyžaduje týdny analýzy.

Promarněná optimalizace

Někdy změna, která vypadá riskantně, ve skutečnosti výrazně zlepšuje výkon nebo bezpečnost. Princip „funguje — nešahej na to“ by neměl blokovat změny, které přinášejí měřitelný prospěch — snižují náklady na servery, zrychlují načítání stránek, zvyšují bezpečnost.

Ztráta kompetencí

Když tým roky nesa há na určité části kódu, ztrácí pochopení toho, jak fungují. Odejde klíčový programátor — a kód se změní v legacy bez možnosti údržby. Princip by měl být aplikován s ohledem na dlouhodobou údržbu projektu.

Zlatá střední cesta: refaktorizace bez fanatismu

Optimální strategie — neřídit se principem slepě, ale aplikovat ho vědomě s ohledem na kontext. Refaktorizace je potřebná, ale musí být bezpečná.

Pravidlo skauta

Pravidlo skauta v programování: „Zanech kód čistší, než jsi ho našel“. Pokud programátor provádí změnu v modulu, měl by zlepšit jeho strukturu, ale v rozumných mezích. Nepřepisovat vše od nuly, ale alespoň přejmenovat nečitelné proměnné a přidat komentáře.

Refaktorizace pod ochranou testů

Testy — jediný způsob, jak bezpečně aplikovat princip „funguje — nešahej na to“. Pokud je kód pokryt testy, každá refaktorizace se stává předvídatelnou: programátor změní kód, spustí testy a uvidí, jestli se něco nerozbilo. Bez testů — nešahej na to. S testy — refaktoruj s důvěrou.

// Příklad: bezpečná refaktorizace pod pokrytím testy
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Starý, ale fungující kód
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test chránící před regresí
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Tento příklad ukazuje správný přístup: nejprve test, poté refaktorizace. Pokud test projde — změna je bezpečná. Princip „funguje — nešahej na to“ se transformuje na „funguje pod testy — refaktoruj směle“.

Reálné příklady z praxe

Podívejme se na reálné scénáře, ve kterých se princip „funguje — nešahej na to“ ukázal jako zachraňující i ničivý.

Zachraňující případ: problém podobný Y2K

Programátor zjistil, že v kódu pro zpracování dat je použit formát DD/MM/YY místo YYYY. Kód fungoval správně od roku 2000 do roku 2025. Přes touhu „opravit“ to — nechal kód být, omezil se na komentář. V roce 2026 společnost aktualizovala systém a nové řešení již správně zpracovávalo staletí. Předčasná změna by rozbila fungující logiku.

Ničivý případ: ztráta dat kvůli „vylepšení“

Inženýr se rozhodl „vylepšit“ starý, ale fungující kód pro import dat tím, že jej nahradil moderní knihovnou. Nevzal v úvahu, že stará knihovna zpracovávala specifický okrajový případ, který nebyl zdokumentován. Po release — masivní ztráta dat. Princip „funguje — nešahej na to“ byl porušen a cena chyby byla dva týdny práce týmu na obnově.