بدهی فنی: چه زمانی آن را بپذیریم و چه زمانی نه

بدهی فنی از آن اصطلاح‌هایی است که همه استفاده می‌کنند و هر کس معنای خودش را از آن دارد. برای بعضی هر کدی که دوست ندارند بدهی فنی است. برای بعضی دیگر بهانه‌ای است برای بازنویسی هر چیز.

تعریف دقیق‌تر این است: هزینه‌ی آینده‌ای که امروز برای سریع‌تر رسیدن پذیرفته‌اید.

تشبیه وام

بدهی فنی مثل وام است. وام به خودی خود بد نیست. اگر با آن چیزی بخرید که ارزش می‌سازد و بتوانید قسطش را بدهید، تصمیم خوبی بوده است. مشکل از سه جا شروع می‌شود:

• ندانید که وام گرفته‌اید.
• برنامه‌ای برای بازپرداخت نداشته باشید.
• بهره آن‌قدر بالا برود که همه‌ی درآمدتان صرف آن شود.

در نرم‌افزار، «بهره» همان کند شدن تدریجی هر تغییر جدید است.

دو نوع بدهی

بدهی آگاهانه. تصمیم گرفته‌اید چیزی را ساده‌تر بسازید تا زودتر به بازار برسید، می‌دانید چه چیزی را فدا کرده‌اید و ثبتش کرده‌اید. مثلاً: «فعلاً گزارش‌ها هر شب ساخته می‌شوند، نه لحظه‌ای. اگر کاربران بیشتر شدند، عوضش می‌کنیم.»

بدهی ناخواسته. از بی‌دقتی، عجله یا نبود طراحی می‌آید. کسی تصمیمی نگرفته؛ فقط اتفاق افتاده است. این نوع خطرناک است، چون دیده نمی‌شود تا وقتی که گران شده باشد.

چه زمانی پذیرفتن بدهی منطقی است

• هنوز نمی‌دانید محصول جواب می‌دهد یا نه. صرف هفته‌ها برای کامل کردن چیزی که شاید دور ریخته شود، خودش اتلاف است.
• ساده‌سازی پشت یک مرز درست قرار دارد. اگر بخش ساده‌شده را بشود بعداً بدون دست زدن به بقیه عوض کرد، بدهی ارزان است.
• مهلت واقعی دارید. نه مهلت خیالی؛ رویداد یا تعهدی که واقعاً قابل جابه‌جایی نیست.

چه زمانی نباید بدهی بگیرید

بعضی بدهی‌ها بهره‌ی بسیار بالایی دارند و تقریباً هیچ‌وقت نمی‌ارزند:

• امنیت و داده‌ی کاربر. «بعداً امنش می‌کنیم» یعنی یک حادثه در راه است. ببینید: امنیت از روز اول.
• مدل داده‌ی اصلی. اصلاح ساختار داده بعد از جمع شدن داده‌ی واقعی، دردناک و پرریسک است.
• مرزهای سامانه. اگر ماژول‌ها در هم بروند، جدا کردنشان یعنی بازنویسی.
• نبود هر گونه آزمون برای منطق حیاتی. بدون آزمون، هر تغییر بعدی قمار است.

بدهی را مکتوب کنید

بدهی‌ای که نوشته نشود، به بدهی ناخواسته تبدیل می‌شود. برای هر بدهی آگاهانه سه چیز را ثبت کنید:

1. چه چیزی ساده شده است؟
2. چه نشانه‌ای می‌گوید وقت اصلاحش رسیده؟ مثلاً «وقتی تعداد کاربران هم‌زمان از فلان حد گذشت».
3. اصلاحش تقریباً چقدر کار دارد؟

بهترین جا برای این کار همان ثبت تصمیم معماری است.

بازپرداخت بدون توقف

اشتباه رایج این است که تیم بخواهد «دو ماه فقط بدهی صاف کند». این درخواست تقریباً هیچ‌وقت پذیرفته نمی‌شود و اگر هم بشود، محصول دو ماه بی‌حرکت می‌ماند.

روش بهتر:

• در مسیر کار اصلاح کنید. هر بار که روی بخشی کار می‌کنید، همان بخش را کمی تمیزتر تحویل دهید.
• سهم ثابت بگذارید. بخش مشخصی از هر دوره‌ی کاری به اصلاح اختصاص یابد.
• گران‌ترین بهره را اول بدهید. بخشی که بیشترین تغییر را می‌بیند و بیشترین کندی را می‌سازد، اولویت دارد. کد زشتی که کسی به آن دست نمی‌زند، می‌تواند صبر کند.

نشانه‌های اینکه بدهی از کنترل خارج شده

• تخمین هر کار ساده مدام بیشتر می‌شود.
• هر تغییر، چیز نامربوطی را خراب می‌کند.
• اعضای تیم از دست زدن به بخش‌هایی از کد می‌ترسند.
• نیروی جدید ماه‌ها طول می‌کشد تا مفید شود.

اگر این نشانه‌ها را می‌بینید، بحث بدهی دیگر فنی نیست؛ ریسک کسب‌وکار است.

جمع‌بندی

هدف، بدهی صفر نیست؛ بدهی دانسته است. بدهی‌ای که آگاهانه گرفته شده، مکتوب است و نشانه‌ی بازپرداختش مشخص است، ابزار سرعت است. بقیه، هزینه‌ای است که بی‌صدا رشد می‌کند.

مطلب مرتبط: لایه‌های قابل‌تعویض.