بدهی فنی چیست؟ چرا ارزانترین پروژه ممکن است گرانترین پروژهی شما شود
بدهی فنی (Technical Debt) هزینهی پنهان میانبُرهای امروز است که فردا با بهره پس داده میشود. انواع آن، نشانهها و راههای مدیریتش را بشناسید.
حتماً این جمله را شنیدهاید: «فعلاً سریع درستش کن، بعداً مرتبش میکنیم.» گاهی این تصمیم کاملاً درست است. اما اگر «بعداً» هیچوقت نرسد، هر تغییر بعدی کمی کندتر، کمی گرانتر و کمی پرخطرتر میشود. به این هزینهی انباشته میگویند بدهی فنی.
بدهی فنی یعنی چه؟
اصطلاح بدهی فنی (Technical Debt) را وارد کانینگهام، از پیشگامان توسعهی نرمافزار، در اوایل دههی ۱۹۹۰ مطرح کرد. استعارهاش دقیق است: وقتی برای رسیدن سریعتر، راهحلی سرهمبندیشده را انتخاب میکنید، در واقع وام گرفتهاید. زمانی که امروز صرفهجویی کردید، اصل وام است. و هر بار که به آن بخش از کد برمیگردید و بهخاطر آشفتگیاش وقت بیشتری صرف میکنید، دارید بهره میدهید.
مثل هر وامی، بدهی فنی ذاتاً بد نیست. مشکل از جایی شروع میشود که نه کسی بداند چقدر بدهکار است و نه برنامهای برای بازپرداخت وجود داشته باشد.
چهار نوع بدهی فنی
مارتین فاولر بدهی فنی را با دو پرسش دستهبندی میکند: آیا آگاهانه بود؟ و آیا محتاطانه بود؟
| آگاهانه | ناآگاهانه | |
|---|---|---|
| بیپروا | «وقت طراحی نداریم، همینطوری بنویس.» | «جداسازی لایهها دیگر چیست؟» |
| محتاطانه | «الان منتشر میکنیم و هزینهاش را میدانیم.» | «حالا که ساختیم، فهمیدیم باید چطور میساختیم.» |
بدهی آگاهانه و محتاطانه ابزار مشروع کسبوکار است؛ مثلاً وقتی یک MVP را برای سنجیدن بازار سریع منتشر میکنید. بدهی بیپروا تقریباً همیشه ناشی از عجلهی بیحساب یا کمبود مهارت است و گران تمام میشود.
نشانههای اینکه پروژهی شما زیر بار بدهی است
- تغییرهای کوچک که قبلاً یک روز طول میکشیدند، حالا یک هفته طول میکشند.
- رفع یک باگ، دو باگ جدید در جای دیگری میسازد.
- تیم از دست زدن به بخشهایی از کد میترسد و جملهی «به آن قسمت دست نزنید» زیاد شنیده میشود.
- برنامهنویس جدید هفتهها طول میکشد تا بتواند کار مفیدی انجام دهد.
- برآورد زمان کارها مدام غلط از آب درمیآید.
- پیشنهاد «باید از اول بنویسیمش» مدام تکرار میشود.
چرا ارزانترین پیشنهاد اغلب گرانتر تمام میشود
فرض کنید برای یک سامانهی سفارشگیری دو پیشنهاد دارید. اولی ارزانتر است چون تست ندارد، ساختار کد را فدای سرعت کرده و مستندی تحویل نمیدهد. دومی کمی گرانتر است ولی همهی اینها را دارد. روز تحویل هر دو دقیقاً یک کار را انجام میدهند.
تفاوت در ماههای بعد پیدا میشود. هر قابلیت جدید روی پیشنهاد اول چند برابر زمان میبرد، باگها بیشترند و اگر بخواهید تیم را عوض کنید، تیم جدید احتمالاً پیشنهاد بازنویسی میدهد. در عمل، قیمت واقعی نرمافزار قیمت ساختش نیست؛ قیمت ساختن بهعلاوهی تمام تغییرهای بعدی است.
MVP و بدهی فنی: سرعت بدون شلختگی
یک سوءتفاهم رایج این است که MVP یعنی کد بیکیفیت. اینطور نیست. MVP دربارهی تعداد قابلیتهاست، نه کیفیت آنها. MVP خوب کوچک است، اما پایهاش درست ریخته شده: ساختار روشن، کد خوانا، تست مسیرهای اصلی و امکان گسترش. سرعت را باید از حذف قابلیتهای غیرضروری به دست آورد، نه از کم گذاشتن روی پایه.
بدهی فنی را چطور مدیریت کنیم؟
۱. آن را قابل دیدن کن
هر میانبُر آگاهانه را همان لحظه ثبت کن: کجاست، چرا زده شد و جبرانش حدوداً چقدر کار دارد. بدهی ثبتشده را میشود مدیریت کرد؛ بدهی نامرئی فقط رشد میکند.
۲. بخشی از هر دوره را برای بازپرداخت کنار بگذار
بسیاری از تیمها بخش ثابتی از زمان هر دورهی کاری (معمولاً حدود پانزده تا بیست درصد) را صرف بهبود کد موجود، یعنی ریفکتور، میکنند. این کار از انباشته شدن بهره جلوگیری میکند.
۳. قانون پیشاهنگی
«کد را کمی تمیزتر از وقتی که تحویلش گرفتی ترک کن.» هر بار که به بخشی از کد دست میزنی، یک بهبود کوچک هم انجام بده: یک نام بهتر، یک تابع شکستهشده، یک تست اضافه.
۴. با تست از خودت محافظت کن
بدون تست خودکار، ریفکتور کردن ترسناک است و ترس باعث میشود بدهی هرگز پرداخت نشود. تستها اجازه میدهند با اطمینان کد را بهتر کنی.
۵. بازنویسی کامل، آخرین گزینه
بازنویسی از صفر وسوسهانگیز است ولی معمولاً از آنچه فکر میکنید طولانیتر و پرخطرتر است. در بیشتر موارد، بهبود تدریجی بخشبهبخش راه امنتری است.
جمعبندی
بدهی فنی نه دشمن است و نه چیزی که بشود کاملاً از آن فرار کرد. ابزاری است که باید آگاهانه و با حسابوکتاب از آن استفاده کرد. تیم خوب کسی نیست که هیچوقت میانبُر نمیزند؛ کسی است که میداند کدام میانبُر ارزشش را دارد، ثبتش میکند و بهموقع جبرانش میکند.