بدهی فنی
بدهی فنی (همچنین به عنوان بدهی طراحی[۱] یا بدهی کد شناخته می‌شود) مفهومی در توسعه نرم‌افزار است که نشان دهنده هزینه ضمنی کار اضافی ناشی از انتخاب یک راه حل آسان (محدود) در زمان حال به جای استفاده از یک رویکرد بهتر است که طولانی‌تر خواهد بود.[۲]
بدهی فنی را می‌توان با بدهی پولی مقایسه کرد.[۳] اگر بدهی فنی بازپرداخت نشود، می‌تواند «بهره» را ایجاد کند، و اجرای آتی تغییرات را سخت‌تر می‌کند. بدهی فنی آنتروپی نرم‌افزار را افزایش می‌دهد. بدهی فنی لزوماً چیز بدی نیست و گاهی اوقات (مانند موارد اثبات مفهوم یا proof-of-concept) بدهی فنی برای پیشبرد پروژه‌ها لازم است. از سوی دیگر، برخی کارشناسان ادعا می‌کنند استعاره «بدهی فنی» تمایل به حداقل رساندن تأثیراتی دارد، که منجر به اولویت بندی کافی در کارهای لازم برای اصلاح آن می‌شود.[۴][۵]
با شروع تغییر در یک کدبندی، اغلب نیاز به ایجاد تغییرات هماهنگ به‌طور هم‌زمان در سایر قسمتهای پایه کد یا مستندات وجود دارد. تغییرات مورد نیاز که تکمیل نشده‌اند بدهی در نظر گرفته می‌شوند که باید در مقطعی از آینده پرداخت شود. دقیقاً مانند بدهی مالی، این تغییرات ناتمام روی هم انباشته شده و ساخت یک پروژه را دشوار می‌کند. اگرچه این اصطلاح در توسعه نرم‌افزار به‌طور عمده استفاده می‌شود، اما می‌تواند در سایر حرفه‌ها نیز کاربرد داشته باشد.
برای درک بهتر مفهوم بدهی فنی، فرض کنید برای شروع یک پروژه نرم افزاری می‌خواهید یک تیم برنامه نویسی را کنار هم جمع کنید. در این حالت ممکن است به دلیل محدودیت بودجه افرادی را استخدام کنید که فاقد مهارت کافی هستند. در نهایت، نتیجه نرم افزاری می‌شود که از لحاظ ویژگی‌ها و کیفیت به پای رقبا نمی‌رسد. در چنین حالتی ممکن است برای رسیدن به جایگاه مناسب در بازار مجبور شوید این بدهی را با هزینه دوباره برای طراحی نرم افزار یا بازسازی کد پرداخت کنید.[۶]
علل[ویرایش]
دلایل عمده بدهی فنی شامل موارد زیر است:
- تعریف ناکافی از چشم‌انداز کار، جایی که هنوز الزامات در طول توسعه تعریف می‌شود، توسعه قبل از انجام هرگونه طراحی شروع می‌شود. این کار برای صرفه جویی در وقت انجام می‌شود اما اغلب در آینده نیاز به دوباره کاری می‌شود.
- فشارهای بیزینسی، جایی که بیزینس در نظر دارد زودتر از اتمام همه تغییرات لازم، محصول را منتشر کند، بدهی فنی‌ای را تشکیل می‌دهد که شامل تغییرات ناقص است. [۷] [۸]
- عدم پردازش یا تفاهم، در شرایطی که کسب‌وکارها مفهوم بدهی فنی را نمی‌دانند و بدون در نظر گرفتن پیامدهای آن تصمیم‌گیری می‌کنند.
- کامپوننت‌های به هم تنیده، در صورتی که سیستم‌ها ماژولار نباشند، نرم‌افزار به اندازه کافی انعطاف‌پذیر نیست تا بتواند با نیازهای تجاری سازگار شود.
- عدم وجود تست کیس‌ها، که برای تشخیص سریع مشکلات استفاده شود.
- عدم وجود مستندات، در جایی که کد بدون مستندات لازم پشتیبانی، ایجاد شود. کار برای ایجاد هرگونه مستندات پشتیبانی در آینده، بیانگر بدهی است که باید پرداخت شود.[۷]
- عدم همکاری، در جایی که دانش در مورد سازمان به اشتراک گذاشته نمی‌شود و کارایی کسب‌وکار پایین است، یا توسعه دهندگان کم تجربه به درستی راهنمایی و مربیگری نمی‌شوند.
- توسعه موازی در دو یا چند برنچ به دلیل کار مورد نیاز برای ادغام تغییرات در یک منبع واحد، بدهی فنی را ایجاد می‌کند. هرچه تغییرات بیشتر در انزوا انجام شود، بدهی بیشتری جمع می‌شود.
- تأخیر در ریفکتورینگ، از آنجا که الزامات یک پروژه در حال تحول است، ممکن است مشخص شود که قسمت‌هایی از کد ناکارآمد یا نگهداری آن دشوار شده‌است و برای پشتیبانی از نیازهای آینده باید مورد بازبینی قرار داده شود. هرچه این موضوع مدت طولانی‌تری به تأخیر انداخته شود و کد بیشتری اضافه شود، بدهی نیز بیشتر می‌شود. [۸]
- عدم مطابقت با استانداردها، جایی که ویژگی‌های استاندارد صنعت، فریم‌ورک‌ها و فناوری‌ها نادیده گرفته می‌شوند. سرانجام زمان ادغام با استانداردها فرا خواهد رسید. هر چه انتطباق با استانداردها زودتر انجام شود هزینه کمتری خواهد داشت. [۷]
- عدم دانش، هنگامی که توسعه دهنده به سادگی نمی‌داند چگونه کد تمیزی بنویسد.[۸]
- عدم مالکیت، هنگامی که تلاش‌های برون سپاری بخشی از کارها منجر به این می‌شود که تیم داخلی نیاز به ریفکتورینگ یا بازنویسی کد برون سپاری شده را پیدا می‌کند.
- رهبری ضعیف فنی، زمانی که تیم از مدیریت فنی ضعیفی برخوردار باشد بدهی‌های فنی افزایش می‌یابد.
- تغییرات لحظه آخری در نیازمندی‌ها، این امکان وجود دارد که در طول یک پروژه برای اعمال تغییرات تحت فشار قرار بگیریم اما زمان‌بندی و بودجه بندی مناسب برای پیاده‌سازی آنها در نظر گرفته نشود
| بی پروا | محتاط | |
|---|---|---|
حساب شده |
"ما زمان برای طراحی نداریم" | "باید اکنون منتشر کنیم و با عواقب آن رو به رو شویم (بعداً)" |
| ناخواسته | "لایه بندی چیست؟" | "اکنون می‌دانیم که چگونه باید این کار را می‌کردیم" |
مارتین فاولر در یک پست بلاگ خود[۹] چهار نوع بدهی را بر اساس دو دسته متمایز متمایز می‌کند: دسته اول بی پروا در مقابل محتاط، دسته دوم، حساب شده در مقابل ناخواسته.
خدمت یا بازپرداخت بدهی فنی[ویرایش]
کنی روبین از دسته‌بندی‌های وضعیت زیر استفاده می‌کند:[۱۰]
- بدهی فنی به اتمام رسیده‌است - بدهی که تیم توسعه از پرداخت آن بی‌خبر بودند. به عنوان مثال، تیم ویژگی جدیدی را به محصول اضافه می‌کند و پس از پایان کار می‌فهمد که مدت‌ها قبل این ویژگی توسط شخصی که مدت‌هاست از آنجا خارج شده‌است، در سیستم پیاده‌سازی شده‌است.
- بدهی فنی شناخته شده - بدهی که برای تیم توسعه شناخته شده‌است و با استفاده از یکی از روش‌های مطرح شده، قابل مشاهده است.
- بدهی فنی هدفمند - بدهی که شناخته شده‌است و توسط تیم توسعه جهت سرویس دهی در نظر گرفته شده‌است.
عواقب[ویرایش]
«پرداخت بهره» هم به دلیل نگهداری‌های محلی و هم به دلیل عدم نگهداری سایر کاربران پروژه ایجاد می‌شود. توسعه مداوم در پروژه‌های اصلی می‌تواند هزینه پرداخت بدهی فنی را در آینده افزایش دهد.
ایجاد بدهی فنی یکی از دلایل اصلی عدم موفقیت پروژه‌ها در رسیدن به سررسیدهاست. بسیار دشوار است که میزان دقیق کاری که برای پرداخت بدهی که با بروز هر تغییر ایجاد می‌شود را محاسبه کرد.
اگر کار کافی روی پروژه انجام شود تا مانع شکست آن شود، باز هم پروژه‌ای منتشر می‌شود که هنوز هم مقدار قابل توجهی بدهی فنی به همراه دارد. اگر این نرم‌افزار به تولید برسد، خطرات مربوط به اجرای هر گونه ریفکتور آتی برای برطرف کردن بدهی فنی را، به طرز چشمگیری افزایش می‌دهد. در صورتی که قراردادهای تولید نرم‌افزار شامل توافقات سطح خدمات (SLA) باشند، تغییر کد تولید خطر از کارافتادن، خسارات مالی و احتمالاً پیامدهای قانونی را به همراه خواهد داشت. به همین دلیل می‌توانیم تقریباً بدهی فنی به عنوان بدهی را افزایش داده و شاهد افزایش نرخ بهره باشیم و تنها زمانی این بدهی کاهش می‌یابد که توسعه محصول متوقف شود.
در حالی که قانون مانی لمن پیش از این اعلام کرده بود که برنامه‌های در حال توسعه به‌طور مداوم بر پیچیدگی و ساختار رو به زوال آنها افزوده می‌شود مگر اینکه برای حفظ آنها کاری انجام شود، وارد کانینگهام در ۱۹۹۲ گزارشی از تجربه مقایسه بین پیچیدگی فنی و بدهی را ترسیم کرد:
جوشوا کریایفسکی در متن خود در سال ۲۰۰۴ با عنوان Refactoring to Models، استدلال قابل مقایسه ای را در رابطه با هزینه‌های مرتبط با سهل انگاری در معماری ارائه می‌دهد، که او آن را «بدهی طراحی» توصیف می‌کند.[۱۱]
فعالیتهایی که ممکن است به تعویق افتد شامل مستندسازی، نوشتن تست‌ها، مشخص کردن TODOها و نادیده‌گرفتن هشدارهای تحلیل کد استاتیک و کامپایلر است. موارد دیگر بدهی فنی شامل دانش است که در سازمان به اشتراک گذاشته نمی‌شود و کدهایی که بسیار گیج کننده بوده به راحتی اصلاح نمی‌شود.
جوناد علی با نوشتن مقاله‌ای دربارهٔ توسعه PHP در سال ۲۰۱۴ گفت:
گرادی بوچ مقایسه می‌کند که چگونه شهرهای در حال تحول شبیه به سیستم‌های در حال تحول نرم‌افزاری هستند و چگونه عدم مقاوم‌سازی می‌تواند به بدهی فنی منجر شود.
در نرم‌افزار منبع باز، به تعویق انداختن ارسال تغییرات محلی به پروژه بالادستی نوعی بدهی فنی است.
جستارهای وابسته[ویرایش]
- بوی کد (علائم کیفیت پایین کد که می‌تواند به بدهی فنی کمک کند)
- توپ بزرگ گل
- پوسیدگی نرم‌افزار
- ضریب اتوبوس
- افزایش تعهد
- آنتروپی نرم‌افزار
- SQALE
- هزینه غرق
- TODO , FIXME , XXX
- نظارت مهندسی
منابع[ویرایش]
- ↑ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells (1st ed.). Morgan Kaufmann. p. 258. ISBN 978-0-12-801397-7.
- ↑ "Definition of the term "Technical Debt" (plus, some background information and an "explanation")". Techopedia. Retrieved August 11, 2016.
- ↑ Allman, Eric (May 2012). "Managing Technical Debt". Communications of the ACM. 55 (5): 50–55. doi:10.1145/2160718.2160733.
- ↑ Jeffries, Ron. "Technical Debt – Bad metaphor or worst metaphor?". Archived from the original on November 11, 2015. Retrieved November 10, 2015.
- ↑ Knesek, Doug. "Averting a 'Technical Debt' Crisis". Retrieved April 7, 2016.
- ↑ دیک، تک. «بدهی فنی Technical debt». تک دیک. دریافت‌شده در ۲۰۲۲-۱۰-۲۵.
- ↑ ۷٫۰ ۷٫۱ ۷٫۲ Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 November 2014). Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
- ↑ ۸٫۰ ۸٫۱ ۸٫۲ Chris Sterling (10 December 2010). Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. p. 17. ISBN 978-0-321-70055-1.
- ↑ Fowler, Martin. "Technical Debt Quadrant". Retrieved 20 November 2014.
- ↑ Rubin, Kenneth (2013), Essential Scrum. A Practical Guide to the Most Popular Agile Process (به انگلیسی), Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
- ↑ Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 978-0-321-21335-8.
پیوند به بیرون[ویرایش]
- Ward Explains Debt Metaphor, video from Ward Cunningham
- OnTechnicalDebt The online community for discussing technical debt
- Experts interviews on Technical Debt: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY
- Steve McConnell discusses technical debt
- TechnicalDebt from Martin Fowler Bliki
- Averting a "Technical Debt" Crisis by Doug Knesek
- An Andy Lester talk entitled بایگانی‌شده در ۱ ژوئن ۲۰۲۰ توسط Wayback Machine "Get out of Technical Debt Now!"
- Lehman's Law
- Managing Technical Debt Webinar by Steve McConnell
- Boundy, David, Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (آوریل ۱۹۹۳), Association for Computing Machinery, New York, New York, US
- Technical debt: investeer en voorkom faillissement by Colin Spoel
- Technical debts: Everything you need to know
- What is technical debt? from DeepSource blog