بدهی فنی (Technical Debt)

مشکل: چرا همه چیز کند شده است؟

فروشگاه اینترنتی ما دو سال پیش راه افتاد. آن روزها هر ویژگی جدید یک هفته طول می‌کشید. حالا مدیر محصول می‌پرسد: «چرا یک تغییر ساده در تخفیف، سه هفته طول کشید؟»

تیم جواب را می‌داند، ولی گفتنش سخت است:

1. قانون تخفیف در سه جا کپی شده است. در سبد خرید، در صفحه پرداخت و در گزارش فروش. هر تغییر باید سه بار انجام شود.
2. تست خودکار برای پرداخت نداریم. هر تغییر را باید دستی امتحان کرد.
3. کلاس CheckoutService سه هزار خط است. هیچ کس جرأت نمی‌کند به آن دست بزند.

هر کدام از این‌ها روزی یک تصمیم سریع بود. به این‌ها بدهی فنی می‌گوییم.

ایده: وام و سود

این تشبیه را وارد کانینگهام (Ward Cunningham) مطرح کرد. وقتی یک میان‌بر می‌زنیم، مثل این است که وام گرفته‌ایم:

1. اصل وام. کاری که باید بعداً انجام دهیم تا کد را درست کنیم. مثلاً یکی کردن سه نسخه قانون تخفیف.
2. سود وام. وقت اضافه‌ای که هر بار برای کار با کد بد می‌پردازیم. مثلاً سه بار تغییر به جای یک بار، و باگ‌هایی که چون یکی از سه جا فراموش شد، پیش آمد.
3. نکته مهم. تا وقتی وام را پس نداده‌ایم، سود را می‌دهیم. و سود فقط وقتی پرداخت می‌شود که به آن کد دست بزنیم.

وام بد نیست. شرکت‌ها برای رشد وام می‌گیرند. مشکل، وامی است که کسی یادش نیست، و سودی که هر ماه بیشتر می‌شود.

مثال زنده: سود بدهی در طول زمان

در این مدل ساده، هر اسپرینت ده واحد وقت داریم. هر اسپرینت یک میان‌بر تازه اضافه می‌شود. هر واحد بدهی، یک واحد از وقت هر اسپرینت را می‌خورد. دو روش را امتحان کن:

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

چهار نوع بدهی

همه بدهی‌ها یکسان نیستند. مارتین فاولر (Martin Fowler) بدهی را با دو سؤال تقسیم می‌کند: آگاهانه بود؟ و با احتیاط بود؟

1. آگاهانه و محتاطانه. «حراج جمعه است. با یک راه ساده می‌فرستیم و هفته بعد درستش می‌کنیم.» این یک تصمیم کسب‌وکاری درست است، اگر واقعاً ثبت شود و هفته بعد انجام شود.
2. آگاهانه و بی‌احتیاط. «وقت طراحی نداریم.» تیم می‌داند که بد است، ولی هیچ برنامه‌ای برای برگشت ندارد.
3. ناآگاهانه و بی‌احتیاط. تیم نمی‌داند که کد بد است. راه حلش آموزش و بازبینی کد است.
4. ناآگاهانه و محتاطانه. «حالا که ساختیم، فهمیدیم چطور باید می‌ساختیم.» این همیشه پیش می‌آید. نشانه یادگیری است، نه اشتباه.

کدام بدهی را اول بدهیم؟

همه کد بد ارزش درست کردن ندارد. یادت هست؟ سود فقط وقتی پرداخت می‌شود که به کد دست بزنیم. پس کد زشتی که هیچ کس تغییرش نمی‌دهد، تقریباً سودی ندارد.

یک روش ساده برای پیدا کردن این نقطه‌های داغ (Hotspot):

1. تعداد تغییر را بشمار. تاریخچه گیت نشان می‌دهد کدام فایل‌ها در چند ماه اخیر بیشتر تغییر کرده‌اند.
2. پیچیدگی را ببین. فایل‌های خیلی بزرگ، متدهای خیلی طولانی، شرط‌های تودرتو.
3. این دو را کنار هم بگذار. فایلی که در هر دو فهرست بالا است، اولویت اول است.
4. از تیم بپرس. «کدام بخش را دوست نداری باز کنی؟» این جواب معمولاً با عددها جور است.

# Files changed most often in the last 6 months
git log --since="6 months ago" --name-only --pretty=format: -- "*.cs" \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -10

نمونه: یکی کردن قانون تخفیف

قبل از تغییر، همین منطق در سه کلاس جدا بود:

// CartService.cs, CheckoutService.cs and SalesReport.cs (copied 3 times)
var discount = order.Total > 5_000_000 && customer.IsVip ? 0.1m : 0m;
var payable = order.Total - order.Total * discount;

بعد از تغییر، قانون یک جا و به زبان کسب‌وکار است:

public static class DiscountPolicy
{
    private const decimal VipThreshold = 5_000_000;
    private const decimal VipRate = 0.10m;

    public static decimal PayableAmount(decimal total, bool isVip) =>
        isVip && total > VipThreshold ? total * (1 - VipRate) : total;
}

حالا یک تست کافی است و تغییر بعدی فقط یک جا انجام می‌شود. این بازآرایی (Refactoring) کوچک بود. لازم نبود کل سیستم را بازنویسی کنیم.

چطور بدهی را کم کنیم؟

1. ثبتش کن. هر بدهی آگاهانه یک کار در فهرست کارهای تیم (Backlog) می‌شود. بنویس کجا است، سودش چیست و درست کردنش چقدر وقت می‌برد. بدهی ثبت‌نشده فراموش می‌شود.
2. قانون پیشاهنگی. هر بار که به یک فایل دست می‌زنی، آن را کمی تمیزتر از قبل ترک کن. یک اسم بهتر، یک متد کوتاه‌تر، یک تست.
3. سهم ثابت در هر اسپرینت. بخشی از وقت هر اسپرینت را برای بدهی کنار بگذار. پرداخت کم و همیشگی بهتر از یک پاک‌سازی بزرگ است که هیچ وقت تأیید نمی‌شود.
4. بدهی را به کار کسب‌وکاری بچسبان. «قبل از تخفیف جدید، قانون تخفیف را یکی می‌کنیم» راحت‌تر تأیید می‌شود تا «یک اسپرینت برای Refactoring».
5. بخش بزرگ را کم‌کم عوض کن. برای یک بخش خیلی بد، بازنویسی کامل خطرناک است. کد جدید را کنار کد قدیمی بساز و کم‌کم مسیرها را به آن ببر. به این روش Strangler Fig می‌گوییم.

با مدیر چطور حرف بزنیم؟

مدیر محصول کلمه «کد کثیف» را نمی‌فهمد. ولی وقت، پول و ریسک را خوب می‌فهمد.

اشتباه‌های رایج