Hardcode sa pag-develop: ano ito, mga panganib at paano maiiwasan

Ano ang ibig sabihin ng “ipinako” at “hardcode”

Mag-hardcode (ipinako) – isama ang isang partikular na value sa code ng programa sa paraang para mabago ito, kailangan i-edit ang source code at i-recompile ang application. Ang metapora na “ipinako” ay tumpak na sumasalamin sa esensya: ang value ay mahigpit na nakaayos at maaari lamang mahiwalay sa code nang may pagsisikap.

Halimbawa ng hardcode – URL ng server na isinulat bilang string nang direkta sa body ng function. Kung lumipat ang server sa ibang address, kailangan ng developer na hanapin ang string sa code, baguhin ito, muling buuin ang application, at mag-release. Sa isang application na may tamang arkitektura, ang naturang URL ay ililipat sa configuration file, environment variable, o configuration service.

Ang terminong “ipinako” ay may mas emosyonal na konotasyon: binibigyang-diin nito na ang value ay nakapasok nang mahigpit at walang posibilidad ng mabilisang pagpapalit. Sa kapaligirang nagsasalita ng Filipino, ang parehong mga expression ay ginagamit bilang kumpletong kasingkahulugan na may negatibong konotasyon. Minsan ang hardcode ay ironically tinatawag na “constant na inilipat sa isang hiwalay na constant mula sa isang constant”.

Bakit itinuturing na anti-pattern ang hardcode

Hardcode ay isang anti-pattern dahil lumalabag ito sa mga prinsipyo ng maintainability, testability, at extensibility ng code. Sa code kung saan ang mga value ay “ipinako”, ang anumang pagbabago sa kapaligiran, disenyo, o lohika ay nangangailangan ng manu-manong paghahanap at pagpapalit sa mga source. Pinapataas nito ang panganib ng mga error at pinapabagal ang pag-develop.

Tingnan natin ang mga tiyak na kahihinatnan ng hardcode sa halimbawa ng isang tipikal na mobile application. Kung ang spacing ng lahat ng button ay itinakda ng isang numero sa code, hindi sa pamamagitan ng resource – ang pagbabago sa disenyo ay mangangailangan ng paghahanap ng lahat ng occurrence at pagpapalit. Kung ang endpoint URL ay mahigpit na nakasulat – ang paglipat sa pagitan ng mga kapaligiran (dev, stage, prod) ay imposible nang walang recompilation.

Halimbawa ng masamang hardcode

Ang function na gumagamit ng magic numbers at mahigpit na nakasulat na mga string ay klasikong halimbawa ng hardcode. Pagkatapos ng isang buwan, hindi maaalala ng may-akda kung ano ang kahulugan ng 18, 0.07, at 2.5. Pagkatapos ng isang taon – walang sinuman sa koponan ang maglalakas-loob na baguhin ang mga numerong ito dahil sa takot na masira ang lohika. Ang paglipat ng mga value sa named constants ay ginagawang self-documenting ang code.

// Masama: magic numbers at 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
}

Epekto sa pag-test

Ang naka-hardcode na URL ng database ay hindi papayag na magpatakbo ng mga test sa isang lokal na in-memory database. Kailangan ng developer na mag-set up ng isang buong server o ayusin ang code bago mag-test. Ang paglipat ng configuration mula sa code ay nireresolba ang problema: ang mga test ay gumagamit ng test parameters, ang production ay gumagamit ng real parameters, at ang code ay hindi nagbabago.

Kailan makatwiran ang hardcode: mga exception sa panuntunan

Ang hardcode ay isang anti-pattern, ngunit may mga lehitimong exception kung saan ang isang mahigpit na nakasulat na value ay hindi lamang pinapayagan, ngunit mas gusto. Ang hangganan ay tumatakbo sa axis ng variability: kung ang value ay hindi kailanman o halos hindi nagbabago sa lifecycle ng application, maaari itong i-hardcode. Kung hindi bababa sa potensyal na maaaring magbago – ilipat sa configuration.

Mathematical at physical constants – Pi, acceleration ng gravity, bilang ng milliseconds sa isang segundo – ay ligtas para sa hardcode. Ang mga ito ay tinukoy ng kalikasan o mga pamantayan at hindi magbabago. Mga laki ng constant arrays na tinukoy ng specification ay maaari ding mahigpit na itakda, ngunit may komento tungkol sa pinagmulan ng numero.

Halimbawa ng makatwirang hardcode

Ang bilang ng milliseconds sa isang segundo ay isang stable na constant na tinukoy ng time standard. Walang saysay na ilipat ito sa config, dahil hindi ito magbabago kailanman. Gayunpaman, kahit na ang mga naturang constant ay mas mainam na ideklara na may naiintindihang pangalan, upang ang code ay hindi naglalaman ng “magic numbers”: sa halip na 1000, isulat ang MILLISECONDS_IN_SECOND.

// Makatwirang hardcode: stable constants
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."
}

Mga alternatibo sa hardcode: configs, ENV, DI

May ilang napatunayang paraan upang maiwasan ang hardcode, bawat isa ay angkop para sa partikular na uri ng value. Ang pagpili ng alternatibo ay depende sa kung gaano kadalas nagbabago ang value at kung sino ang nagbabago nito: developer, devops, o end user.

Configuration file

Para sa mga URL ng server, API key, at feature flag, gumamit ng configuration file sa format na JSON, YAML, o TOML. Sa Android ito ay build.gradle na may buildConfigField o res/values/config.xml. Sa iOS – Info.plist o xcconfig. Ang mga config ay binuo kasama ng application, ngunit maaaring magkaiba para sa iba’t ibang build scheme.

Environment variables

Para sa mga sikreto (token, password) at mga parameter ng kapaligiran, gumamit ng environment variables. Hindi sila napupunta sa repository at maaaring magkaiba sa dev, stage, at prod server. Sa mobile development, ang environment variables ay madalas na ginagaya sa pamamagitan ng Xcode build scheme o build flavors sa Gradle.

Resources ng application

Ang mga string, kulay, laki, larawan ay dapat ilipat sa resource file: strings.xml sa Android, Localizable.strings sa iOS, ARB file sa Flutter. Pinapasimple nito ang lokalisasyon, pag-adapt sa iba’t ibang screen, at dark mode. Ang pagpapalit ng string sa resources ay hindi nangangailangan ng muling pagsulat ng code.

<!-- 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)

Para sa mga serbisyo at provider, gumamit ng Dependency Injection sa pamamagitan ng Dagger, Hilt, o Koin sa Android, Swinject sa iOS. Ang mga DI framework ay nagpapahintulot na palitan ang mga implementasyon on the fly – para sa mga test, para sa iba’t ibang kapaligiran, para sa iba’t ibang user. Ito ang pinakamataas na antas ng abstraction, kung saan ang “pagpapako” ng value ay pinapalitan ng injection mula sa labas.

Paano i-refactor ang naka-hardcode na code

Pag-refactor ng hardcode ay ang proseso ng paglipat ng mahigpit na nakasulat na mga value sa configuration o resources. Ito ay isa sa pinakaligtas na operasyon ng refactoring, kung gagawin nang methodically. Ang sequence na inilarawan sa ibaba ay angkop para sa anumang wika at platform.

Hakbang 1: hanapin ang lahat ng magic numbers at string

Ang paghahanap ay maaaring gawin sa pamamagitan ng IDE (Search in Project) o script. Hanapin ang mga string, URL, numeric literals, laki, timeout. Espesyal na atensyon sa mga paulit-ulit na value: kung ang parehong numero ay lumitaw sa limang lugar, ito ay isang kandidato para ilipat sa isang constant. Gumamit ng grep o built-in na paghahanap ng IDEA / Xcode.

Hakbang 2: palitan ng named constants

Para sa bawat nahanap na value, lumikha ng constant na may makabuluhang pangalan. Igrupo ang mga constant ayon sa module o klase. Ang pangalan ay dapat ipaliwanag kung ano ang ibig sabihin ng value, hindi kung paano ito ginagamit: API_TIMEOUT, hindi TIMEOUT_30. Pagkatapos ng pagpapalit, walang numero sa code ang dapat manatiling walang paliwanag.

// Bago: magic number 0.4
let cardHeight = screenHeight * 0.4

// Pagkatapos: named constant
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

Hakbang 3: ilipat sa configuration o resources

Kung ang value ay maaaring magbago sa pagitan ng mga build o kapaligiran – ilipat ito sa configuration file o resources ng application. Para sa mga string, gumamit ng localization file. Para sa URL – build config o xcconfig. Para sa laki – resource file (dimens.xml sa Android). Tiyakin na ang application ay nagco-compile at gumagana nang tama pagkatapos ng paglipat.

Hakbang 4: magsulat ng test

Pagkatapos ng refactoring, magsulat ng test na nagsusuri na ang configuration ay na-load nang tama at ang mga value ay tumutugma sa inaasahan. Kung sa hinaharap ay may magbago ng config, ituturo ng test ang pagkakaiba. Ang configuration test ay isang mabilis at maaasahang paraan upang maiwasan ang regression.

Hakbang 5: alisin ang mga duplicate

Pagkatapos ilipat sa config, tiyakin na ang lahat ng lugar kung saan ginamit ang lumang value ay tumutukoy sa iisang source. Alisin ang naka-comment na code at mga lumang constant na hindi na ginagamit. Tapusin ang refactoring gamit ang isang commit na may mensaheng naglalarawan kung anong mga value at saan inilipat.