ڈیویلپمنٹ میں ہارڈکوڈ: یہ کیا ہے، خطرات اور اس سے کیسے بچیں

«کیل سے ٹھونکنا» اور «ہارڈکوڈ کرنا» کا کیا مطلب ہے

ہارڈکوڈ کرنا (کیل سے ٹھونکنا) — پروگرام کوڈ میں ایک مخصوص قیمت اس طرح ضمن کرنا کہ اسے بدلنے کے لیے سورس کوڈ میں ترمیم اور ایپلیکیشن کو دبارہ ترتیب دینا ضروری ہے۔ «کیل سے ٹھونکنا» کا استعارہ حقیقت کو درست طرح ظاہر کرتا ہے: قیمت مستقل طرح مقرر ہے، اور اسے کوڈ سے علاحد کرنا صرف محنت سے ممکن ہے۔

ہارڈکوڈ کی مثال — ایک فنکشن کے بدن میں سیدھے ایک سٹرنگ کے طور پر لکھی گئی سرور URL۔ اگر سرور کسی دوسرے پتے پر چلا جاتا ہے، ڈیویلپر کو کوڈ میں سٹرنگ چھونکر اسے بدلنا ہوگا، ایپلیکیشن کو دبارہ بنانا ہوگا اور ریلیز جاری کرنا ہوگا۔ درست آرکیٹیکچر والی ایپلیکیشن میں ایسی URL ایک کنفگریشن فائل، انوارونمنٹ ویریابل یا کنفگریشن سروس میں رکھی گئی ہوتی۔

«کیل سے ٹھونکنا» کی اصطلاح زیاده جذباتی ہے: یہ اس بات پر زور دیتی ہے کہ قیمت مستقل طرح ڈالی گئی ہے اور تیزی سے بدلنے کا امکان نہیں ہے۔ روسی زبان کے ماحول میں، دونوں اظہار منفی مفہوم کے ساتھ مکمل مترادفات کے طور پر استعمال ہوتے ہیں۔ کبھی کبار ہارڈکوڈ کو طنزیا کے طور پر «کنسٹنٹ جو ایک کنسٹنٹ سے الگ کر کے ایک علاحدہ کنسٹنٹ میں نکالا گیا» کہا جاتا ہے۔

ہارڈکوڈ کو انٹی پیٹرن کیوں مانا جاتا ہے

ہارڈکوڈ ایک انٹی پیٹرن ہے کیونکہ یہ کوڈ کی دیکھ ریکھ پذیری، ٹیسٹ پذیری اور وسیع پذیری کے اصولوں کی خلاف ورزی کرتا ہے۔ ایسے کوڈ میں جہاں قیمتیں «کیل سے ٹھونکی گئی ہیں»، ماحول، ڈیزائن یا لجیک میں کسی بھی تبدیلی کے لیے سورسز میں دستی طلاش اور تبدیل کی ضرورت ہے۔ یہ غلطیوں کے خطرے کو بڑھاتا ہے اور ترقی کو سست کرتا ہے۔

ایک طویل موبائل ایپلیکیشن کی مثال سے ہارڈکوڈ کے مخصوص نتائج پر غور کریں۔ اگر تمام بٹنوں کا مارجن کسی وسیلے کے ذریعے نہیں بلکہ کوڈ میں ایک عدد سے متعین کیا گیا ہے — ڈیزائن میں تبدیلی کے لیے تمام مقامات کو چھونکر بدلنا ہوگا۔ اگر اینڈ پوئنٹ URL مضبوط طرح مقرر ہے — ماحولات (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
}

ٹیسٹنگ پر اثر

ایک ہارڈکوڈ کردہ ڈیٹابیس URL مقامی 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

ہارڈکوڈ سے بچنے کے کئی مصدقہ طریقے موجود ہیں، ہر ایک اپنی قیمت کی قسم کے لیے موزوں ہے۔ متبادل کا انتخاب اس بات پر منحصر ہے کہ قیمت کتنی مرتبہ بدلتی ہے اور کون اسے بدلتا ہے: ڈیویلپر، ڈیواپس یا آخری صرف کرنے والا۔

کنفگریشن فائلیں

سرور URLز، API کنجیاں اور فیچر فلیگز کے لیے JSON، YAML یا TOML فارمیٹ میں کنفگریشن فائلیں استعمال کریں۔ Android پر، یہ build.gradle buildConfigField یا res/values/config.xml کے ساتھ ہے۔ iOS پر — Info.plist یا xcconfig۔ کنفگریشنیں ایپلیکیشن کے ساتھ ترتیب پاتی ہیں، لیکن مختلف بائل اسکیمز کے لیے مختلف ہو سکتی ہیں۔

انوارونمنٹ ویریابلز

راز ( ٹوکنز، پاسورڈز ) اور ماحول کے پیرامیٹرز کے لیے انوارونمنٹ ویریابلز استعمال کریں۔ وہ ریپوزیٹری میں نہیں جاتیں اور dev، stage اور prod سرورز پر مختلف ہو سکتی ہیں۔ موبائل ڈیویلپمنٹ میں، انوارونمنٹ ویریابلز اکثر Xcode بائل اسکیمز یا Gradle میں build flavors کے ذریعے تقلید کی جاتی ہیں۔

ایپلیکیشن کے وسائل

سٹرنگز، رنگ، سائز، تصاویر کو وسائل کی فائلوں میں رکھنا چاہی۔: 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 کے ذریعے Dependency Injection استعمال کریں۔ DI فریم ورکز ٹیسٹز، مختلف ماحولات، مختلف صارفین کے لیے پروگرام کی عمل کے دوران نفاذیت بدلنے کی اجازت دیتے ہیں۔ یہ تجرید کی سب سے اونچی سطح ہے، جہاں قیمت کا «ٹھونکنا» بیرونی انسیال سے بدل دیا جاتا ہے۔

ہارڈکوڈ شدہ کوڈ کو کیسے ری فیکٹر کیا جائے

ہارڈکوڈ کا ری فیکٹرنگ مقرر قیمتوں کو کنفگریشن یا وسائل میں نکالنے کا عمل ہے۔ یہ ری فیکٹرنگ کے سب سے محفوظ آپریشنز میں سے ایک ہے، اگر اسے طریقہ واری انجام دیا جائے۔ ذیل میں بیان کردہ ترتیب کسی بھی زبان اور پلیٹ فارم کے لیے موزوں ہے۔

مرحلہ 1: تمام جادوئی عددوں اور سٹرنگز کو چھونیں

IDE (Search in Project) یا ایک اسکریپٹ کے ذریعے طلاش کی جا سکتی ہے۔ سٹرنگز، URLز، عددی لیٹرلز، سائز، ٹائم آئوٹ کو چھونیں۔ خاص توجہ — دہرائی قیمتوں پر: اگر وہی عدد پانچ مقامات پر ظاہر ہوتا ہے، تو یہ کنسٹنٹ میں نکالنے کا امیڈوار ہے۔ grep یا IDEA / Xcode کی مضمونی طلاش استعمال کریں۔

مرحلہ 2: نامزد کنسٹنٹس سے بدلیں

ہر ملنے والی قیمت کے لیے بامعنی نام کا کنسٹنٹ بنائیں۔ کنسٹنٹس کو میڈیولز یا کلاسز کے مطابق گروپ کریں۔ نام کو قیمت کا مطلب سمجھانا چاہی۔، یہ نہیں کہ اسے کیسے استعمال کیا جاتا ہے: TIMEOUT_30 نہیں، API_TIMEOUT۔ بدلنے کے بعد کوڈ میں کوئی عدد بگیر وضاحت نہیں رہنا چاہی۔۔

// پہلے: جادوئی عدد 0.4
let cardHeight = screenHeight * 0.4

// بعد: نامزد کنسٹنٹ
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

مرحلہ 3: کنفگریشن یا وسائل میں نکالیں

اگر قیمت بائلز یا ماحولات کے درمیان بدل سکتی ہے — اسے کنفگریشن فائل یا ایپلیکیشن کے وسائل میں رکھیں۔ سٹرنگز کے لیے مقامی کرنے کی فائلیں استعمال کریں۔ URLز کے لیے — build config یا xcconfig۔ سائز کے لیے — وسائل کی فائلیں (Android پر dimens.xml)۔ نکالنے کے بعد ایپلیکیشن کے بننے اور صحیح کام کرنے کی تصدیق کریں۔

مرحلہ 4: ایک ٹیسٹ لکھیں

ری فیکٹرنگ کے بعد، ایک ٹیسٹ لکھیں جو کنفگریشن کے صحیح لوڈ ہونے اور قیمتوں کے متوقعہ کے مطابق ہونے کی تصدیق کرتا ہے۔ اگر مستقبل میں کوئی config بدلتا ہے، ٹیسٹ اس اختلاف کی ضرورت کو اشارہ کرے گا۔ کنفگریشن کا ٹیسٹ ریگریشن کو روکنے کا ایک تیز اور قابل بھروسہ طریقہ ہے۔

مرحلہ 5: دراح جات ہٹائیں

config میں نکالنے کے بعد تصدیق کریں کہ پرانی قیمت استعمال کرنے والے تمام مقامات ایک واحد مخذ کا حوالہ دیتے ہیں۔ تبصرہ شدہ کوڈ اور پرانے کنسٹنٹس کو ہٹائیں جو مزید استعمال نہیں ہوتے۔ ری فیکٹرنگ کو ایک کمیٹ کے ساتھ مکمل کریں جس کا پیغام بیان کرتا ہے کہ کون سی قیمتیں اور کہاں نکالی گئی ہیں۔