Hardcodul în dezvoltare: ce este, riscuri și cum să eviți

Ce înseamnă „bătut în cuie” și „hardcodat”

A hardcoda (a băte în cuie) – a încorpora o valoare specifică în codul programului astfel încât pentru a o modifica este necesară editarea codului sursă și recompilarea aplicației. Metafora „bătut în cuie” reflectă exact esența: valoarea este fixată definitiv și poate fi separată de cod doar cu efort.

Exemplu de hardcod – URL-ul serverului scris ca string direct în corpul funcției. Dacă serverul se mută la o altă adresă, dezvoltatorul trebuie să găsească stringul în cod, să îl modifice, să recompileze aplicația și să lanseze o nouă versiune. Într-o aplicație cu arhitectură corectă, un astfel de URL ar fi externalizat într-un fișier de configurare, o variabilă de mediu sau un serviciu de configurare.

Termenul „bătut în cuie” are o conotație mai emoțională: subliniază că valoarea este fixată rigid fără posibilitatea de înlocuire rapidă. În mediul românesc, ambele expresii sunt folosite ca sinonime complete cu conotație negativă. Uneori hardcodul este numit ironic „constantă externalizată într-o constantă separată dintr-o constantă”.

De ce hardcodul este considerat anti-pattern

Hardcodul este un anti-pattern deoarece încalcă principiile de întreținere, testare și extensibilitate ale codului. În codul în care valorile sunt „bătute în cuie”, orice modificare a mediului, designului sau logicii necesită căutare manuală și înlocuire în surse. Acest lucru crește riscul de erori și încetinește dezvoltarea.

Să analizăm consecințele concrete ale hardcodului pe exemplul unei aplicații mobile tipice. Dacă dimensiunea spațierii tuturor butoanelor este dată de un număr în cod, nu printr-o resursă – modificarea designului va necesita găsirea tuturor aparițiilor și înlocuirea lor. Dacă URL-ul endpoint-ului este scris rigid – comutarea între medii (dev, stage, prod) este imposibilă fără recompilare.

Exemplu de hardcod prost

O funcție care folosește numere magice și stringuri scrise rigid este un exemplu clasic de hardcod. După o lună, autorul nu își va aminti ce înseamnă 18, 0.07 și 2.5. După un an – nimeni din echipă nu va îndrăzni să modifice aceste numere, de teamă să nu strice logica. Externalizarea valorilor în constante denumite face codul autodocumentat.

// Rău: numere magice și stringuri
fun calculatePrice(base: Double): Double {
    val tax = base * 0.07
    val tip = base * 0.15
    val discount = if (base > 100) 10 else 0
    return base + tax + tip - discount
}

Impactul asupra testării

URL-ul hardcodat al bazei de date nu va permite rularea testelor pe o bază de date locală in-memory. Dezvoltatorul va trebui să pornească un server complet sau să modifice codul înainte de testare. Externalizarea configurației din cod rezolvă problema: testele folosesc parametri de test, producția – parametri reali, iar codul nu se modifică.

Când este justificat hardcodul: excepții de la regulă

Hardcodul este un anti-pattern, dar există excepții legitime când o valoare scrisă rigid este nu doar admisibilă, ci și preferabilă. Granița trece pe axa variabilității: dacă valoarea nu se schimbă niciodată sau aproape niciodată în ciclul de viață al aplicației, poate fi hardcodată. Dacă cel puțin potențial se poate schimba – externalizează în configurare.

Constantele matematice și fizice – numărul Pi, accelerația gravitațională, numărul de milisecunde într-o secundă – sunt sigure pentru hardcod. Sunt definite de natură sau standarde și nu se vor modifica. Dimensiunile array-urilor constante definite de specificație pot fi, de asemenea, fixate rigid, dar cu un comentariu despre originea numărului.

Exemplu de hardcod justificat

Numărul de milisecunde într-o secundă este o constantă stabilă definită de standardul de timp. Nu are sens să o externalizezi în config, deoarece nu se va schimba niciodată. Cu toate acestea, chiar și astfel de constante este mai bine să fie declarate cu un nume sugestiv, astfel încât codul să nu conțină „numere magice”: în loc de 1000, scrie MILLISECONDS_IN_SECOND.

// Hardcod justificat: constante stabile
private const val MILLIS_IN_SECOND = 1000
private const val LOGIN_TIMEOUT_SECONDS = 30

fun formatDuration(ms: Long): String {
    val seconds = ms / MILLIS_IN_SECOND
    return "${seconds} sec."
}

Alternative la hardcod: configuri, ENV, DI

Există mai multe metode dovedite pentru a evita hardcodul, fiecare potrivită pentru un tip specific de valori. Alegerea alternativei depinde de cât de des se schimbă valoarea și cine o modifică: dezvoltatorul, devops-ul sau utilizatorul final.

Fișiere de configurare

Pentru URL-uri de servere, chei API și feature flags, folosește fișiere de configurare în formate JSON, YAML sau TOML. Pe Android este build.gradle cu buildConfigField sau res/values/config.xml. Pe iOS – Info.plist sau xcconfig. Configurile sunt compilate împreună cu aplicația, dar pot fi diferite pentru diferite scheme de build.

Variabile de mediu

Pentru secrete (tokenuri, parole) și parametri de mediu, folosește variabile de mediu. Acestea nu ajung în repository și pot diferi pe serverele dev, stage și prod. În dezvoltarea mobilă, variabilele de mediu sunt adesea emulate prin scheme de build Xcode sau build flavors în Gradle.

Resursele aplicației

Stringurile, culorile, dimensiunile, imaginile trebuie externalizate în fișiere de resurse: strings.xml pe Android, Localizable.strings pe iOS, fișiere ARB în Flutter. Acest lucru simplifică localizarea, adaptarea la diferite ecrane și tema întunecată. Modificarea unui string în resurse nu necesită rescrierea codului.

<!-- Android: res/values/strings.xml -->
<resources>
    <string name="app_name">MyApp</string>
    <string name="api_base_url">https://api.example.com</string>
</resources>

Injecția dependențelor (DI)

Pentru servicii și furnizori, folosește Dependency Injection prin Dagger, Hilt sau Koin pe Android, Swinject pe iOS. Framework-urile DI permit înlocuirea implementărilor din zbor – pentru teste, pentru diferite medii, pentru diferiți utilizatori. Acesta este cel mai înalt nivel de abstractizare, unde „fixarea” valorii este înlocuită cu injecția din exterior.

Cum să refactorizezi codul hardcodat

Refactorizarea hardcodului este procesul de externalizare a valorilor scrise rigid în configurare sau resurse. Este una dintre cele mai sigure operații de refactorizare, dacă este executată metodic. Secvența descrisă mai jos este potrivită pentru orice limbaj și platformă.

Pasul 1: găsește toate numerele magice și stringurile

Căutarea poate fi efectuată prin IDE (Search in Project) sau printr-un script. Caută stringuri, URL-uri, literali numerici, dimensiuni, timeout-uri. Atenție specială la valorile repetitive: dacă același număr apare în cinci locuri, este un candidat pentru externalizare într-o constantă. Folosește grep sau căutarea încorporată IDEA / Xcode.

Pasul 2: înlocuiește cu constante denumite

Pentru fiecare valoare găsită, creează o constantă cu un nume sugestiv. Grupează constantele pe module sau clase. Numele trebuie să explice ce înseamnă valoarea, nu cum este utilizată: API_TIMEOUT, nu TIMEOUT_30. După înlocuire, niciun număr din cod nu trebuie să rămână fără explicație.

// Înainte: numărul magic 0.4
let cardHeight = screenHeight * 0.4

// După: constantă denumită
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Pasul 3: externalizează în configurare sau resurse

Dacă valoarea se poate modifica între compilări sau medii – externalizeaz-o într-un fișier de configurare sau în resursele aplicației. Pentru stringuri, folosește fișiere de localizare. Pentru URL-uri – build config sau xcconfig. Pentru dimensiuni – fișiere de resurse (dimens.xml pe Android). Verifică că aplicația se compilează și funcționează corect după externalizare.

Pasul 4: scrie un test

După refactorizare, scrie un test care verifică că configurația se încarcă corect și valorile corespund celor așteptate. Dacă în viitor cineva modifică configul, testul va indica neconcordanța. Testul de configurare este o modalitate rapidă și fiabilă de a preveni regresia.

Pasul 5: elimină duplicatele

După externalizarea în config, verifică că toate locurile în care se folosea valoarea veche se referă la o sursă unică. Elimină codul comentat și constantele vechi care nu mai sunt utilizate. Finalizează refactorizarea cu un commit având un mesaj care descrie ce valori și unde au fost externalizate.