بدهی فنی وایب کدینگ؛ چه چیزی را بعداً باید پس بدهید

بدهی فنی (technical debt) یک استعارهٔ مالی ساده دارد: هر بار که یک راه‌حل سریع را به‌جای راه‌حل درست انتخاب می‌کنید، مثل این است که وام گرفته‌اید. وام کار امروز را راه می‌اندازد، اما بهره‌اش — زمان بیشتر برای فهمیدن کد، ریسک بیشتر برای هر تغییر، احتمال بالاتر باگ — هر ماه اضافه می‌شود. وایب کدینگ سرعت وام گرفتن را چند برابر می‌کند؛ این خودش بد نیست، اگر بدانید چقدر وام دارید و کِی قرار است پسش بدهید. در راهنمای کامل وایب کدینگ دربارهٔ شروع درست این روش نوشتیم؛ اینجا دربارهٔ چیزی صحبت می‌کنیم که آن روش پشت سر جا می‌گذارد.

بدهی فنی یعنی چه، به زبان ساده

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

چهار نوع بدهی که وایب کدینگ تولید می‌کند

۱. بدهی درک (Comprehension Debt)

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

۲. بدهی معماری (Architecture Debt)

هر بار که یک feature جدید بدون توجه به ساختار کلی پروژه اضافه می‌شود، فاصلهٔ بین «چطور باید باشد» و «چطور واقعاً هست» بیشتر می‌شود. هزینه‌اش در آینده به شکل refactoring‌های بزرگ و پرریسک ظاهر می‌شود؛ کاری که اگر زودتر انجام می‌شد، چند ساعت طول می‌کشید، حالا چند هفته می‌طلبد.

۳. بدهی تست (Test Debt)

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

۴. بدهی امنیتی (Security Debt)

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

هزینهٔ هرکدام در عمل

چرا نادیده گرفتن بدهی گران‌تر تمام می‌شود

بدهی فنی، برخلاف بدهی مالی، بهرهٔ ثابتی ندارد؛ بهره‌اش با هر feature جدیدی که روی همان بخش سوار می‌شود، بیشتر می‌شود. یک تابع غول‌پیکر که امروز فقط کمی سخت‌فهم است، بعد از چند بار افزودن منطق جدید به آن، به بخشی تبدیل می‌شود که هیچ‌کس جرأت لمسش را ندارد. همین موضوع دربارهٔ بدهی امنیتی هم صادق است: هرچه یک آسیب‌پذیری بیشتر در کد بماند، احتمال این‌که در یک بخش دیگر هم تکرار شده باشد بیشتر می‌شود.

یک مثال کوچک از ثبت بدهی

فرض کنید از هوش مصنوعی خواسته‌اید یک تابع برای محاسبهٔ تخفیف بنویسد و فعلاً فقط برای یک نوع مشتری تست شده است. به‌جای این‌که این محدودیت را در ذهن نگه دارید و امیدوار باشید یادتان بماند، همان لحظه آن را مستند کنید:

// TODO(بدهی تست): فقط برای مشتری عادی تست شده
// قبل از فعال کردن برای مشتری VIP و سازمانی، تست اضافه شود
function calculateDiscount(customer, order) {
  if (customer.type === "regular") {
    return order.total * 0.05;
  }
  return 0;
}

این یک کامنت دو خطی، تفاوت بزرگی ایجاد می‌کند: هر کسی که بعداً این تابع را برای مشتری VIP فراخوانی کند، فوراً می‌فهمد که وارد قلمرو تست‌نشده شده است. بدون این علامت، همان اشتباه ممکن است ماه‌ها بعد، در production، کشف شود.

چطور بدهی را عمدی و ثبت‌شده نگه داریم

بدهی فنی مشکل نیست؛ بدهی پنهان مشکل است. تیم‌هایی که با وایب کدینگ خوب کار می‌کنند، معمولاً این عادت‌ها را دارند:

• هر بار که یک راه‌حل سریع را انتخاب می‌کنید، یک خط کامنت یا یک آیتم در backlog با عنوان روشن ثبت کنید (مثلاً «TODO: این تابع نیاز به تست دارد»).
• پیش از شروع sprint بعدی، لیست بدهی‌ها را مرور کنید و حداقل یکی-دو مورد را پرداخت کنید.
• بدهی امنیتی و بدهی مربوط به منطق پرداخت یا داده‌های حساس را همیشه در اولویت بالاتر از بقیه قرار دهید.
• یک قاعدهٔ ساده تعیین کنید: هیچ feature جدیدی روی بخشی از کد که بدهی تست دارد سوار نشود، مگر این‌که ابتدا تست پایه اضافه شود.

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

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

جمع‌بندی

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