ডেভেলপমেন্টে হার্ডকোড: এটি কী, ঝুঁকি এবং কীভাবে এড়ানো যায়

“পেরেক দিয়ে আটকানো” এবং “হার্ডকোড করা” বলতে কী বোঝায়

হার্ডকোড করা (পেরেক দিয়ে আটকানো) — কোডে একটি নির্দিষ্ট মান এমনভাবে বসানো যে এটি পরিবর্তন করতে সোর্স কোড সম্পাদনা এবং অ্যাপ্লিকেশন পুনরায় কম্পাইল করতে হবে। “পেরেক দিয়ে আটকানো” রূপকটি সারমর্ম সঠিকভাবে প্রতিফলিত করে: মানটি স্থায়ীভাবে固定的, এবং কোড থেকে এটি আলাদা করা কেবল প্রচেষ্টার মাধ্যমে সম্ভব।

হার্ডকোডের উদাহরণ — ফাংশনের বডিতে সরাসরি স্ট্রিং হিসেবে লেখা সার্ভার 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 ডিবিতে টেস্ট চালাতে দেবে না। ডেভেলপারকে পূর্ণাঙ্গ সার্ভার চালু করতে হবে বা টেস্টিংয়ের আগে কোড সম্পাদনা করতে হবে। কোড থেকে কনফিগারেশন বের করা সমস্যার সমাধান করে: টেস্টগুলি পরীক্ষার প্যারামিটার ব্যবহার করে, production — বাস্তব প্যারামিটার, এবং কোড অপরিবর্তিত থাকে।

কখন হার্ডকোড ন্যায্য: নিয়মের ব্যতিক্রম

হার্ডকোড — একটি অ্যান্টিপ্যাটার্ন, তবে বৈধ ব্যতিক্রম রয়েছে, যখন জোর করে লেখা মান কেবল অনুমোদিত নয়, বরং পছন্দনীয়। সীমাটি পরিবর্তনযোগ্যতার অক্ষ বরাবর চলে: যদি মানটি অ্যাপ্লিকেশনের জীবনচক্রে কখনো বা প্রায় কখনো পরিবর্তিত না হয়, তবে এটি হার্ডকোড করা যেতে পারে। যদি সম্ভাব্যভাবে পরিবর্তিত হতে পারে — কনফিগারেশনে নিয়ে যান।

গাণিতিক এবং পদার্থবিজ্ঞানের কনস্ট্যান্ট — পাই, অভিকর্ষজ ত্বরণ, সেকেন্ডে মিলিসেকেন্ডের সংখ্যা — হার্ডকোডের জন্য নিরাপদ। এগুলি প্রকৃতি বা মান দ্বারা নির্ধারিত এবং পরিবর্তিত হবে না। স্পেসিফিকেশন দ্বারা নির্ধারিত কনস্ট্যান্ট অ্যারের আকার জোর করে লেখা যেতে পারে, তবে সংখ্যাটির উত্স সম্পর্কে মন্তব্য সহ।

ন্যায্য হার্ডকোডের উদাহরণ

সেকেন্ডে মিলিসেকেন্ডের সংখ্যা — একটি স্থিতিশীল কনস্ট্যান্ট, সময়ের মান দ্বারা নির্ধারিত। এটি কনফিগে নেওয়ার কোনো মানে নেই, কারণ এটি কখনো পরিবর্তিত হবে না। তবে এমন কনস্ট্যান্টও অর্থপূর্ণ নাম দিয়ে ঘোষণা করা ভাল, যাতে কোডে “ম্যাজিক সংখ্যা” না থাকে: 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। কনফিগগুলি অ্যাপ্লিকেশনের সাথে একসাথে বিল্ড হয়, তবে বিভিন্ন বিল্ড স্কিমের জন্য ভিন্ন হতে পারে।

Environment variables

গোপন তথ্য (টোকেন, পাসওয়ার্ড) এবং পরিবেশ প্যারামিটারের জন্য এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করুন। এগুলি রিপোজিটরিতে যায় না এবং 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: নামযুক্ত কনস্ট্যান্ট দিয়ে প্রতিস্থাপন করুন

প্রতিটি পাওয়া মানের জন্য একটি অর্থপূর্ণ নাম সহ কনস্ট্যান্ট তৈরি করুন। মডিউল বা ক্লাস অনুযায়ী কনস্ট্যান্ট গ্রুপ করুন। নামটি ব্যাখ্যা করবে মানটির অর্থ কী, এটি কীভাবে ব্যবহার হয় তা নয়: API_TIMEOUT, TIMEOUT_30 নয়। প্রতিস্থাপনের পরে কোডে কোনো সংখ্যা ব্যাখ্যা ছাড়া থাকা উচিত নয়।

// আগে: ম্যাজিক সংখ্যা 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: একটি টেস্ট লিখুন

রিফ্যাক্টরিংয়ের পরে একটি টেস্ট লিখুন যা যাচাই করে যে কনফিগারেশন সঠিকভাবে লোড হচ্ছে এবং মানগুলি প্রত্যাশিত অনুযায়ী রয়েছে। যদি ভবিষ্যতে কেউ কনফিগ পরিবর্তন করে, টেস্ট অমিল নির্দেশ করবে। কনফিগারেশন টেস্ট — regression প্রতিরোধের একটি দ্রুত এবং নির্ভরযোগ্য উপায়।

ধাপ 5: ডুপ্লিকেট মুছুন

কনফিগে নেওয়ার পরে যাচাই করুন যে পুরানো মান ব্যবহার করা সমস্ত জায়গা একক উত্স-কে নির্দেশ করছে। কমেন্ট করা কোড এবং পুরানো কনস্ট্যান্ট যা আর ব্যবহার হয় না মুছুন। রিফ্যাক্টরিং কমিট দিয়ে শেষ করুন, যার বার্তায় বর্ণনা করুন কী মান এবং কোথায় নেওয়া হয়েছে।