Hardcode ve vývoji: co to je, rizika a jak se vyhnout

Co znamená „přibít hřebíky“ a „hardcode“

Hardcode (přibít hřebíky) – vložit konkrétní hodnotu do kódu programu tak, že pro její změnu je třeba upravit zdrojový kód a znovu zkompilovat aplikaci. Metafora „přibít hřebíky“ přesně odráží podstatu: hodnota je pevně fixovaná a lze ji od kódu oddělit pouze s námahou.

Příklad hardcode – URL serveru zapsané jako řetězec přímo v těle funkce. Pokud se server přesune na jinou adresu, vývojář musí najít řetězec v kódu, změnit jej, znovu sestavit aplikaci a vydat novou verzi. V aplikaci se správnou architekturou by takové URL bylo přesunuto do konfiguračního souboru, proměnné prostředí nebo konfigurační služby.

Termín „přibít hřebíky“ má emocionálnější nádech: zdůrazňuje, že hodnota je vložena pevně a bez možnosti rychlé výměny. V českém prostředí se oba výrazy používají jako úplná synonyma s negativní konotací. Někdy se hardcode ironicky nazývá „konstanta přesunutá do samostatné konstanty z konstanty“.

Proč je hardcode považován za anti-vzor

Hardcode je anti-vzor, protože porušuje principy udržovatelnosti, testovatelnosti a rozšiřitelnosti kódu. V kódu, kde jsou hodnoty „přibité hřebíky“, každá změna prostředí, designu nebo logiky vyžaduje ruční vyhledávání a nahrazování ve zdrojích. To zvyšuje riziko chyb a zpomaluje vývoj.

Podívejme se na konkrétní důsledky hardcode na příkladu typické mobilní aplikace. Pokud je mezera všech tlačítek dána číslem v kódu, nikoli prostřednictvím zdroje – změna designu bude vyžadovat nalezení všech výskytů a jejich nahrazení. Pokud je URL endpointu pevně zapsáno – přepínání mezi prostředími (dev, stage, prod) není možné bez překompilování.

Příklad špatného hardcode

Funkce, která používá magická čísla a pevně zapsané řetězce, je klasikou hardcode. Po měsíci si autor nebude pamatovat, co znamená 18, 0.07 a 2.5. Po roce – nikdo v týmu se neodváží tato čísla měnit, ze strachu, že zlomí logiku. Přesunutí hodnot do pojmenovaných konstant činí kód samodokumentující.

// Špatně: magická čísla a řetězce
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
}

Dopad na testování

Hardcode URL databáze neumožní spouštět testy na lokální in-memory databázi. Vývojář bude muset spustit plnohodnotný server nebo upravit kód před testováním. Přesunutí konfigurace z kódu řeší problém: testy používají testovací parametry, produkce produkční parametry a kód se přitom nemění.

Kdy je hardcode oprávněný: výjimky z pravidla

Hardcode je anti-vzor, ale existují legitimní výjimky, kdy pevně zapsaná hodnota není jen povolena, ale je preferována. Hranice prochází podél osy proměnlivosti: pokud se hodnota nikdy nebo téměř nikdy nemění během životního cyklu aplikace, lze ji hardcode. Pokud se alespoň potenciálně může změnit – přesuňte do konfigurace.

Matematické a fyzikální konstanty – číslo Pí, gravitační zrychlení, počet milisekund v sekundě – jsou pro hardcode bezpečné. Jsou definovány přírodou nebo standardy a nezmění se. Velikosti konstantních polí definované specifikací lze také pevně fixovat, ale s komentářem o původu čísla.

Příklad oprávněného hardcode

Počet milisekund v sekundě je stabilní konstanta definovaná časovým standardem. Nemá smysl ji přesouvat do konfigu, protože se nikdy nezmění. Nicméně i takové konstanty je lepší deklarovat s pochopitelným názvem, aby kód neobsahoval „magická čísla“: místo 1000 napište MILLISECONDS_IN_SECOND.

// Oprávněný hardcode: stabilní konstanty
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."
}

Alternativy k hardcode: konfigy, ENV, DI

Existuje několik osvědčených způsobů, jak se vyhnout hardcode, z nichž každý je vhodný pro svůj typ hodnot. Výběr alternativy závisí na tom, jak často se hodnota mění a kdo ji mění: vývojář, devops nebo koncový uživatel.

Konfigurační soubory

Pro URL serverů, API klíče a feature flagy používejte konfigurační soubory ve formátech JSON, YAML nebo TOML. Na Androidu je to build.gradle s buildConfigField nebo res/values/config.xml. Na iOS – Info.plist nebo xcconfig. Konfigy se sestavují spolu s aplikací, ale mohou být různé pro různá schémata sestavení.

Proměnné prostředí

Pro tajemství (tokeny, hesla) a parametry prostředí používejte proměnné prostředí. Ty se nedostanou do repozitáře a mohou se lišit na dev, stage a prod serverech. V mobilním vývoji se proměnné prostředí často emulují pomocí Xcode schémat sestavení nebo build flavorů v Gradlu.

Zdroje aplikace

Řetězce, barvy, velikosti, obrázky by měly být přesunuty do souborů zdrojů: strings.xml na Androidu, Localizable.strings na iOS, ARB soubory ve Flutteru. To zjednodušuje lokalizaci, přizpůsobení různým obrazovkám a tmavému režimu. Změna řetězce ve zdrojích nevyžaduje přepisování kódu.

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

Vkládání závislostí (DI)

Pro služby a poskytovatele používejte Dependency Injection přes Dagger, Hilt nebo Koin na Androidu, Swinject na iOS. DI frameworky umožňují výměnu implementací za běhu – pro testy, pro různá prostředí, pro různé uživatele. To je nejvyšší úroveň abstrakce, kde je „přibití“ hodnoty nahrazeno vkládáním zvenčí.

Jak refaktorovat hardcode kód

Refaktorování hardcode je proces přesouvání pevně zapsaných hodnot do konfigurace nebo zdrojů. Je to jedna z nejbezpečnějších refaktorovacích operací, pokud se provádí metodicky. Níže popsaná sekvence je vhodná pro jakýkoli jazyk a platformu.

Krok 1: najděte všechna magická čísla a řetězce

Vyhledávání lze provést pomocí IDE (Search in Project) nebo skriptem. Hledejte řetězce, URL, číselné literály, velikosti, časové limity. Zvláštní pozornost věnujte opakujícím se hodnotám: pokud se stejné číslo objevuje na pěti místech, je to kandidát na přesun do konstanty. Použijte grep nebo vestavěné vyhledávání IDEA / Xcode.

Krok 2: nahraďte pojmenovanými konstantami

Pro každou nalezenou hodnotu vytvořte konstantu s výstižným názvem. Seskupte konstanty podle modulů nebo tříd. Název by měl vysvětlovat, co hodnota znamená, ne jak se používá: API_TIMEOUT, ne TIMEOUT_30. Po nahrazení by žádné číslo v kódu nemělo zůstat bez vysvětlení.

// Před: magické číslo 0.4
let cardHeight = screenHeight * 0.4

// Po: pojmenovaná konstanta
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Krok 3: přesuňte do konfigurace nebo zdrojů

Pokud se hodnota může měnit mezi sestaveními nebo prostředími – přesuňte ji do konfiguračního souboru nebo zdrojů aplikace. Pro řetězce používejte lokalizační soubory. Pro URL – build config nebo xcconfig. Pro velikosti – soubory zdrojů (dimens.xml na Androidu). Zkontrolujte, že se aplikace po přesunutí správně sestavuje a funguje.

Krok 4: napište test

Po refaktorování napište test, který kontroluje, že se konfigurace načítá správně a hodnoty odpovídají očekávaným. Pokud v budoucnu někdo změní konfig, test upozorní na nesoulad. Test konfigurace je rychlý a spolehlivý způsob, jak zabránit regresi.

Krok 5: odstraňte duplikáty

Po přesunutí do konfigu zkontrolujte, že všechna místa, kde se používala stará hodnota, odkazují na jednotný zdroj. Odstraňte zakomentovaný kód a staré konstanty, které se již nepoužívají. Dokončete refaktorování commitem se zprávou popisující, jaké hodnoty a kam byly přesunuty.