بدهی فنی در توسعه موبایل — ماهیت، انواع و اصول مدیریت

بدهی فنی (Technical Debt) چیست

بدهی فنی (Technical Debt) — استعاره‌ای است که اولین بار توسط وارد کانینگهام در سال ۱۹۹۲ در OOPSLA ارائه شد. او برنامه‌نویسی را با سرمایه‌گذاری مقایسه کرد: کد شلخته یک وام گرفته شده است. بهره آن به صورت زمان اضافی برای پشتیبانی، رفع باگ‌ها و سازگاری با نیازهای جدید پرداخت می‌شود. مهم است بدانیم که بدهی همیشه بد نیست؛ بدهی استراتژیک می‌تواند موجه باشد.

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

نکته مهم: بدهی فنی ≠ کد بد. کد بد — نتیجه بی‌کفایتی است. بدهی فنی — سازش آگاهانه. تیم می‌فهمد که کار غیرایده‌آل انجام می‌دهد، آن را در مستندات فنی ثبت می‌کند و برنامه بازگشت برای بهبود را دارد. تفاوت بین بدهی و کد بد در آگاهانه بودن تصمیم است. به همین دلیل اولین گام برای مدیریت بدهی — پذیرش وجود آن است.

انواع بدهی فنی

طبقه‌بندی بدهی فنی به درک ماهیت آن و انتخاب استراتژی مناسب پرداخت کمک می‌کند. مارتین فاولر مدل ربعی را با دو محور پیشنهاد کرد: عمدی/غیرعمدی و نسنجیده/سنجیده. هر ترکیب نیازمند رویکرد متفاوتی است. بیایید انواع اصلی بدهی را که تیم توسعه موبایل با آن مواجه می‌شود بررسی کنیم.

بدهی عمدی و غیرعمدی

بدهی عمدی — تیم آگاهانه تصمیم می‌گیرد کد غیربهینه را برای رسیدن به مهلت تحویل منتشر کند. مثال: راه‌اندازی MVP با یک ViewModel یکپارچه، با علم به اینکه پس از اعتبارسنجی فرضیه، ViewModel بر اساس دامنه‌ها تقسیم خواهد شد. چنین بدهی در بک‌لاگ ثبت می‌شود و سررسید برنامه‌ریزی شده دارد. بدون برنامه، بدهی عمدی مزمن می‌شود.

بدهی غیرعمدی — کدی که کیفیت آن به دلیل کمبود دانش، نبود بازبینی کد یا فرآیندهای ضعیف پایین‌تر از حد انتظار است. مثال: توسعه‌دهنده بهترین شیوه‌های کار با Room DB را نمی‌دانست و کوئری‌ها را در رشته UI می‌نوشت و باعث ANR می‌شد. چنین بدهی موذی‌ترین است — تیم تا مواجهه با مشکلات بحرانی عملکرد آن را درک نمی‌کند.

بدهی معماری و کد

بدهی معماری — انتخاب نادرست الگوها یا ساختار پروژه. مثال: برنامه بدون لایه انتزاع بر روی شبکه، جایی که Retrofit مستقیماً از ViewModel استفاده می‌شود. جایگزینی Retrofit با Ktor نیازمند تغییر همه ViewModel‌ها خواهد بود. رفع بدهی معماری گران‌ترین است، بنابراین تصمیم‌ها در سطح معماری با حداکثر احتیاط گرفته می‌شوند.

بدهی کد — نابهینه‌های محلی درون یک کلاس یا متد خاص. مثال: متد طولانی با ۲۰۰ خط که در آن UI، منطق کسب‌وکار و کار با داده‌ها مخلوط شده است. با Extract Method در ۱۵ دقیقه رفع می‌شود. بدهی کد کمتر بحرانی است، اما انباشت آن در مقیاس پروژه توسعه را کمتر از بدهی معماری کند نمی‌کند.

بدهی تست و مستندات

بدهی تست — نبود تست‌های واحد، تست‌های UI یا تست‌های یکپارچه‌سازی. هر اجرای دستی رگرسیون بهره این بدهی است. اگر در پروژه تست خودکار نباشد، هر تغییری ساعت‌ها تست دستی نیاز دارد. به گفته Google Testing Blog، پروژه‌های با پوشش تست >۷۰٪ دو برابر کمتر باگ به تولید می‌فرستند.

بدهی مستندات — نبود یا قدیمی شدن مستندات معماری، کامنت‌ها برای بخش‌های پیچیده کد، readme برای راه‌اندازی. توسعه‌دهنده جدید بدون مستندات هفته‌ها وقت تلف می‌کند. راه‌حل: نگهداری Architecture Decision Records (ADR) و بخشی کردن مستندات از Definition of Done برای هر کار.

چرا بدهی فنی خطرناک است

اثر بهره مرکب — خطر اصلی بدهی فنی. هر لایه جدید کد غیربهینه پیچیدگی سیستم را نه خطی، بلکه نمایی افزایش می‌دهد. مثال ساده: اگر ماژول A به ماژول B وابسته باشد و هر دو حاوی بدهی باشند، تغییر در A نیازمند درک بدهی در B است. پس از ۱۰ تکرار، توسعه‌دهنده ۸۰٪ زمان را صرف باز کردن وابستگی‌ها و فقط ۲۰٪ را صرف قابلیت جدید می‌کند.

کند شدن زمان عرضه به بازار — نتیجه مستقیم بدهی. تیم زمان بیشتری را صرف پشتیبانی و زمان کمتری را صرف ویژگی‌های جدید می‌کند. تحقیق Stripe (۲۰۲۳) نشان داد که توسعه‌دهندگان به طور متوسط ۱۷ ساعت در هفته را صرف کار با بدهی فنی می‌کنند، نه ایجاد ارزش برای کسب‌وکار. در توسعه موبایل این با نیاز به پشتیبانی از دو پلتفرم — هر کدام با به‌روزرسانی‌های پلتفرمی خود — تشدید می‌شود.

فرسودگی تیم — نتیجه غیرقابل مشاهده اما مخرب. کار در کدی که هر تغییری سه چیز دیگر را خراب می‌کند باعث استرس مزمن می‌شود. توسعه‌دهندگان از افتخار به محصول دست می‌کشند، انگیزه کاهش می‌یابد، جابجایی کارکنان افزایش می‌یابد. به گفته Stack Overflow Survey ۲۰۲۴، کار با کد قدیمی — دومین علت شایع نارضایتی شغلی پس از حقوق پایین است.

چگونه بدهی فنی را مدیریت کنیم

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

استراتژی Boy Scout Rule — «محل اردو را تمیزتر از آنچه یافتی ترک کن». قانون ساده: هنگام تغییر متد ۱۰٪ زمان بیشتر صرف کن تا آن را کمی بهتر کنی — نام متغیر را عوض کن، بلوک ۵۰ خطی را به دو بخش تقسیم کن. در مقیاس تیم این رویکرد کاهش تدریجی بدهی را بدون اختصاص اسپرینت‌های جداگانه برای بازآفرینی می‌دهد. بهبود باید میکروسکوپی اما منظم باشد.

اختصاص زمان برای مدیریت بدهی — نشانه بلوغ تیم. توصیه می‌شود ۱۵–۲۰٪ اسپرینت را به بهبودهای فنی اختصاص دهید. این به این معنی نیست که تیم یک روز در هفته جز بازآفرینی کاری نمی‌کند. وظایف فنی به طور مساوی توزیع می‌شوند: بهبود معیارها، بازآفرینی بخش‌های داغ، به‌روزرسانی وابستگی‌ها. بدون زمان اختصاصی، بدهی پیوسته رشد می‌کند.

// استراتژی Boy Scout Rule در عمل
// بود: متد غیرقابل خواندن با اعداد جادویی
fun calc(a: Int): Int = a * 60 * 1000

// شد: متد قابل خواندن با ثابت‌ها
private const val SECONDS_IN_MINUTE = 60
private const val MILLIS_IN_SECOND = 1000

fun minutesToMillis(minutes: Int): Int =
    minutes * SECONDS_IN_MINUTE * MILLIS_IN_SECOND

خودکارسازی کشف بدهی — سومین ستون مدیریت. اعلان‌هایی برای تشخیص متدهای طولانی (>۳۰ خط)، کلاس‌های بزرگ (>۵۰۰ خط)، تو در توی بیش از حد (>۵ سطح) تنظیم کنید. از Danger یا مشابه آن برای کامنت‌های خودکار روی درخواست‌های کشش استفاده کنید: اگر متد از آستانه پیچیدگی عبور کند، بات می‌نویسد «این متد پیچیدگی سیکلوماتیک ۱۲ دارد — لطفاً تقسیم آن را در نظر بگیرید». خودکارسازی بار بازبینی کد را کاهش می‌دهد.

ابزارهای تحلیل بدهی

SonarQube — محبوب‌ترین پلتفرم برای تحلیل بدهی فنی. «تعداد روزهای رفع» را محاسبه می‌کند — معیاری قابل فهم برای مدیران. SonarQube از Kotlin، Swift، Java، Python و زبان‌های دیگر پشتیبانی می‌کند. در خط لوله CI/CD ادغام می‌شود و اگر بدهی از آستانه فراتر رود، درخواست کشش را رد می‌کند. برای تیم‌های موبایل این استاندارد دوفاکتو است.

برای تیم‌های Android همچنین از Detekt (تحلیل استاتیک Kotlin) و Android Lint استفاده می‌شود. Detekt معیارهای کد را شمارش می‌کند و الگوهای Code Smell را پیدا می‌کند. افزونه Gradle SonarQube Android نتایج را در یک گزارش واحد ترکیب می‌کند. برای تیم‌های iOS — SwiftLint برای تحلیل استاتیک و Periphery برای یافتن کد استفاده نشده. Xcode Organizer معیارهای عملکرد را نشان می‌دهد که اغلب با بدهی معماری همبستگی دارند.

CodeClimate و CodeFactor — راه‌حل‌های ابری که مخازن GitHub/GitLab را تحلیل و پویایی بدهی را نشان می‌دهند. هر commit را ارزیابی می‌کنند و امکان ردیابی لحظه شروع رشد بدهی را فراهم می‌کنند. نمودار Maintainability — ابزاری قابل فهم برای ارتباط با مدیریت: «قله در ماه مارس را می‌بینید؟ آن زمان انتشار را مجبور کردیم و بدهی به اندازه ۳ روز رفع انباشتیم».