„Működik — ne nyúlj hozzá” — mi ez, az elv lényege és kockázatok

Mi az a „működik — ne nyúlj hozzá” elv?

A „Működik — ne nyúlj hozzá” elv (angolul: „If it ain't broke, don't fix it”) — egy empirikus szabály, amely óva inti a programozókat a működő kód megváltoztatásától elegendő indok nélkül. Az elv alapján egyszerű statisztika áll: a hibák túlnyomó többsége éppen a meglévő kód módosítása során kerül be.

Az elv nem dogma — inkább egy heurisztika, amely segít a döntéshozatalban bizonytalanság esetén. Minél összetettebb és átláthatatlanabb a kódbázis, annál nagyobb a valószínűsége, hogy egy „ártatlan” változtatás elront valamit, amit senki sem várt, hogy elromlik.

A Microsoft vállalat kutatása (2024) szerint az összes kritikus éles incidens körülbelül 60%-a olyan közelmúltbeli kódváltoztatásokhoz kapcsolódik, amelyeket jó szándékkal hajtottak végre, de nem teszteltek kellőképpen valós terhelés mellett.

Az elv története és eredete

A „If it ain't broke, don't fix it” idioma a 20. század közepének amerikai mérnöki kultúrájához nyúlik vissza. A legkorábbi dokumentált használat Bert Lance (1977) nevéhez fűződik, aki az USA Szenátusának Pénzügyi Bizottságában dolgozott és a túlzott szabályozás ellen lépett fel.

A programozásba az elv a hardvermérnökségből érkezett, ahol egy működő chip cseréje egy újra kiszámíthatatlan következményekkel járhatott. A szoftverek kontextusában ez az elv különösen elterjedtté vált a szoftverrendszerek összetettségének növekedésével és az örökölt kód megjelenésével.

Érdekes módon a programozásban az elvnek van egy másik oldala is — a „működik, de jobb nem hozzányúlni” gyakran ürügy lesz a refaktorálás elutasítására, ami hosszú távon a technikai adósság kritikus felhalmozódásához vezet. A Thoughtworks tanácsadó cég (2023) szerint a projektek körülbelül 40%-a szembesül súlyos problémákkal a változtatásokkal szembeni túlzott konzervativizmus miatt.

Mikor alkalmazzuk az elvet

A „Működik — ne nyúlj hozzá” elv különösen aktuális bizonyos helyzetekben, amikor a hiba ára meghaladja a változtatások potenciális hasznát.

Örökölt projektek tesztek nélkül

Az örökölt kódban, amelyet nem fednek le tesztek, minden változtatás orosz rulett. Ha a programozó nem tudja ellenőrizni, hogy a változtatás nem rontotta el a szomszédos modulokat, a legjobb stratégia, ha nem nyúl a működő kódhoz. Kivétel — csak kritikus hibák vagy biztonsági követelmények.

Kritikus rendszerek

Azokban a rendszerekben, ahol az állásidő elfogadhatatlan vagy a hiba ára óriási — orvosi szoftverek, repüléselektronika, pénzügyi tranzakciók — a „működik — ne nyúlj hozzá” elv de facto szabvány. Minden változtatás többlépcsős egyeztetésen és tesztelésen megy keresztül.

Szoros határidők

Ha a kiadás holnap van és a kód működik — ne próbáld javítani az architektúráját. Csak azt változtasd meg, ami közvetlenül befolyásolja a kiadás funkcióit. A refaktorálást halaszd a következő sprintre (de ne feledkezz meg róla).

Az elv követésének kockázatai

A „működik — ne nyúlj hozzá” elv vak követése nem kisebb kockázatokkal jár, mint a végtelen refaktorálás. Nézzük a főbb veszélyeket.

Technikai adósság felhalmozódása

Ha minden programozó ezt az elvet követi, a kódbázis gyorsan elavult megoldások, mankók és nem optimális algoritmusok „réteges tortájává” válik. Előbb-utóbb a technikai adósság elviselhetetlenné válik — minden változtatás hetekig tartó elemzést igényel.

Elszalasztott optimalizálás

Néha a változtatás, amely kockázatosnak tűnik, valójában jelentősen javítja a teljesítményt vagy a biztonságot. A „működik — ne nyúlj hozzá” elv nem blokkolhatja azokat a változtatásokat, amelyek mérhető hasznot hoznak — csökkentik a szerverköltségeket, gyorsítják az oldalbetöltést, növelik a biztonságot.

Kompetenciák elvesztése

Amikor a csapat évekig nem nyúl a kód bizonyos részeihez, elveszti a megértését annak, hogyan működnek. Távozik a kulcsprogramozó — és a kód örökölt kóddá válik karbantartási lehetőség nélkül. Az elvet a projekt hosszú távú karbantartásának figyelembevételével kell alkalmazni.

Arany középút: refaktorálás fanatizmus nélkül

Az optimális stratégia — ne kövesd az elvet vakon, hanem alkalmazd tudatosan, a kontextust figyelembe véve. A refaktorálás szükséges, de biztonságosnak kell lennie.

A cserkész szabálya

A cserkész szabálya a programozásban: „Hagyd a kódot tisztábban, mint ahogy találtad”. Ha a programozó változtatást végez egy modulban, javítania kell a szerkezetén, de ésszerű határokon belül. Nem mindent újraírni, de legalább átnevezni az olvashatatlan változókat és megjegyzéseket hozzáadni.

Refaktorálás tesztek védelme alatt

A tesztek — az egyetlen módja a „működik — ne nyúlj hozzá” elv biztonságos alkalmazásának. Ha a kódot tesztek fedik le, minden refaktorálás kiszámíthatóvá válik: a programozó módosítja a kódot, futtatja a teszteket és látja, hogy nem romlott-e el valami. Tesztek nélkül — ne nyúlj hozzá. Tesztekkel — refaktorálj bátran.

// Példa: biztonságos refaktorálás tesztlefedettség alatt
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Régi, de működő kód
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Teszt, amely véd a regressziótól
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Ez a példa a helyes megközelítést mutatja: először a teszt, aztán a refaktorálás. Ha a teszt sikeres — a változtatás biztonságos. A „működik — ne nyúlj hozzá” elv átalakul „működik tesztek alatt — refaktorálj bátran” elvvé.

Valós példák a gyakorlatból

Vizsgáljunk meg valós forgatókönyveket, amelyekben a „működik — ne nyúlj hozzá” elv egyszerre bizonyult megmentőnek és rombolónak.

Megmentő eset: Y2K-szerű probléma

Egy programozó felfedezte, hogy a dátumfeldolgozó kódban DD/MM/YY formátumot használtak YYYY helyett. A kód 2000-től 2025-ig helyesen működött. Annak ellenére, hogy „javítani” akarta — meghagyta a kódot úgy, ahogy volt, mindössze egy megjegyzést fűzött hozzá. 2026-ban a cég frissítette a rendszert, és az új megoldás már helyesen kezelte az évszázadokat. Az idő előtti változtatás csak elrontotta volna a működő logikát.

Romboló eset: adatvesztés a „javítás” miatt

Egy mérnök úgy döntött, hogy „javítja” a régi, de működő adatimportáló kódot egy modern könyvtárra cserélve. Nem vette figyelembe, hogy a régi könyvtár egy speciális határesetet kezelt, amely nem volt dokumentálva. A kiadás után — tömeges adatvesztés. A „működik — ne nyúlj hozzá” elvet megsértették, és a hiba ára a csapat két hetes helyreállítási munkája volt.