بدهی فنی – Technical debt

هر کسی تمام تلاش خود را می کند تا بهترین کد را از ابتدا بنویسد. احتمالاً هیچ برنامه نویسی نیست که عمداً کد ناخوشایند و به ضرر پروژه بنویسد. اما در چه مرحله ای کد تمیز، کثیف می شود؟

استعاره “بدهی فنی” در مورد کد بد در ابتدا توسط Ward Cunningham پیشنهاد شده.

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

همین اتفاق می تواند با کد رخ دهد. شما می توانید به طور موقت بدون نوشتن تست برای ویژگی های جدید، به کار سرعت بخشید ، اما این کار به تدریج هر روز پیشرفت شما را کند می کند تا اینکه در نهایت با نوشتن تست ها بدهی خود را پرداخت کنید.

علل بروز بدهی فنی

فشار بیزنس

بعضی اوقات شرایط تجاری ممکن است شما را وادار کند فیچر های خود را قبل از اتمام کار ارائه کنید. در این حالت تکه های ناجوری در کد ظاهر می شوند تا اتمام پروژه مخفی می شود.

عدم درک عواقب بدهی فنی

صرف نظر از درک بدهی فنی، گاهی اوقات کارفرمای شما ممکن است درک نکند که بدهی فنی باعث کاهش بهره وری می شود. این  موضوع می تواند اختصاص دادن زمان تیم را به refactoring بسیار دشوار کند زیرا مدیریت ارزش آن را نمی بیند.

عدم موفقیت در برابر انسجام دقیق اجزاء

در شرایطی این پروژه به جای ماژولهای انفرادی شبیه به یک تکه سنگ یکپارچه باشد، هرگونه تغییر در یک قسمت از پروژه ، بخش های دیگر را تحت تأثیر قرار می دهد. در این حالت کار بسیار دشوار تر است زیرا جدا کردن این اجزاء از هم خیلی سخت است.

نبود تست

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

نبود مستند سازی

این امر باعث بروز مشکل در معرفی افراد جدید به پروژه می شود و در صورت ترک افراد اصلی پروژه توسعه متوقف خواهد شد.

عدم تعامل بین اعضای تیم

اگر پایگاه دانش در سراسر شرکت توزیع نشود ، افراد در نهایت با درک قدیمی از روندها و اطلاعات مربوط به پروژه کار می کنند. این وضعیت زمانی می تواند تشدید شود که توسعه دهندگان جدید به طور نادرست توسط مربیان خود آموزش ببینند.

توسعه همزمان و طولانی مدت در برنچ های(Branches) مختلف

این امر می تواند به انباشت بدهی فنی منجر شود ، که در هنگام ادغام تغییرات(Merge) افزایش می یابد. هرچه تغییرات بیشتر توسط اعضای تیم بصورت منفرد (Isolated) انجام شود کل بدهی فنی بیشتر می شود.

تأخیر در اصلاح کد(Refactoring ریفکتور)

الزامات پروژه به طور مداوم در حال تغییر است و ممکن است در بعضی مواقع مشخص شود که قسمت هایی از کد منسوخ و دست و پا گیر شده اند و برای برآورده کردن نیازهای جدید باید دوباره طراحی شوند.

از طرف دیگر ، برنامه نویسان پروژه هر روز کدهای جدید می نویسند که با قسمتهای منسوخ کار می کند. بنابراین ، هرچه تأخیر بیشتر به تأخیر بیفتد ، در آینده کدهای وابسته تری داریم که نیاز به ریفکتور (اصلاح) دارند.

نبود نظارت بر تطابق

وقتی که هر کسی بر روی پروژه بر طبق روش خودش کد نویسی را ادامه دهد این اتفاق خواهد افتاد و کدها یکدست نخواهند شد.

بی کفایتی

در شرایطی که توسعه دهنده واقعا نمی داند چگونه کد مناسبی را بنویسد و در واقع توان فنی لازم را ندارد.

منبع