هاردکد در توسعه: چیست، ریسک‌ها و چگونه اجتناب کنیم

معنای «میخکوب کردن» و «هاردکد کردن»

هاردکد کردن (میخکوب کردن) – تعبیه یک مقدار مشخص در کد برنامه به گونه‌ای که برای تغییر آن نیاز به ویرایش کد منبع و کامپایل مجدد برنامه باشد. استعاره «میخکوب کردن» دقیقاً ماهیت را منعکس می‌کند: مقدار محکم تثبیت شده و جدا کردن آن از کد فقط با تلاش امکان‌پذیر است.

نمونه هاردکد – 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 استفاده کنید. در اندروید این build.gradle با buildConfigField یا res/values/config.xml است. در iOS – Info.plist یا xcconfig. کانفیگ‌ها همراه با برنامه ساخته می‌شوند اما می‌توانند برای طرح‌های ساختی مختلف متفاوت باشند.

متغیرهای محیطی

برای اسرار (توکن‌ها، رمزهای عبور) و پارامترهای محیط از متغیرهای محیطی استفاده کنید. آنها وارد مخزن نمی‌شوند و می‌توانند در سرورهای dev، stage و prod متفاوت باشند. در توسعه موبایل، متغیرهای محیطی اغلب از طریق طرح‌های ساخت Xcode یا build flavors در Gradle شبیه‌سازی می‌شوند.

منابع برنامه

رشته‌ها، رنگ‌ها، اندازه‌ها، تصاویر باید به فایل‌های منابع منتقل شوند: strings.xml در اندروید، Localizable.strings در iOS، فایل‌های ARB در Flutter. این کار بومی‌سازی، تطبیق با صفحه‌های مختلف و تم تاریک را ساده می‌کند. تغییر رشته در منابع نیازی به بازنویسی کد ندارد.

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

تزریق وابستگی (DI)

برای سرویس‌ها و تأمین‌کنندگان از Dependency Injection از طریق Dagger، Hilt یا Koin در اندروید، Swinject در iOS استفاده کنید. فریم‌ورک‌های DI امکان جایگزینی پیاده‌سازی‌ها را در لحظه فراهم می‌کنند – برای آزمایش‌ها، محیط‌های مختلف، کاربران مختلف. این بالاترین سطح انتزاع است، جایی که «میخکوبی» مقدار با تزریق از بیرون جایگزین می‌شود.

چگونه کد هاردکد شده را بازآرایی کنیم

بازآرایی هاردکد – فرآیند انتقال مقادیر سفت‌وسخت به پیکربندی یا منابع. این یکی از ایمن‌ترین عملیات‌های بازآرایی است، اگر به صورت روشمند انجام شود. دنباله توصیف شده در زیر برای هر زبان و پلتفرمی مناسب است.

مرحله ۱: همه اعداد جادویی و رشته‌ها را پیدا کنید

جستجو را می‌توان از طریق IDE (Search in Project) یا با اسکریپت انجام داد. رشته‌ها، URLها، لیترال‌های عددی، اندازه‌ها، زمان‌های انتظار را جستجو کنید. توجه ویژه به مقادیر تکراری: اگر یک عدد در پنج جا ظاهر می‌شود، این کاندیدای انتقال به ثابت است. از grep یا جستجوی داخلی IDEA / Xcode استفاده کنید.

مرحله ۲: با ثابت‌های نام‌دار جایگزین کنید

برای هر مقدار پیدا شده یک ثابت با نام معنادار ایجاد کنید. ثابت‌ها را بر اساس ماژول‌ها یا کلاس‌ها گروه‌بندی کنید. نام باید توضیح دهد که مقدار به چه معناست، نه اینکه چگونه استفاده می‌شود: API_TIMEOUT، نه TIMEOUT_30. پس از جایگزینی، هیچ عددی در کد نباید بدون توضیح باقی بماند.

// قبل: عدد جادویی 0.4
let cardHeight = screenHeight * 0.4

// بعد: ثابت نام‌دار
private let cardHeightRatio: CGFloat = 0.4
let cardHeight = screenHeight * cardHeightRatio

مرحله ۳: به پیکربندی یا منابع منتقل کنید

اگر مقدار ممکن است بین ساخت‌ها یا محیط‌ها تغییر کند – آن را به فایل پیکربندی یا منابع برنامه منتقل کنید. برای رشته‌ها از فایل‌های بومی‌سازی استفاده کنید. برای URL – build config یا xcconfig. برای اندازه‌ها – فایل‌های منابع (dimens.xml در اندروید). بررسی کنید که برنامه پس از انتقال به درستی ساخته و اجرا می‌شود.

مرحله ۴: یک آزمایش بنویسید

پس از بازآرایی، آزمایشی بنویسید که بررسی کند پیکربندی به درستی بارگذاری می‌شود و مقادیر با موارد مورد انتظار مطابقت دارند. اگر در آینده شخصی کانفیگ را تغییر دهد، آزمایش عدم تطابق را نشان خواهد داد. آزمایش پیکربندی راهی سریع و قابل اعتماد برای جلوگیری از بازگشت است.

مرحله ۵: تکراری‌ها را حذف کنید

پس از انتقال به کانفیگ بررسی کنید که همه مکان‌هایی که از مقدار قدیمی استفاده می‌کردند به منبع واحد ارجاع می‌دهند. کد کامنت شده و ثابت‌های قدیمی که دیگر استفاده نمی‌شوند را حذف کنید. بازآرایی را با کامیتی با پیامی که توضیح می‌دهد چه مقادیری و به کجا منتقل شده‌اند نهایی کنید.