کد موقت در برنامه‌نویسی — چیست، دلایل و چه زمانی موجه است

«کد موقت» در برنامه‌نویسی چیست

کد موقت (crutch) — راه‌حل نرم‌افزاری که کار می‌کند اما «سرسری» ساخته شده: مشکل خاصی را می‌بندد اما علت آن را برطرف نمی‌کند، از معماری پروژه پیروی نمی‌کند و با کوچک‌ترین تغییرات محیط ممکن است خراب شود. استعاره دقیق است — مانند یک عصای واقعی، چنین کدی به «راه رفتن» کمک می‌کند اما «پا» را درمان نمی‌کند.

برنامه‌نویسان با کد موقت، باگ‌ها، ناسازگاری نسخه‌ها، ویژگی‌های پلتفرم و درخواست‌های فوری مشتری را «زیرپایی می‌گذارند». یک کد موقت معمول — کد موقت شرطی: اگر iOS 15 فاصله اضافه کن، اگر Huawei — دکمه را مخفی کن. چنین بررسی‌هایی تکثیر می‌شوند و کد را به «کیک لایه‌ای» از شاخه‌های پلتفرمی و نسخه‌ای تبدیل می‌کنند.

کدهای موقت در مقیاس‌های مختلف وجود دارند: از یک خط با شرط موقت تا یک ماژول میان‌افزاری کامل که رفتار کتابخانه را «اصلاح» می‌کند. مهم است بدانیم که کد موقت همیشه بد نیست: در دستان درست، ابزاری است که امکان انتشار به موقع محصول را فراهم می‌کند. مشکل زمانی شروع می‌شود که کد موقت برای همیشه در کد باقی می‌ماند.

چرا کدهای موقت ظاهر می‌شوند: دلایل و زمینه

دلیل اصلی ظهور کدهای موقت — تضاد بین راه‌حل ایده‌آل و محدودیت‌های واقعی پروژه است. برنامه‌نویس می‌داند چگونه درست انجام دهد، اما زمان، پول یا محدودیت‌های فنی اجازه نمی‌دهد. در نتیجه یک راه‌حل مصالحه‌ای ایجاد می‌شود که «فقط کار می‌کند».

بیایید چهار دلیل اصلی را بررسی کنیم که چرا برنامه‌نویسان آگاهانه به کد موقت متوسل می‌شوند. درک این دلایل کمک می‌کند تا کدهای موقت را نه به عنوان اشتباه، بلکه به عنوان ابزاری عملی که نیاز به مدیریت دارد، ببینیم.

ضرب‌الاجل‌ها

شایع‌ترین دلیل. انتشار فردا است، باگ فقط روی یک مدل خاص تکرار می‌شود، رفع معماری دو هفته طول می‌کشد. کد موقت شرطی یک ساعت طول می‌کشد و مشکل را می‌بندد. پس از انتشار، تیم قول می‌دهد برگردد و درست بازنویسی کند. «هیچ چیز دائمی‌تر از یک راه‌حل موقت نیست» — دقیقاً درباره این کدهای موقت است.

ناسازگاری نسخه‌ها

کتابخانه A به Android 12 نیاز دارد اما برنامه شما از Android 10 پشتیبانی می‌کند. راه‌حل — نوشتن یک لایه میانی که نسخه سیستم‌عامل را بررسی کرده و مسیر اجرا را انتخاب می‌کند. این یک کد موقت است، زیرا هنگام به‌روزرسانی کتابخانه، لایه میانی باید بازنویسی شود. اما جایگزین — کنار گذاشتن کتابخانه یا پشتیبانی از دستگاه‌های قدیمی — می‌تواند بدتر باشد.

// کد موقت برای سازگاری با API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

وابستگی‌های خارجی با باگ

کتابخانه‌ای که پروژه به آن وابسته است دارای باگ است، اما به‌روزرسانی آن ممکن است هفته‌ها طول بکشد (نیاز به PR، بازبینی کد، انتشار). به جای انتظار، تیم یک wrapper می‌نویسد که رفتار کتابخانه را در لحظه وصله می‌کند. پس از انتشار نسخه اصلاح‌شده کتابخانه، wrapper حذف می‌شود. اگر حذف نشود — این دیگر یک مشکل معماری است.

درک ناقص از سیستم

یک برنامه‌نویس جدید در پروژه قدیمی نمی‌فهمد که چرا کد دقیقاً به این شکل کار می‌کند. به جای بررسی، یک شرط جدید روی شرط موجود اضافه می‌کند. این خطرناک‌ترین نوع کد موقت است، زیرا نویسنده متوجه نیست که این یک کد موقت است. تنها درمان — بازبینی کد و برنامه‌نویسی جفتی برای اعضای جدید تیم.

چه زمانی کد موقت موجه است: رویکرد عملی

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

معیارهای کد موقت موجه: مشکل خاصی را می‌بندد، مالک دارد (کسی که مسئول حذف آن است) و برنامه بازسازی وجود دارد. اگر حداقل یکی از سه شرط برقرار نباشد — کد موقت به بدهی فنی تبدیل می‌شود. ابزارهایی مانند توضیحات TODO با ticket در ردیاب — حداقل روش مستندسازی است.

مثال کد موقت موجه

یک باگ بحرانی در شاخه انتشار که باید تا استقرار فردا بسته شود. راه‌حل خالص نیاز به بازسازی معماری دارد و دو هفته طول می‌کشد. کد موقت — اضافه کردن بررسی nil و ارسال fix به عنوان hotfix. شرایط موجه بودن: ticket برای بازسازی در ردیاب ایجاد شده، شخص مسئول تعیین شده، کد موقت با توضیح مشخص شده است. دو هفته بعد تیم به وظیفه بازمی‌گردد.

// TODO: IT-1234 — پس از بازسازی AuthService این کد موقت را حذف کنید
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

چگونه کد موقت را از مشکل معماری تشخیص دهیم

مرز بین کد موقت آگاهانه و مشکل معماری (بدهی فنی) بر دو پارامتر استوار است: آگاهانه بودن تصمیم و وجود برنامه حذف. کد موقت همیشه یک راه‌حل موقت با عمر مشخص است. بدهی فنی — نتیجه کدهای موقت متعددی است که بدون توجه رها شده‌اند.

چه زمانی کد موقت به مشکل تبدیل می‌شود

وضعیت وقتی بدتر می‌شود که تعداد کدهای موقت از جرم بحرانی فراتر رود. هر کد موقت جدید «شکنندگی» سیستم را افزایش می‌دهد: تغییر در یک مکان، مکان دیگر را خراب می‌کند. در نتیجه توسعه کند می‌شود، باگ‌ها تکثیر می‌شوند و یک برنامه‌نویس جدید بدون کمک نویسنده نمی‌تواند کد را بفهمد. در این لحظه کدهای موقت دیگر راه‌حل موقت نیستند و به مشکل معماری تبدیل می‌شوند.

نشانه‌های بحران کدهای موقت

اگر در کد پنج بررسی تو در تو برای نسخه سیستم‌عامل، سازنده دستگاه و وجود کتابخانه خاص وجود دارد — این کد موقت نیست، مشکل معماری است. اگر افزودن یک fix باعث سه پسرفت در ماژول‌های مجاور شود — کدهای موقت دیگر محلی نیستند. اگر بازبینی کد به دلیل «یک کد موقت دیگر» مرتباً رد می‌شود — وقت برنامه‌ریزی بازسازی است.

• یک کد موقت در سه یا بیشتر مکان تکرار می‌شود — وقت راه‌حل واحد است
• کد موقت بیش از سه sprint بدون برنامه حذف زنده می‌ماند — این دیگر بدهی فنی است
• برنامه‌نویس جدید نمی‌فهمد چرا کد این‌گونه کار می‌کند — کد موقت مستند نشده
• حذف کد موقت باعث واکنش زنجیره‌ای خطاها می‌شود — وابستگی به کد موقت معماری شده است

بازسازی کدهای موقت: استراتژی و عمل

بازسازی کدهای موقت — فرآیند جایگزینی راه‌حل‌های موقت با راه‌حل‌های معماری درست. این نیاز به زمان دارد، بنابراین یک استراتژی اولویت‌بندی لازم است: همه کدهای موقت نیاز به حذف فوری ندارند. یک استراتژی خوب — ارزیابی هر کد موقت بر دو پارامتر: فراوانی تغییرات در این ناحیه از کد و تأثیر بر کاربران.

استراتژی اولویت‌بندی

اولویت بالا — کدهای موقت در ماژول‌های پرتغییر (منطق کسب‌وکار، UI عمومی) که توسعه را کند می‌کنند و باعث پسرفت می‌شوند. اولویت متوسط — کدهای موقت در ماژول‌های کم‌تغییر اما با تأثیر بالقوه بر کاربران (پردازش پرداخت، احراز هویت). اولویت پایین — کدهای موقت در کد قدیمی که پایدار کار می‌کند و برنامه‌ای برای تغییر آن نیست.

فرآیند گام‌به‌گام حذف

گام ۱: فهرست‌برداری — همه TODO و FIXME مرتبط با کدهای موقت را پیدا کنید. گام ۲: ارزیابی — تعیین کنید کدام‌ها هنوز معتبر هستند. گام ۳: برنامه‌ریزی — بازسازی کدهای موقت را در sprint برنامه‌ریزی کنید، از اولویت بالا شروع کنید. گام ۴: جایگزینی — راه‌حل خالص را پیاده‌سازی کنید، کد موقت و توضیح TODO آن را حذف کنید. گام ۵: تأیید — مطمئن شوید تست‌ها عبور می‌کنند و پسرفتی وجود ندارد.

# همه کدهای موقت TODO را در پروژه پیدا کنید
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

پیشگیری از کدهای موقت جدید

بهترین راه مبارزه با کدهای موقت — ایجاد نکردن آنها بدون نیاز است. قبل از نوشتن کد موقت، سه سوال از خود بپرسید: آیا می‌شود راه‌حل خالص در زمان معقول انجام داد؟ آیا جایگزینی وجود دارد که کد موقت نباشد؟ آیا تیم زمان خواهد داشت برگردد و این را بازنویسی کند؟ اگر حداقل به یک سوال پاسخ «نه» است — قبل از «زیرپایی گذاشتن» کد، دوباره فکر کنید.