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

سرنوشت دوام بلندمدت یک پروژه نرم‌افزاری نه در طول طرح‌های بزرگ بازنویسی کد (Refactoring) یا بررسی‌های معماری، بلکه دقیقاً در همان لحظه‌ای رقم می‌خورد که یک توسعه‌دهنده یک «راه‌حل سریع» را روی شاخه اصلی (Main Branch) ثبت می‌کند.

این گام واحد — یعنی بده‌بستان آگاهانه بین عرضه یک ویژگی در امروز و پرداخت بهره این میان‌بر در فردا — همان جایی است که بدهی فنی در واقع ضرب می‌شود. این همان تصمیم تعیین‌کننده‌ای است که مشخص می‌کند آیا یک پایگاه کد به‌راحتی مقیاس‌پذیر خواهد بود یا در نهایت زیر وزن خودش فرو می‌ریزد.[6]

خود این اصطلاح اغلب توسط بخش‌های بازاریابی برای فروش ابزارهای خودکار اسکن کد مصادره می‌شود؛ با این فضاسازی که هر کد ناقصی یک شکست فاجعه‌بار مهندسی است. اما در عمل، بدهی فنی یک ابزار اقتصادی حساب‌شده است. این استعاره که در سال ۱۹۹۲ توسط مهندس نرم‌افزار، وارد کانینگهام (Ward Cunningham) ابداع شد، توضیح می‌دهد که چگونه تیم‌های مهندسی برای انتشار نرم‌افزار پیش از بسته‌شدن پنجره فرصت بازار، زیر بار بدهی می‌روند؛ درست شبیه استارتاپی که برای تصاحب سهم اولیه بازار، بدهی مالی بالا می‌آورد.[4]

این سازوکار کاملاً بر پیش‌خور کردن هزینه‌های بازسازی آینده استوار است. اگر تیمی با نادیده گرفتن یک مهاجرت اصولی پایگاه داده، امروز ۲ هفته در زمان توسعه صرفه‌جویی کند، در واقع دارد از آینده خودش زمان قرض می‌گیرد. اصل این وام، هزینه بازنویسی بعدی کدها برای رسیدن به استاندارد مناسب است. بهره آن نیز زمان اضافه‌ای است که در این فاصله برای ساخت هر ویژگی جدید روی آن پایه شکننده صرف می‌شود.[1]

نشریه CIO در تحلیلی در سال ۲۰۲۰ از رویه‌های نرم‌افزاری سازمانی خاطرنشان می‌کند: «بدهی فنی یک ریسک تجاری است که واحد فناوری اطلاعات باید آن را مدیریت کند.» اگر پرداخت‌های بهره — یعنی اصطکاک روزمره کار با کدهای شکننده — از ارزش به‌دست‌آمده بابت عرضه زودهنگام فراتر رود، پروژه وارد وضعیت ورشکستگی فنی می‌شود. در آن نقطه، تقریباً ۱۰۰ درصد از تلاش مهندسی به‌جای نوآوری، صرف نگهداری می‌شود.[5]

برای درک چگونگی انباشت این بدهی، صنعت نرم‌افزار به‌شدت به «ماتریس بدهی فنی» متکی است؛ چارچوبی که در سال ۲۰۰۹ توسط مارتین فاولر (Martin Fowler) معرفی شد. این ماتریس، بده‌بستان‌های مهندسی را در ۲ محور متقاطع به ۴ نوع متمایز دسته‌بندی می‌کند: بی‌پروا در برابر محتاط، و عمدی در برابر سهوی.[1]

بدهی محتاطانه و عمدی زمانی رخ می‌دهد که تیم دقیقاً می‌داند چه چیزی را و به چه دلیلی فدا می‌کند. آن‌ها ممکن است برای رسیدن به ضرب‌الاجل روز جمعه، یک پیکربندی را در کد هاردکد (Hardcode) کنند، با این نیت کامل که دوشنبه بعد یک مدیر پیکربندی پویا بسازند. این معادل یک وام کوتاه‌مدت و حساب‌شده است.[1]

در مقابل، بدهی بی‌پروا و سهوی زمانی اتفاق می‌افتد که تیم تجربه کافی برای درک این موضوع ندارد که در حال نوشتن کدهای غیرقابل نگهداری است. آن‌ها یک بده‌بستان استراتژیک انجام نمی‌دهند؛ بلکه صرفاً در حال اشتباه کردن هستند. این شکل از بدهی دارای نرخ بهره متغیری است که به‌طور غیرقابل پیش‌بینی مرکب می‌شود و اغلب زمانی که معماری در نهایت در هم می‌شکند، به بازنویسی کامل سیستم نیاز پیدا می‌کند.[1]

یک مطالعه میدانی که توسط موسسه مهندسی نرم‌افزار دانشگاه کارنگی ملون (CMU) انجام شد، نشان داد که این مدل‌های نظری چگونه در محیط‌های واقعی تولید (Production) خود را نشان می‌دهند. محققان دریافتند که توسعه‌دهندگان بخش عظیمی از ساعات کاری خود را صرفاً برای کلنجار رفتن با پیچیدگی‌های ناشی از میان‌برهای گذشته صرف می‌کنند، نه نوشتن منطق جدید.[3]

این مطالعه برجسته کرد که موذی‌ترین شکل بدهی فنی، کدهای بد نوشته‌شده نیست، بلکه معماری با هم‌راستایی ضعیف است. وقتی طراحی بنیادین یک سیستم دیگر با نیازمندی‌های تجاری که به آن‌ها خدمت می‌کند مطابقت نداشته باشد، هر ویژگی جدید به یک راه‌حل موقت (Workaround) نیاز دارد. این ناهماهنگی‌های معماری مانند یک مالیات دائمی بر تمام چرخه‌های توسعه آینده عمل می‌کنند.[3]

شرکت مکنزی (McKinsey & Company) این چالش را به‌عنوان نیازی برای بازپس‌گیری «ارزش ویژه فناوری» (Tech Equity) چارچوب‌بندی می‌کند. در تحلیل آن‌ها، سازمان‌هایی که فعالانه بدهی فنی خود را مدیریت و پرداخت می‌کنند، می‌توانند یک مالیات ۱۰ تا ۲۰ درصدی بر منابع توسعه را از بخش نگهداری، دوباره به سمت نوآوری هدایت کنند.[2]

با این حال، نگاه بدبینانه به این معیار این است که کمّی‌سازی «ارزش ویژه فناوری» در ترازنامه شرکت‌ها به‌شدت دشوار است. برخلاف بدهی مالی، بدهی فنی صورت‌حساب ماهانه ندارد. هزینه‌های آن در چرخه‌های انتشار به تأخیر افتاده، روحیه پایین توسعه‌دهندگان و افزایش دفعات قطعی سیستم در محیط تولید که کاربران نهایی را ناامید می‌کند، پنهان است.[2]

گذار از استعاره به نظریه رسمی، تمرکز محققان دانشگاهی بوده است. نشریه IEEE Software در سال ۲۰۱۲ یک مطالعه بنیادین منتشر کرد که تلاش می‌کرد نحوه اندازه‌گیری بدهی فنی را استاندارد کند و از شکایات ذهنی توسعه‌دهندگان فراتر رفته و به معیارهای عینی مانند پیچیدگی سایکلوماتیک (Cyclomatic Complexity) و ریزش کد (Code Churn) برسد.[4]

با این وجود، پیشرفته‌ترین ابزارهای اندازه‌گیری هم نمی‌توانند جایگزین تصمیم بنیادین اقتصادی شوند. انتخابِ زیر بار بدهی رفتن، یک تصمیم تجاری است، نه صرفاً یک تصمیم فنی. اگر بودجه یک استارتاپ تمام شود چون ۶ ماه را صرف بی‌نقص کردن معماری محصولی کرده‌اند که هیچ‌کس آن را نمی‌خواست، پایگاه کد دست‌نخورده و تمیز آن‌ها کاملاً بی‌ارزش است.[5]

ایستگاه قابل‌بررسی بعدی برای این صنعت، ادغام دستیارهای کدنویسی هوش مصنوعی مولد است. از آنجا که این مدل‌ها سرعت نوشتن کد را به‌طرز چشمگیری افزایش می‌دهند، هم‌زمان سرعت تولید بدهی فنی سهوی را نیز بالا می‌برند. اینکه آیا این ابزارها در نهایت به‌عنوان موتورهای خلق بدهی عمل خواهند کرد یا راه‌حل‌های خودکار بازنویسی کد، پرسش مرکزی ۱۰ سال آینده مهندسی نرم‌افزار باقی می‌ماند.[6]