„Funcționează — nu atinge” — ce este, esența principiului și riscuri

Ce este principiul „funcționează — nu atinge”?

Principiul „Funcționează — nu atinge” (eng. „If it ain't broke, don't fix it”) — este o regulă empirică care îi avertizează pe programatori să nu facă modificări în codul funcțional fără motive suficiente. La baza principiului stă o statistică simplă: marea majoritate a defectelor sunt introduse tocmai în procesul de modificare a codului existent.

Principiul nu este o dogmă — este mai degrabă o euristică ce ajută la luarea deciziilor în condiții de incertitudine. Cu cât baza de cod este mai complexă și mai încâlcită, cu atât este mai mare probabilitatea ca o modificare „nevinovată” să strice ceva ce nimeni nu se aștepta să se strice.

Potrivit cercetării corporației Microsoft (2024), aproximativ 60% din toate incidentele critice din producție sunt legate de modificări recente ale codului, care au fost făcute cu intenții bune, dar nu au fost testate suficient în condiții de sarcină reală.

Istoria și originea principiului

Idioma „If it ain't broke, don't fix it” își are originea în cultura inginerească americană de la mijlocul secolului XX. Cea mai timpurie utilizare documentată este atribuită lui Bert Lance (1977), care lucra în Comitetul Financiar al Senatului SUA și se opunea reglementării excesive.

În programare, principiul a venit din ingineria hardware, unde înlocuirea unui circuit funcțional cu unul nou putea duce la consecințe imprevizibile. În contextul software-ului, acest principiu a căpătat o răspândire deosebită odată cu creșterea complexității sistemelor și apariția codului legacy.

Interesant, în programare principiul are și o față ascunsă — „funcționează, dar e mai bine să nu atingi” devine adesea o justificare pentru refuzul refactorizării, ceea ce pe termen lung duce la acumularea critică a datoriei tehnice. Potrivit companiei de consultanță Thoughtworks (2023), aproximativ 40% dintre proiecte se confruntă cu probleme grave din cauza conservatorismului excesiv față de schimbări.

Când se aplică principiul

Principiul „Funcționează — nu atinge” este deosebit de actual în anumite situații, când prețul erorii depășește beneficiul potențial al modificărilor.

Proiecte legacy fără teste

În codul legacy care nu este acoperit de teste, orice modificare este o ruletă rusească. Dacă programatorul nu poate verifica dacă modificarea a stricat modulele învecinate, cea mai bună strategie este să nu atingă codul funcțional. Excepție — doar bug-urile critice sau cerințele de securitate.

Sisteme critice

În sistemele unde timpul de nefuncționare este inadmisibil sau prețul erorii este enorm — software medical, avionică, tranzacții financiare — principiul „funcționează — nu atinge” este standardul de facto. Orice modificare trece prin etape multiple de aprobare și testare.

Termene stricte

Dacă lansarea este mâine, iar codul funcționează — nu încerca să îi îmbunătățești arhitectura. Schimbă doar ceea ce afectează direct funcționalitatea lansării. Refactorizarea amân-o pentru următorul sprint (dar nu uita de ea).

Riscurile respectării principiului

Respectarea oarbă a principiului „funcționează — nu atinge” prezintă riscuri nu mai mici decât refactorizarea infinită. Să analizăm principalele pericole.

Acumularea datoriei tehnice

Dacă fiecare programator se ghidează după acest principiu, baza de cod se transformă rapid într-un „tort în straturi” de soluții învechite, improvizații și algoritmi neoptimali. Mai devreme sau mai târziu, datoria tehnică devine insuportabilă — orice modificare necesită săptămâni de analiză.

Optimizare ratată

Uneori, modificarea care pare riscantă îmbunătățește de fapt semnificativ performanța sau securitatea. Principiul „funcționează — nu atinge” nu trebuie să blocheze modificările care aduc beneficii măsurabile — reduc costurile serverelor, accelerează încărcarea paginilor, sporesc securitatea.

Pierderea competențelor

Când echipa nu atinge ani de zile anumite porțiuni de cod, își pierde înțelegerea modului în care funcționează. Pleacă programatorul cheie — și codul devine legacy fără posibilitate de întreținere. Principiul trebuie aplicat cu luarea în considerare a întreținerii pe termen lung a proiectului.

Mijlocul de aur: refactorizare fără fanatism

Strategia optimă — nu respecta principiul orb, ci aplică-l conștient, ținând cont de context. Refactorizarea este necesară, dar trebuie să fie sigură.

Regula cercetașului

Regula cercetașului în programare: „Lasă codul mai curat decât l-ai găsit”. Dacă programatorul face o modificare într-un modul, trebuie să îi îmbunătățească structura, dar în limite rezonabile. Să nu rescrie totul de la zero, ci măcar să redenumească variabilele ilizibile și să adauge comentarii.

Refactorizare sub protecția testelor

Testele — singurul mod de a aplica în siguranță principiul „funcționează — nu atinge”. Dacă codul este acoperit de teste, orice refactorizare devine predictibilă: programatorul modifică codul, rulează testele și vede dacă s-a stricat ceva. Fără teste — nu atinge. Cu teste — refactorizează cu încredere.

// Exemplu: refactorizare sigură sub acoperire de teste
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Cod vechi, dar funcțional
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test care protejează de regresie
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Acest exemplu demonstrează abordarea corectă: mai întâi testul, apoi refactorizarea. Dacă testul trece — modificarea este sigură. Principiul „funcționează — nu atinge” se transformă în „funcționează sub teste — refactorizează cu încredere”.

Exemple reale din practică

Să analizăm scenarii reale în care principiul „funcționează — nu atinge” s-a dovedit atât salvator, cât și distructiv.

Caz salvator: problemă similară Y2K

Un programator a descoperit că în codul de procesare a datelor se folosește formatul DD/MM/YY în loc de YYYY. Codul funcționa corect între 2000 și 2025. În ciuda dorinței de a „repara” — a lăsat codul neschimbat, limitându-se la un comentariu. În 2026, compania a actualizat sistemul, iar noua soluție gestiona corect secolele. O modificare prematură ar fi stricat logica funcțională.

Caz distructiv: pierderea datelor din cauza „îmbunătățirii”

Un inginer a decis să „îmbunătățească” codul vechi, dar funcțional, de import al datelor, înlocuindu-l cu o bibliotecă modernă. Nu a ținut cont că biblioteca veche gestiona un caz specific de margine care nu era documentat. După lansare — pierdere masivă de date. Principiul „funcționează — nu atinge” a fost încălcat, iar prețul erorii a fost de două săptămâni de muncă a echipei pentru recuperare.