هر تیم نرم‌افزاری روزی به این نقطه می‌رسد که یک قابلیت ساده، چند برابر انتظار طول می‌کشد و هیچ‌کس دقیقاً نمی‌داند چرا. در بیشتر مواقع پاسخ در کدی است که سال گذشته با عجله نوشته شد. مدیریت بدهی فنی (Technical Debt) یعنی همین کار: بدهی‌هایی که برای سرعت گرفتن گرفته‌ایم را نام‌گذاری، اندازه‌گیری و در زمان درست بازپرداخت کنیم؛ نه اینکه امیدوار باشیم خودبه‌خود حل شوند.
چرا استعارهٔ مالی را باید جدی گرفت
وقتی مسیر میان‌بُر می‌زنیم، دو چیز به دست می‌آوریم: سرعت امروز و تعهدی برای فردا. مثل وام است؛ اصل بدهی همان کد میان‌بُر است و بهره‌اش هزینه‌ای که هر تغییر بعدی در همان ناحیه پرداخت می‌کند. تفاوت مهم با وام بانکی این است که صورت‌حساب بدهی فنی به خانه نمی‌آید؛ در قالب تأخیر، کار اضافه و خستگی تیم ظاهر می‌شود و کسی آن را به بدهی نسبت نمی‌دهد.
نکتهٔ دوم این است که بدهی، به‌خودی‌خود بد نیست. تیمی که هیچ بدهی‌ای ندارد، احتمالاً هیچ ریسکی هم نپذیرفته و هیچ‌گاه چیزی را زودتر به دست کاربر نرسانده است. مسئله «داشتن یا نداشتن» نیست؛ «آگاهانه بودن» و «مدیریت‌شده بودن» است.
سه نوع بدهی که نباید در یک سبد ریخته شوند
بدهی عمدی و آگاهانه
تصمیم می‌گیریم بخشی از اعتبارسنجی را ساده بگیریم تا نسخهٔ اولیه زودتر بازخورد بگیرد. این بدهی سالم است، به شرطی که نوشته شود: چه چیزی ساده شد، چرا، و چه زمانی باید برگردیم.
بدهی ناخواسته
وقتی بعد از نوشتن کد می‌فهمیم مدل داده اشتباه بوده است. این نوع با مستندسازی از بین نمی‌رود؛ با بازبینی کد در جایگاه درست و طراحی کوتاه پیش از پیاده‌سازی کم می‌شود.
بدهی محیطی و فرسودگی
وابستگی‌های قدیمی، اسکریپت‌های راه‌اندازی دستی و تنظیماتی که فقط یک نفر بلد است. این دسته بیشترین بهره را می‌گیرد، چون هر کار جدید را کند می‌کند و برخلاف بدهی کدی، در یک فایل مشخص جمع نشده است.
نرخ بهره را اندازه بگیرید، نه حجم بدهی را
پرسیدن «چند مورد بدهی داریم؟» تقریباً بی‌فایده است. سؤال درست این است: «کدام بخش‌ها امروز دارند بهره می‌گیرند؟» چند نشانهٔ عملی که می‌توانید بی‌درنگ بررسی کنید:
- یک تغییر کوچک در بخشی از سیستم، به تغییر در چند فایل پراکنده منجر می‌شود.
- تیم برای دست‌زدن به یک ماژول تعلل می‌کند و آن را «دست نزنیم بهتر است» می‌نامد.
- راه‌اندازی محیط توسعه یا استقرار، هر بار کار دستی و حافظه‌ای می‌خواهد.
- کارهای تکراری ماهانه وجود دارد که هیچ‌کس مالکشان نیست.
هر کدام از این‌ها یک جملهٔ دقیق در دفتر بدهی است؛ چیزی که می‌شود درباره‌اش تصمیم گرفت. «کیفیت کد پایین است» چیزی نیست که بشود تصمیم گرفت.
دفتر بدهی فنی: یک صفحه که خیلی چیزها را حل می‌کند
دفتر بدهی فنی (Technical Debt Register) لازم نیست ابزار تازه باشد. یک جدول ساده کافی است، به شرطی که هر ردیف این‌ها را داشته باشد:
- شرح یک‌خطی به زبان اثر روی کار، نه به زبان اصطلاح فنی.
- جای دقیق: ماژول، سرویس یا فرایند.
- دلیل ایجاد: عجله، نبود دانش، تغییر نیاز، وابستگی خارجی.
- هزینهٔ بازپرداخت: تخمین نسبی (کم، متوسط، زیاد) بهتر از ساعت دقیق است.
- نرخ بهره: چه کاری را کند یا پرریسک می‌کند.
- مالک و تاریخ بازبینی: بدهی بدون مالک، همان بدهی پنهان است.
این دفتر را در همان ابزاری نگه دارید که کارها را مدیریت می‌کنید — مثلاً در یک سامانهٔ تیکتینگ و مدیریت پروژه یک دستهٔ جدا برایش بسازید — تا بدهی در تصمیم‌های روزمره دیده شود و به فهرستی آرزومندانه در انتهای یک فایل تبدیل نشود.
چه وقت بدهی بگیریم و چه وقت پرداخت کنیم
دو فهرست کوتاه که در جلسهٔ برنامه‌ریزی به کار می‌آید:
بدهی بگیرید وقتی
- هدف یادگیری است و نتیجهٔ کار قرار است دور ریخته شود.
- بازخورد کاربر هنوز نیامده و ممکن است کل بخش حذف شود.
- معماری همان ناحیه در آیندهٔ نزدیک عوض می‌شود؛ بازپرداخت الان هدر است.
پرداخت کنید وقتی
- بهره از اصل بدهی گذشته است؛ هر تغییر جدید چند برابر زمان می‌برد.
- آن بخش از کد پایدار شده و مشتری واقعی دارد.
- قرار است قابلیت جدیدی روی همان ناحیه ساخته شود؛ قبل از افزودن، مرتب کنید.
- بدهی ریسک امنیتی یا از دست رفتن داده ایجاد کرده است؛ این دسته قابل تعویق نیست.
چهار راهبرد بازپرداخت در عمل
- بازپرداخت تدریجی: در هر اسپرینت سهم کوچکی برای بدهی‌های با نرخ بهرهٔ بالا کنار بگذارید. اگر این ظرفیت را در همان چرخهٔ کاری مدیریت پروژهٔ چابک جا ندهید، هرگز وقتش نمی‌رسد.
- پاک‌سازی همان ناحیه: هر کس وارد بخشی شد، آن را کمی بهتر از قبل ترک کند. این قانون کوچک، جلوی انبوه‌شدن بدهی را می‌گیرد.
- بازپرداخت به‌عنوان کار مستقل و کوچک: بدهی را به یک تغییر قابل بازبینی و قابل آزمون بشکنید؛ بازنویسی یک‌جا معمولاً به بدهی تازه تبدیل می‌شود.
- بازنویسی هدفمند، آخرین گزینه: تنها وقتی که ناحیهٔ موردنظر هم پرترافیک است، هم مالک روشنی دارد و هم آزمون‌های محافظ دارد.
جمع‌بندی
بدهی فنی با انکار حل نمی‌شود و با شعار «کد تمیز بنویسیم» هم مدیریت نمی‌شود. سه کار کوچک بیشتر لازم نیست: هر میان‌بُر را در یک دفتر ثبت کنید، برایش نرخ بهره بنویسید و در هر چرخهٔ کاری، بخشی از ظرفیت را به گران‌ترین ردیف‌ها بدهید. تیمی که بدهی‌هایش را می‌شناسد، آزادانه‌تر می‌تواند بدهی تازه بگیرد؛ تیمی که نمی‌شناسد، فقط می‌تواند امیدوار باشد.
