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