خانه / Agile / کمی شفاف سازی در باب بدهی فنی

کمی شفاف سازی در باب بدهی فنی

Technical Debt

چندی پیش سوالی رو جناب مهندس مهرداد در باب مبحث مدیریت بدهی فنی رو مطرح فرمودند؛ و بحثی در این باره باز شد. در پاسخ به این سوال مهم جناب مهندس مهرداد عزیز؛ بنده گریزی زدم به پیش زمینه و معنی و مفهوم این concept بسیار مهم؛ که فرصتی پیش اومد تا اون رو در پست خدمتتون ارائه بدم.

اما سوال جناب مهندس مهرداد عزیز.

#پرسش

رویکرد شما در تیم‌های خود برای مدیریت بدهی فنی (Technical Debt) چگونه است؟

اگر زحمتی نیست، لطفا  تجربیات خود را با ما در میان بگذارید.

پیشاپیش سپاسگزارم.

پاسخ بنده:

#TechnicalDebt

#TechnicalDebtQuadrant

در مورد بحث Technical Debt فصل هشتم کتاب #EssentialAgile ترجمه دوستان و همکاران بسیار ارزشمند بنده مهندس مهرداد؛ مهندس اسماعیلی و همچنین مهندس معصومی به طور مفصل توضیح داده شده.

مورد مهمتر اما در مورد misconceive هست که در این مورد وجود دارد. که الزاما هر کد و یا طراحی غلط و بد و اسپاگتی کدی به عنوان Technical Debtشناخته می شود؛ که در عمل متوجه می شیم که این تصوری است غلط که ممکن است پسا برخردهای درستی هم به دنبال نداشته باشد. در ای باره آقای #Uncle_Bob در #Clean_Code مفصلا بحث می کند که می تونید به لینک زیر هم مراجعه کنید.

 

https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt

 

 

آقای #Martin_Fowler هم به این گفته ی آقای باب اشاره می کنند : A mess is not a Technical Debt. و اشاره می کنن که این سوال که آیا یک طراحی غلط و اشتباه و بد باید در گروه بدهی فنی قرار بگیرد یا خیر سوالی غلط است و اصلاح #Debt_Metaphor رو بکار می برن. و یکی از مزیت های عمده ای این اصلاح این است که بر خلاف تصور غلطی که ممکن است وجود داشته باشد در باب بدهی فنی با استفاده از #Debt_Metaphor برقراری ارتباط با افراد و ذینفعان غیر فنی بسیار مناسبت تر و بهتر است.

و سپس از عبارت #Reckless استفاده می کند که در مقابل #Prudent قرار می گیرد و اشاره می کند که #mess_code از انواع #Reckless_Debt می باشه ;می تونه منجر به جریمه سنگین و فلج کننده بشه. از طرف دیگه #Prudent_Debt مصامحه ای است بین دو تصمیم. و اینکه گاهی میتوان با (احتیاط) جهت رسیدن به یک ریلیز از یکسری اصول تخطی نمود به شرطی که جریمه مرتبط با این تخطی کنترل شده و به اندازه زیاد نباشد.(از جمله اینکه به عنوان مثال با اینکار خیلی کم احتیاج به دستکاری #Code_Base داشته باشیم.

از طرف دیگر آقای فاولر از دو اصطلاح دیگر #Deliberate_Debt و #Inadvertant_Debt هم اشاره می کنه. و اشاره می کنه که #Produnt_Debt یکی از انواع #Deliberate_Debtهست چون تیم به نوعی از قبل مطلع هست که کاری که انجام میده منجر به یک بدهی(Debt) خواهد شد اما با تصمیم گیری در تیم متوجه میشن که یک ریلیز زود تر و سریعتر میتونه بیشتر از هزینه ای که باید بابت Debt پرداخت کنند مفید واقع شود پس بهمین دلیل دست به این کار میزنه. و تیمی از #Design_Practiceها بی اطلاع هستش و دارای علم و تجربه ی کافی در این زمینه نیست و درگیر #Reckless_Debt میشن. در حالت عمومی #Reckless_Debt ها نیمتونن جز بدهی هی سهوی(#inadvertent_Debt) باشند.

در تکمیل #TechnicalDebtQuadrant  آقای فاولر این مورد هم میتونه خیلی مفید باشه

 

درباره ی masoud@admin

همچنین ببینید

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل

مایکروسرویس ها و ادامه چرخه ی تسلسل اجایل هرچند تفکر و ایده ی ورای Microservices …

Problem Solving و Critical Thinking حلقه های گمشده ی مهندسی

Problem Solving Problem Solving یا توانایی حل مسئله بخشی از جریان فکری و تفکر انسان …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن