Хардкод у развоју: шта је то, ризици и како избећи

Шта значи „приковати“ и „хардкодовати“

Хардкодовати (приковати) – уградити конкретну вредност у код програма тако да је за њену промену потребно уређивање изворног кода и прекомпајлирање апликације. Метафора „приковати“ тачно одражава суштину: вредност је чврсто фиксирана и може се одвојити од кода само са напором.

Пример хардкода – УРЛ сервера записан као стринг директно у телу функције. Ако сервер пређе на другу адресу, програмер треба да пронађе стринг у коду, промени га, поново изгради апликацију и објави издање. У апликацији са исправном архитектуром такав УРЛ би био извучен у конфигурациони фајл, променљиву окружења или сервис конфигурације.

Термин „приковати“ има емотивнију конотацију: наглашава да је вредност уметнута чврсто и без могућности брзе замене. У српском окружењу оба израза се користе као потпуни синоними са негативном конотацијом. Понекад се хардкод иронично назива „константом извученом у посебну константу из константе“.

Зашто се хардкод сматра анти-обрасцем

Хардкод је анти-образац јер нарушава принципе одржавања, тестирања и проширивости кода. У коду где су вредности „приковане“, свака промена окружења, дизајна или логике захтева ручно тражење и замену у изворима. То повећава ризик од грешака и успорава развој.

Размотримо конкретне последице хардкода на примеру типичне мобилне апликације. Ако је размак свих дугмади задат бројем у коду, а не кроз ресурс – промена дизајна ће захтевати проналажење свих појављивања и замену. Ако је УРЛ крајње тачке чврсто уписан – пребацивање између окружења (dev, stage, prod) није могуће без прекомпајлирања.

Пример лошег хардкода

Функција која користи магичне бројеве и чврсто уписане стрингове је класика хардкода. После месец дана аутор неће запамтити шта значе 18, 0.07 и 2.5. После годину дана – нико у тиму неће усудити да мења ове бројеве, плашећи се да поквари логику. Извлачење вредности у именоване константе чини код самодокументујућим.

// Лоше: магични бројеви и стрингови
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
}

Утицај на тестирање

Хардкодовани УРЛ базе података неће дозволити покретање тестова на локалној in-memory бази података. Програмер ће морати да подигне пуноправни сервер или да исправи код пре тестирања. Извлачење конфигурације из кода решава проблем: тестови користе тест параметре, продукција – продукцијске, а код се притом не мења.

Када је хардкод оправдан: изузеци од правила

Хардкод је анти-образац, али постоје легитимни изузеци када је чврсто уписана вредност не само дозвољена већ и пожељна. Граница пролази дуж осе променљивости: ако се вредност никада или готово никада не мења у животном циклусу апликације, може се хардкодовати. Ако се макар потенцијално може променити – извуците у конфигурацију.

Математичке и физичке константе – број Пи, убрзање гравитације, број милисекунди у секунди – безбедне су за хардкод. Оне су дефинисане природом или стандардима и неће се променити. Величине константних низова дефинисане спецификацијом такође се могу чврсто фиксирати, али са коментаром о пореклу броја.

Пример оправданог хардкода

Број милисекунди у секунди је стабилна константа дефинисана временским стандардом. Нема смисла извлачити је у конфиг, јер се никада неће променити. Међутим, чак и такве константе је боље декларисати са разумљивим именом, како код не би садржао „магичне бројеве“: уместо 1000 пишите MILLISECONDS_IN_SECOND.

// Оправдан хардкод: стабилне константе
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."
}

Алтернативе хардкоду: конфиги, ENV, DI

Постоји неколико проверених начина да се избегне хардкод, од којих је сваки погодан за свој тип вредности. Избор алтернативе зависи од тога колико често се вредност мења и ко је мења: програмер, devops или крајњи корисник.

Конфигурациони фајлови

За УРЛ-ове сервера, АПИ кључеве и feature-флагове користите конфигурационе фајлове у форматима JSON, YAML или TOML. На Android-у је то build.gradle са buildConfigField или res/values/config.xml. На iOS-у – Info.plist или xcconfig. Конфигови се компајлирају заједно са апликацијом, али могу бити различити за различите шеме изградње.

Променљиве окружења

За тајне (токени, лозинке) и параметре окружења користите променљиве окружења. Оне не доспевају у репозиторијум и могу се разликовати на dev, stage и prod серверима. У мобилном развоју променљиве окружења се често емулирају кроз Xcode шеме изградње или build flavor-е у Gradle-у.

Ресурси апликације

Стрингови, боје, величине, слике треба да буду извучени у ресурсне фајлове: strings.xml на Android-у, Localizable.strings на iOS-у, ARB фајлове у Flutter-у. То олакшава локализацију, прилагођавање различитим екранима и тамној теми. Промена стринга у ресурсима не захтева преписивање кода.

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

Убризгавање зависности (DI)

За сервисе и провајдере користите Dependency Injection путем Dagger, Hilt или Koin на Android-у, Swinject на iOS-у. DI оквири омогућавају замену имплементација у лету – за тестове, за различита окружења, за различите кориснике. Ово је највиши ниво апстракције, где се „прикованост“ вредности замењује убризгавањем споља.

Како рефакторисати хардкодовани код

Рефакторисање хардкода је процес извлачења чврсто уписаних вредности у конфигурацију или ресурсе. Ово је једна од најсигурнијих операција рефакторисања, ако се изводи методично. Описана секвенца испод је погодна за било који језик и платформу.

Корак 1: пронађи све магичне бројеве и стрингове

Претрага се може обавити кроз IDE (Search in Project) или скриптом. Тражите стрингове, УРЛ-ове, нумеричке литерале, величине, тајмауте. Посебну пажњу обратите на понављајуће вредности: ако се исти број појављује на пет места, то је кандидат за извлачење у константу. Користите grep или уграђену претрагу IDEA / Xcode.

Корак 2: замени именованим константама

За сваку пронађену вредност креирајте константу са смисленим именом. Групишите константе по модулима или класама. Име треба да објасни шта вредност значи, а не како се користи: API_TIMEOUT, а не TIMEOUT_30. Након замене ниједан број у коду не сме остати без објашњења.

// Пре: магични број 0.4
let cardHeight = screenHeight * 0.4

// После: именована константа
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Корак 3: извуци у конфигурацију или ресурсе

Ако се вредност може мењати између изградњи или окружења – извуците је у конфигурациони фајл или ресурсе апликације. За стрингове користите фајлове локализације. За УРЛ-ове – build config или xcconfig. За величине – ресурсне фајлове (dimens.xml на Android-у). Проверите да се апликација компајлира и ради исправно након извлачења.

Корак 4: напиши тест

Након рефакторисања напишите тест који проверава да се конфигурација учитава исправно и вредности одговарају очекиваним. Ако у будућности неко промени конфиг, тест ће указати на неслагање. Тест конфигурације је брз и поуздан начин да се спречи регресија.

Корак 5: уклони дупликате

Након извлачења у конфиг проверите да сва места где се користила стара вредност упућују на јединствени извор. Уклоните коментарисани код и старе константе које се више не користе. Финализујте рефакторисање комитом са поруком која описује које вредности и где су извучене.