डेवलपमेंट में हार्डकोड: यह क्या है, जोखिम और कैसे बचें

“कील से ठोकना” और “हार्डकोड” का क्या अर्थ है

हार्डकोड (कील से ठोकना) — प्रोग्राम कोड में एक विशिष्ट मान इस प्रकार एम्बेड करना कि उसे बदलने के लिए स्रोत कोड को संपादित करना और एप्लिकेशन को पुनः संकलित करना आवश्यक हो। “कील से ठोकना” रूपक सार को सटीक रूप से दर्शाता है: मान स्थायी रूप से फिक्स होता है, और इसे कोड से केवल प्रयास से अलग किया जा सकता है।

हार्डकोड का एक उदाहरण — सर्वर URL जो सीधे फ़ंक्शन बॉडी में एक स्ट्रिंग के रूप में लिखा गया है। यदि सर्वर किसी दूसरे पते पर जाता है, तो डेवलपर को कोड में स्ट्रिंग ढूंढनी होगी, उसे बदलना होगा, एप्लिकेशन को फिर से बनाना होगा और रिलीज़ जारी करनी होगी। सही आर्किटेक्चर वाले एप्लिकेशन में, ऐसा URL कॉन्फ़िगरेशन फ़ाइल, एनवायरनमेंट वेरिएबल या कॉन्फ़िगरेशन सेवा में रखा जाएगा।

“कील से ठोकना” शब्द अधिक भावनात्मक रूप से चार्ज है: यह इस बात पर जोर देता है कि मान स्थायी रूप से डाला गया है और त्वरित प्रतिस्थापन की कोई संभावना नहीं है। रूसी भाषी समुदाय में, दोनों अभिव्यक्तियाँ नकारात्मक अर्थ के साथ पूर्ण पर्यायवाची के रूप में उपयोग की जाती हैं। कभी-कभी हार्डकोड को विडंबनापूर्ण रूप से “एक स्थिरांक से एक अलग स्थिरांक में निकाला गया स्थिरांक” कहा जाता है।

हार्डकोड को एंटी-पैटर्न क्यों माना जाता है

हार्डकोड एक एंटी-पैटर्न है क्योंकि यह रखरखाव, परीक्षण और विस्तारशीलता के सिद्धांतों का उल्लंघन करता है। ऐसे कोड में जहां मान “कील से ठोके गए” हैं, वातावरण, डिज़ाइन या तर्क में किसी भी बदलाव के लिए स्रोत कोड में मैन्युअल खोज और प्रतिस्थापन की आवश्यकता होती है। इससे त्रुटियों का खतरा बढ़ जाता है और विकास धीमा हो जाता है।

आइए एक सामान्य मोबाइल एप्लिकेशन के उदाहरण पर हार्डकोड के विशिष्ट परिणामों की जांच करें। यदि सभी बटनों का मार्जिन संसाधन के बजाय कोड में एक संख्या के रूप में सेट किया गया है, तो डिज़ाइन बदलने के लिए सभी घटनाओं को खोजने और बदलने की आवश्यकता होगी। यदि एंडपॉइंट URL हार्डकोडेड है, तो वातावरण (dev, stage, prod) के बीच स्विच करना पुनर्निर्माण के बिना असंभव है।

खराब हार्डकोड का उदाहरण

एक फ़ंक्शन जो मैजिक नंबर और हार्डकोडेड स्ट्रिंग का उपयोग करता है — हार्डकोड का क्लासिक उदाहरण। एक महीने बाद, लेखक को याद नहीं रहेगा कि 18, 0.07 और 2.5 का क्या अर्थ है। एक साल बाद, टीम में कोई भी तर्क को तोड़ने के डर से इन नंबरों को बदलने की हिम्मत नहीं करेगा। मानों को नामित कॉन्स्टेंट में निकालना कोड को स्व-दस्तावेजी बनाता है।

// Bad: magic numbers and strings
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
}

परीक्षण पर प्रभाव

हार्डकोडेड डेटाबेस URL स्थानीय इन-मेमोरी डेटाबेस पर परीक्षण चलाने की अनुमति नहीं देगा। डेवलपर को परीक्षण से पहले एक पूर्ण सर्वर चालू करना होगा या कोड को संशोधित करना होगा। कोड से कॉन्फ़िगरेशन निकालना समस्या का समाधान करता है: परीक्षण परीक्षण पारामीटर का उपयोग करते हैं, उत्पादन वास्तविक का उपयोग करता है, और कोड अपरिवर्तित रहता है।

हार्डकोड कब उचित है: अपवाद

हार्डकोड एक एंटी-पैटर्न है, लेकिन वैध अपवाद मौजूद हैं जहाँ हार्डकोडेड मान न केवल स्वीकार्य है बल्कि बेहतर भी है। सीमा परिवर्तनशीलता की धुरी पर चलती है: यदि कोई मान एप्लिकेशन के जीवनचक्र में कभी या लगभग कभी नहीं बदलता है, तो इसे हार्डकोड किया जा सकता है। यदि यह संभावित रूप से बदल सकता है, तो इसे कॉन्फ़िगरेशन में ले जाएँ।

गणितीय और भौतिक स्थिरांक — पाई, गुरुत्वाकर्षण त्वरण, एक सेकंड में मिलीसेकंड की संख्या — हार्डकोड के लिए सुरक्षित हैं। वे प्रकृति या मानकों द्वारा परिभाषित हैं और बदलेंगे नहीं। स्थिरांक ऐरे के आकार जो विनिर्देश द्वारा परिभाषित हैं, हार्डकोड किए जा सकते हैं, लेकिन संख्या की उत्पत्ति के बारे में टिप्पणी के साथ।

उचित हार्डकोड का उदाहरण

एक सेकंड में मिलीसेकंड की संख्या समय मानक द्वारा परिभाषित एक स्थिर स्थिरांक है। इसे कॉन्फ़िग में ले जाने का कोई मतलब नहीं है क्योंकि यह कभी नहीं बदलेगा। हालाँकि, ऐसे स्थिरांकों को भी एक स्पष्ट नाम के साथ घोषित करना बेहतर है ताकि कोड में “जादुई संख्याएँ” न हों: 1000 के बजाय MILLISECONDS_IN_SECOND लिखें।

// Justified 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."
}

हार्डकोड के विकल्प: कॉन्फ़िग, ENV, DI

हार्डकोड से बचने के कई सिद्ध तरीके मौजूद हैं, प्रत्येक अपने प्रकार के मानों के लिए उपयुक्त है। विकल्प का चुनाव इस बात पर निर्भर करता है कि मान कितनी बार बदलता है और इसे कौन बदलता है: डेवलपर, डेवऑप्स, या अंतिम उपयोगकर्ता।

कॉन्फ़िगरेशन फ़ाइलें

सर्वर URL, API कुंजियाँ और फीचर फ़्लैग के लिए, JSON, YAML या TOML प्रारूपों में कॉन्फ़िगरेशन फ़ाइलों का उपयोग करें। Android में, इसमें buildConfigField के साथ build.gradle या res/values/config.xml शामिल है। iOS में, Info.plist या xcconfig। कॉन्फ़िग एप्लिकेशन के साथ बंडल होते हैं लेकिन विभिन्न बिल्ड स्कीम के लिए भिन्न हो सकते हैं।

एनवायरनमेंट वेरिएबल्स

गुप्त जानकारी (टोकन, पासवर्ड) और एनवायरनमेंट पारामीटर के लिए, एनवायरनमेंट वेरिएबल्स का उपयोग करें। वे रिपॉजिटरी में नहीं जाते और dev, stage और prod सर्वरों पर भिन्न हो सकते हैं। मोबाइल डेवलपमेंट में, एनवायरनमेंट वेरिएबल्स को अक्सर Xcode बिल्ड स्कीम या Gradle बिल्ड फ़्लेवर के माध्यम से अनुकरण किया जाता है।

एप्लिकेशन संसाधन

स्ट्रिंग, रंग, आकार और चित्र संसाधन फ़ाइलों में रखे जाने चाहिए: Android में strings.xml, iOS में Localizable.strings, Flutter में ARB फ़ाइलें। यह स्थानीयकरण, विभिन्न स्क्रीन के अनुकूलन और डार्क मोड को सरल बनाता है। संसाधनों में स्ट्रिंग बदलने के लिए कोड फिर से लिखने की आवश्यकता नहीं होती।

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

डिपेंडेंसी इंजेक्शन (DI)

सेवाओं और प्रदाताओं के लिए, Android पर Dagger, Hilt या Koin, iOS पर Swinject के माध्यम से डिपेंडेंसी इंजेक्शन का उपयोग करें। DI फ्रेमवर्क परीक्षणों, विभिन्न वातावरणों या विभिन्न उपयोगकर्ताओं के लिए तुरंत कार्यान्वयन बदलने की अनुमति देते हैं। यह अमूर्तता का उच्चतम स्तर है, जहाँ मान का “कील से ठोकना” बाहरी इंजेक्शन द्वारा बदल दिया जाता है।

हार्डकोडेड कोड का रिफैक्टर कैसे करें

हार्डकोड का रिफैक्टरिंग — हार्ड-कोडेड मानों को कॉन्फ़िगरेशन या संसाधनों में निकालने की प्रक्रिया है। यदि विधिपूर्वक किया जाए तो यह सबसे सुरक्षित रिफैक्टरिंग ऑपरेशनों में से एक है। नीचे दिया गया क्रम किसी भी भाषा और प्लेटफ़ॉर्म के लिए काम करता है।

चरण 1: सभी जादुई संख्याएँ और स्ट्रिंग खोजें

खोज IDE (परियोजना में खोजें) या स्क्रिप्ट के माध्यम से की जा सकती है। स्ट्रिंग, URL, संख्यात्मक लिटरल, आकार और टाइमआउट खोजें। डुप्लिकेट मानों पर विशेष ध्यान दें: यदि वही संख्या पाँच स्थानों पर दिखाई देती है, तो यह कॉन्स्टेंट में निकालने के लिए उम्मीदवार है। grep या IDEA / Xcode की अंतर्निहित खोज का उपयोग करें।

चरण 2: नामित कॉन्स्टेंट से बदलें

प्रत्येक मिले मान के लिए, एक सार्थक नाम वाला कॉन्स्टेंट बनाएँ। कॉन्स्टेंट को मॉड्यूल या क्लास के अनुसार समूहित करें। नाम को यह समझाना चाहिए कि मान का क्या अर्थ है, न कि इसका उपयोग कैसे किया जाता है: TIMEOUT_30 नहीं, API_TIMEOUT। प्रतिस्थापन के बाद, कोड में कोई भी संख्या बिना स्पष्टीकरण के नहीं रहनी चाहिए।

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

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

चरण 3: कॉन्फ़िगरेशन या संसाधनों में ले जाएँ

यदि मान बिल्ड या वातावरण के बीच बदल सकता है, तो इसे कॉन्फ़िगरेशन फ़ाइल या एप्लिकेशन संसाधनों में ले जाएँ। स्ट्रिंग के लिए, स्थानीयकरण फ़ाइलों का उपयोग करें। URL के लिए, build config या xcconfig का उपयोग करें। आयामों के लिए, संसाधन फ़ाइलों (Android में dimens.xml) का उपयोग करें। सत्यापित करें कि निकालने के बाद एप्लिकेशन बिल्ड और सही ढंग से काम करता है।

चरण 4: एक परीक्षण लिखें

रिफैक्टरिंग के बाद, एक परीक्षण लिखें जो जाँच करे कि कॉन्फ़िगरेशन सही ढंग से लोड होता है और मान अपेक्षित के अनुरूप हैं। यदि भविष्य में कोई कॉन्फ़िग बदलता है, तो परीक्षण विसंगति को इंगित करेगा। कॉन्फ़िगरेशन परीक्षण प्रतिगमन को रोकने का एक तेज़ और विश्वसनीय तरीका है।

चरण 5: डुप्लिकेट हटाएँ

कॉन्फ़िग में ले जाने के बाद, सत्यापित करें कि पुराने मान का उपयोग करने वाले सभी स्थान अब एकल स्रोत का संदर्भ देते हैं। टिप्पणी किए गए कोड और पुराने कॉन्स्टेंट हटाएँ जो अब उपयोग नहीं किए जाते। एक कमिट संदेश के साथ रिफैक्टरिंग को अंतिम रूप दें जो बताता है कि कौन से मान कहाँ ले जाए गए।