Hardcode dalam pengembangan: apa itu, risiko dan cara menghindari

Apa arti “dipaku” dan “hardcode”

Hardcode (dipaku) – menanamkan nilai tertentu ke dalam kode program sehingga untuk mengubahnya diperlukan pengeditan kode sumber dan kompilasi ulang aplikasi. Metafora “dipaku” dengan tepat mencerminkan esensi: nilai terpaku erat dan dapat dilepaskan dari kode hanya dengan usaha.

Contoh hardcode – URL server yang ditulis sebagai string langsung di dalam body fungsi. Jika server pindah ke alamat lain, pengembang harus menemukan string dalam kode, mengubahnya, membangun ulang aplikasi, dan merilis versi baru. Dalam aplikasi dengan arsitektur yang benar, URL seperti itu akan dipindahkan ke file konfigurasi, variable lingkungan, atau layanan konfigurasi.

Istilah “dipaku” memiliki nuansa lebih emosional: menekankan bahwa nilai ditanamkan secara kaku tanpa kemungkinan penggantian cepat. Di lingkungan berbahasa Indonesia, kedua ungkapan digunakan sebagai sinonim penuh dengan konotasi negatif. Terkadang hardcode secara ironis disebut “konstanta yang dipindahkan ke konstanta terpisah dari konstanta”.

Mengapa hardcode dianggap anti-pattern

Hardcode adalah anti-pattern karena melanggar prinsip pemeliharaan, pengujian, dan perluasan kode. Dalam kode di mana nilai “dipaku”, setiap perubahan lingkungan, desain, atau logika memerlukan pencarian dan penggantian manual di sumber. Ini meningkatkan risiko kesalahan dan memperlambat pengembangan.

Mari kita lihat konsekuensi konkret hardcode pada contoh aplikasi mobile tipikal. Jika jarak semua tombol ditentukan oleh angka dalam kode, bukan melalui sumber daya – perubahan desain akan memerlukan pencarian semua kemunculan dan penggantian. Jika URL endpoint ditulis secara kaku – perpindahan antar lingkungan (dev, stage, prod) tidak mungkin tanpa kompilasi ulang.

Contoh hardcode buruk

Fungsi yang menggunakan angka ajaib dan string yang ditulis secara kaku adalah contoh klasik hardcode. Setelah sebulan, penulis tidak akan ingat apa arti 18, 0.07, dan 2.5. Setelah setahun – tidak ada satu pun di tim yang berani mengubah angka-angka ini karena takut merusak logika. Memindahkan nilai ke konstanta bernama membuat kode menjadi self-documenting.

// Buruk: angka ajaib dan string
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
}

Dampak pada pengujian

URL database yang dihardcode tidak akan mengizinkan menjalankan tes pada database in-memory lokal. Pengembang harus menyiapkan server lengkap atau memperbaiki kode sebelum pengujian. Memindahkan konfigurasi dari kode memecahkan masalah: tes menggunakan parameter pengujian, produksi menggunakan parameter nyata, dan kode tidak berubah.

Kapan hardcode dibenarkan: pengecualian dari aturan

Hardcode adalah anti-pattern, tetapi ada pengecualian yang sah di mana nilai yang ditulis secara kaku tidak hanya diperbolehkan tetapi juga lebih disukai. Batasnya berjalan di sepanjang sumbu variabilitas: jika nilai tidak pernah atau hampir tidak pernah berubah dalam siklus hidup aplikasi, nilai tersebut dapat dihardcode. Jika setidaknya berpotensi dapat berubah – pindahkan ke konfigurasi.

Konstanta matematika dan fisika – angka Pi, percepatan gravitasi, jumlah milidetik dalam satu detik – aman untuk dihardcode. Mereka ditentukan oleh alam atau standar dan tidak akan berubah. Ukuran array konstanta yang ditentukan oleh spesifikasi juga dapat ditetapkan secara kaku, tetapi dengan komentar tentang asal angka tersebut.

Contoh hardcode yang dibenarkan

Jumlah milidetik dalam satu detik adalah konstanta stabil yang ditentukan oleh standar waktu. Tidak ada gunanya memindahkannya ke konfig, karena tidak akan pernah berubah. Namun, bahkan konstanta semacam itu sebaiknya dideklarasikan dengan nama yang dapat dipahami, sehingga kode tidak mengandung “angka ajaib”: alih-alih 1000, tulis MILLISECONDS_IN_SECOND.

// Hardcode dibenarkan: konstanta stabil
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."
}

Alternatif hardcode: konfig, ENV, DI

Ada beberapa cara yang terbukti untuk menghindari hardcode, masing-masing cocok untuk jenis nilai tertentu. Pemilihan alternatif tergantung pada seberapa sering nilai berubah dan siapa yang mengubahnya: pengembang, devops, atau pengguna akhir.

File konfigurasi

Untuk URL server, kunci API, dan feature flag, gunakan file konfigurasi dalam format JSON, YAML, atau TOML. Di Android ini adalah build.gradle dengan buildConfigField atau res/values/config.xml. Di iOS – Info.plist atau xcconfig. Konfigurasi dibangun bersama aplikasi tetapi dapat berbeda untuk skema build yang berbeda.

Variable lingkungan

Untuk rahasia (token, kata sandi) dan parameter lingkungan, gunakan variable lingkungan. Mereka tidak masuk ke repositori dan dapat berbeda di server dev, stage, dan prod. Dalam pengembangan mobile, variable lingkungan sering disimulasikan melalui skema build Xcode atau build flavor di Gradle.

Sumber daya aplikasi

String, warna, ukuran, gambar harus dipindahkan ke file sumber daya: strings.xml di Android, Localizable.strings di iOS, file ARB di Flutter. Ini menyederhanakan lokalisasi, adaptasi ke layar berbeda, dan mode gelap. Mengubah string di sumber daya tidak memerlukan penulisan ulang kode.

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

Dependency Injection (DI)

Untuk layanan dan penyedia, gunakan Dependency Injection melalui Dagger, Hilt, atau Koin di Android, Swinject di iOS. Framework DI memungkinkan penggantian implementasi secara langsung – untuk pengujian, untuk lingkungan berbeda, untuk pengguna berbeda. Ini adalah tingkat abstraksi tertinggi, di mana “pemakuan” nilai digantikan oleh injeksi dari luar.

Cara refactor kode yang dihardcode

Refactoring hardcode adalah proses memindahkan nilai yang ditulis secara kaku ke konfigurasi atau sumber daya. Ini adalah salah satu operasi refactoring paling aman, jika dilakukan secara metodis. Urutan yang dijelaskan di bawah ini cocok untuk bahasa dan platform apa pun.

Langkah 1: temukan semua angka ajaib dan string

Pencarian dapat dilakukan melalui IDE (Search in Project) atau dengan skrip. Cari string, URL, literal numerik, ukuran, batas waktu. Perhatian khusus pada nilai yang berulang: jika angka yang sama muncul di lima tempat, itu adalah kandidat untuk dipindahkan ke konstanta. Gunakan grep atau pencarian bawaan IDEA / Xcode.

Langkah 2: ganti dengan konstanta bernama

Untuk setiap nilai yang ditemukan, buat konstanta dengan nama yang bermakna. Kelompokkan konstanta berdasarkan modul atau kelas. Nama harus menjelaskan apa arti nilai tersebut, bukan bagaimana ia digunakan: API_TIMEOUT, bukan TIMEOUT_30. Setelah penggantian, tidak ada angka dalam kode yang boleh tetap tanpa penjelasan.

// Sebelum: angka ajaib 0.4
let cardHeight = screenHeight * 0.4

// Sesudah: konstanta bernama
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Langkah 3: pindahkan ke konfigurasi atau sumber daya

Jika nilai dapat berubah antar build atau lingkungan – pindahkan ke file konfigurasi atau sumber daya aplikasi. Untuk string, gunakan file lokalisasi. Untuk URL – build config atau xcconfig. Untuk ukuran – file sumber daya (dimens.xml di Android). Periksa bahwa aplikasi dapat dikompilasi dan berfungsi dengan benar setelah pemindahan.

Langkah 4: tulis tes

Setelah refactoring, tulis tes yang memeriksa bahwa konfigurasi dimuat dengan benar dan nilai sesuai dengan yang diharapkan. Jika di masa depan seseorang mengubah konfig, tes akan menunjukkan ketidaksesuaian. Tes konfigurasi adalah cara cepat dan andal untuk mencegah regresi.

Langkah 5: hapus duplikat

Setelah dipindahkan ke konfig, periksa bahwa semua tempat di mana nilai lama digunakan merujuk ke sumber tunggal. Hapus kode yang dikomentari dan konstanta lama yang tidak lagi digunakan. Akhiri refactoring dengan commit yang mendeskripsikan nilai apa dan ke mana telah dipindahkan.