موضوع مقاله: بدهی فنی | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # بدهی فنی | مقدمه: بدهی فنی (همچنین به عنوان بدهی طراحی یا بدهی کد شناخته می‌شود) مفهومی در توسعه نرم‌افزار است که نشان دهنده هزینه ضمنی کار اضافی ناشی از انتخاب یک راه حل آسان (محدود) در زمان حال به جای استفاده از یک رویکرد بهتر است که طولانی‌تر خواهد بود. | ## بخش 1: بدهی فنی | اگر بدهی فنی بازپرداخت نشود، می‌تواند «بهره» را ایجاد کند، و اجرای آتی تغییرات را سخت‌تر می‌کند. از سوی دیگر، برخی کارشناسان ادعا می‌کنند استعاره «بدهی فنی» تمایل به حداقل رساندن تأثیراتی دارد، که منجر به اولویت بندی کافی در کارهای لازم برای اصلاح آن می‌شود. با شروع تغییر در یک کدبندی، اغلب نیاز به ایجاد تغییرات هماهنگ به‌طور هم‌زمان در سایر قسمتهای پایه کد یا مستندات وجود دارد. تغییرات مورد نیاز که تکمیل نشده‌اند بدهی در نظر گرفته می‌شوند که باید در مقطعی از آینده پرداخت شود. دقیقاً مانند بدهی مالی، این تغییرات ناتمام روی هم انباشته شده و ساخت یک پروژه را دشوار می‌کند. اگرچه این اصطلاح در توسعه نرم‌افزار به‌طور عمده استفاده می‌شود، اما می‌تواند در سایر حرفه‌ها نیز کاربرد داشته باشد. برای درک بهتر مفهوم بدهی فنی، فرض کنید برای شروع یک پروژه نرم افزاری می‌خواهید یک تیم برنامه نویسی را کنار هم جمع کنید. در این حالت ممکن است به دلیل محدودیت بودجه افرادی را استخدام کنید که فاقد مهارت کافی هستند. در نهایت، نتیجه نرم افزاری می‌شود که از لحاظ ویژگی‌ها و کیفیت به پای رقبا نمی‌رسد. در چنین حالتی ممکن است برای رسیدن به جایگاه مناسب در بازار مجبور شوید این بدهی را با هزینه دوباره برای طراحی نرم افزار یا بازسازی کد پرداخت کنید. علل دلایل عمده بدهی فنی شامل موارد زیر است: تعریف ناکافی از چشم‌انداز کار، جایی که هنوز الزامات در طول توسعه تعریف می‌شود، توسعه قبل از انجام هرگونه طراحی شروع می‌شود. این کار برای صرفه جویی در وقت انجام می‌شود اما اغلب در آینده نیاز به دوباره کاری می‌شود. فشارهای بیزینسی، جایی که بیزینس در نظر دارد زودتر از اتمام همه تغییرات لازم، محصول را منتشر کند، بدهی فنی‌ای را تشکیل می‌دهد که شامل تغییرات ناقص است. | ## بخش 2: بدهی فنی | عدم پردازش یا تفاهم، در شرایطی که کسب‌وکارها مفهوم بدهی فنی را نمی‌دانند و بدون در نظر گرفتن پیامدهای آن تصمیم‌گیری می‌کنند. کامپوننت‌های به هم تنیده، در صورتی که سیستم‌ها ماژولار نباشند، نرم‌افزار به اندازه کافی انعطاف‌پذیر نیست تا بتواند با نیازهای تجاری سازگار شود. کار برای ایجاد هرگونه مستندات پشتیبانی در آینده، بیانگر بدهی است که باید پرداخت شود. عدم همکاری، در جایی که دانش در مورد سازمان به اشتراک گذاشته نمی‌شود و کارایی کسب‌وکار پایین است، یا توسعه دهندگان کم تجربه به درستی راهنمایی و مربیگری نمی‌شوند. توسعه موازی در دو یا چند برنچ به دلیل کار مورد نیاز برای ادغام تغییرات در یک منبع واحد، بدهی فنی را ایجاد می‌کند. تأخیر در ریفکتورینگ، از آنجا که الزامات یک پروژه در حال تحول است، ممکن است مشخص شود که قسمت‌هایی از کد ناکارآمد یا نگهداری آن دشوار شده‌است و برای پشتیبانی از نیازهای آینده باید مورد بازبینی قرار داده شود. هرچه این موضوع مدت طولانی‌تری به تأخیر انداخته شود و کد بیشتری اضافه شود، بدهی نیز بیشتر می‌شود. عدم مطابقت با استانداردها، جایی که ویژگی‌های استاندارد صنعت، فریم‌ورک‌ها و فناوری‌ها نادیده گرفته می‌شوند. عدم مالکیت، هنگامی که تلاش‌های برون سپاری بخشی از کارها منجر به این می‌شود که تیم داخلی نیاز به ریفکتورینگ یا بازنویسی کد برون سپاری شده را پیدا می‌کند. رهبری ضعیف فنی، زمانی که تیم از مدیریت فنی ضعیفی برخوردار باشد بدهی‌های فنی افزایش می‌یابد. تغییرات لحظه آخری در نیازمندی‌ها، این امکان وجود دارد که در طول یک پروژه برای اعمال تغییرات تحت فشار قرار بگیریم اما زمان‌بندی و بودجه بندی مناسب برای پیاده‌سازی آن‌ها در نظر گرفته نشود + ربع فنی بدهی بی پروا محتاطحساب شده "ما زمان برای طراحی نداریم" "باید اکنون منتشر کنیم و با عواقب آن رو به رو شویم (بعداً)"ناخواسته "لایه بندی چیست؟" "اکنون می‌دانیم که چگونه باید این کار را می‌کردیم" مارتین فاولر در یک پست بلاگ خود چهار نوع بدهی را بر اساس دو دسته متمایز متمایز می‌کند: دسته اول بی پروا در مقابل محتاط، دسته دوم، حساب شده در مقابل ناخواسته. خدمت یا بازپرداخت بدهی فنی کنی روبین از دسته‌بندی‌های وضعیت زیر استفاده می‌کند: بدهی فنی به اتمام رسیده‌است - بدهی که تیم توسعه از پرداخت آن بی‌خبر بودند. به عنوان مثال، تیم ویژگی جدیدی را به محصول اضافه می‌کند و پس از پایان کار می‌فهمد که مدت‌ها قبل این ویژگی توسط شخصی که مدت‌هاست از آنجا خارج شده‌است، در سیستم پیاده‌سازی شده‌است. | ## بخش 3: بدهی فنی | بدهی فنی شناخته شده - بدهی که برای تیم توسعه شناخته شده‌است و با استفاده از یکی از روش‌های مطرح شده، قابل مشاهده است. بدهی فنی هدفمند - بدهی که شناخته شده‌است و توسط تیم توسعه جهت سرویس دهی در نظر گرفته شده‌است. عواقب «پرداخت بهره» هم به دلیل نگهداری‌های محلی و هم به دلیل عدم نگهداری سایر کاربران پروژه ایجاد می‌شود. توسعه مداوم در پروژه‌های اصلی می‌تواند هزینه پرداخت بدهی فنی را در آینده افزایش دهد. بسیار دشوار است که میزان دقیق کاری که برای پرداخت بدهی که با بروز هر تغییر ایجاد می‌شود را محاسبه کرد. اگر کار کافی روی پروژه انجام شود تا مانع شکست آن شود، باز هم پروژه‌ای منتشر می‌شود که هنوز هم مقدار قابل توجهی بدهی فنی به همراه دارد. اگر این نرم‌افزار به تولید برسد، خطرات مربوط به اجرای هر گونه ریفکتور آتی برای برطرف کردن بدهی فنی را، به طرز چشمگیری افزایش می‌دهد. در صورتی که قراردادهای تولید نرم‌افزار شامل توافقات سطح خدمات (SLA) باشند، تغییر کد تولید خطر از کارافتادن، خسارات مالی و احتمالاً پیامدهای قانونی را به همراه خواهد داشت. به همین دلیل می‌توانیم تقریباً بدهی فنی به عنوان بدهی را افزایش داده و شاهد افزایش نرخ بهره باشیم و تنها زمانی این بدهی کاهش می‌یابد که توسعه محصول متوقف شود. در حالی که قانون مانی لمن پیش از این اعلام کرده بود که برنامه‌های در حال توسعه به‌طور مداوم بر پیچیدگی و ساختار رو به زوال آنها افزوده می‌شود مگر اینکه برای حفظ آنها کاری انجام شود، وارد کانینگهام در ۱۹۹۲ گزارشی از تجربه مقایسه بین پیچیدگی فنی و بدهی را ترسیم کرد: جوشوا کریایفسکی در متن خود در سال ۲۰۰۴ با عنوان Refactoring to Models، استدلال قابل مقایسه ای را در رابطه با هزینه‌های مرتبط با سهل انگاری در معماری ارائه می‌دهد، که او آن را «بدهی طراحی» توصیف می‌کند. فعالیتهایی که ممکن است به تعویق افتد شامل مستندسازی، نوشتن تست‌ها، مشخص کردن TODOها و نادیده‌گرفتن هشدارهای تحلیل کد استاتیک و کامپایلر است. موارد دیگر بدهی فنی شامل دانش است که در سازمان به اشتراک گذاشته نمی‌شود و کدهایی که بسیار گیج کننده بوده به راحتی اصلاح نمی‌شود. جوناد علی با نوشتن مقاله‌ای دربارهٔ توسعه PHP در سال ۲۰۱۴ گفت: گرادی بوچ مقایسه می‌کند که چگونه شهرهای در حال تحول شبیه به سیستم‌های در حال تحول نرم‌افزاری هستند و چگونه عدم مقاوم‌سازی می‌تواند به بدهی فنی منجر شود. | ## جمع‌بندی | در نرم‌افزار منبع باز، به تعویق انداختن ارسال تغییرات محلی به پروژه بالادستی نوعی بدهی فنی است.