تو این مقاله سعی دارم بدهی فنی رو توضیح بدم و مشکلات و سودهای احتمالیش رو باهم بررسی کنیم که در طولانی مدت میتونه چه مشکلاتی برامون ایجاد کنه و در کوتاه مدت چه سودی میتونه برامون داشته باشه.
فرض کنید روی پروژه‌ای کار میکنید که اضافه کردن فیچر جدید زمان‌بر شده، دیباگ کردن یه باگ بسیار سخت شده، اصطلاحا توسعه پذیر و یا قابل بهبود نیست یا زمان زیادی برای بهبود نیار داره.
مواردی که در بالا بهش اشاره شد نتایج بدهی‌های فنی ساختاریه که به مرور زمان باعث کند شدن پروسه توسعه محصول میشه.
ما میتونیم بدهی‌های فنی داشته باشیم که مشکلی برای توسعه پروژه ایجاد نکنه و به طور مثال خروجی به درستی داره کار میکنه ولی بهینه نیست و میشه بهترش رو نوشت و احتمالا اتفاق فورسی براش پیش نمیاد.
بدهی فنی میتونه علل‌های مختلفی داشته باشه ولی معمولا میتونه تو این دوتا دسته جا بگیره:
محدودیت زمانی: با یک مثال این مورد رو توضیح میدم فرض کنید پیاده کردن یه پروژه نرم افزاری به اسم X با فیچرهای a, b, c طبق بررسی نیازمندی‌ها و توان نیروها ۶ ماه زمان برآورد شده، ولی مدیر پروژه با توجه به محدودیت ها و از دست ندادن زمان عرضه در مارکت درخواست انجام این پروژه را در ۳ ماه دارد، یعنی نصف زمان برآورد شده است.
بی‌تجربه بودن تیم یا فرد: زمانی اتفاق میوفتد که تقریبا همه چیز متناسب با زمانش پیش میرود، ولی در حین پیاده سازی پروژه بخاطر عدم تجربه کافی، تصمیم های غلط گرفته میشود، این تصمیم‌های غلط میتواند انتخاب اشتباه معماری یا حتی انتخاب تکنولوژی یا فریمورک اشتباهی برای آن پروژه خاص باشد که در بلند مدت میتوان آثارش را مشاهده کرد.
بدهی فنی میتونه مزیت های کوتاه مدتی برای محصول داشته باشه که حتی میتونه نقش برگ برنده برای تیم محصول رو بازی کنه، فرض کنید که یک ایده‌ای وجود دارد که در این بازه زمانی امکان درآمد زایی برای شرکت داشته باشه، با فرض این موضوع اگر تیم برنامه نویسی در زمان ایده آل خود بخواهد این فیچر یا پروژه را توسعه دهد احتمالا تیم محصول با یک فرصت سوزی بزرگ روبرو خواهد شد، و بخاطر این موضوع مدیر تیم فنی با قبول عواقب بدهی فنی که در آینده احتمالا گریبان گیر تیم فنی خواهد شد توسعه نرم افزار را جلو ببرد.
معمولا مشکلات بدهی فنی در طولانی مدت و در روند توسعه محصول خودشان را نشان میدهند که هزینه‌های زیادی هم با خودشون میارن، به طور مثال وقتی روی معماری یک پروژه نرم‌افزاری وقت زیادی گذاشته نشود و انتخاب درستی در پیاده سازی نداشته باشیم احتمالا در آینده هزینه خیلی زیاد برای توسعه محصول خواهیم داشت که با بزرگ شدن پروژه روند کارها کندتر و کندتر از قبل پیش میرود، یا موردی رو فرض کنید که شخص جدیدی وارد تیم یا پروژه شده است، چون پروژه بدهی‌های فنی زیادی دارد، از جمله تست خوبی نوشته نشده، وقت زیادی برای معماری، دیزاین پترن‌ها گذاشته نشده، ... در این شرایط هم سرعت توسعه تحت تاثیر قرار گرفته میشه، هم به پیچیده‌تر شدن Code base پروژه اضافه میشه.
بدهی‌های فنی میتونه موارد زیادی رو در بر بگیره با اولویت‌های کم یا زیاد و شرایط خاص و غیر خاص، به طور مثال معمولا در پروژه‌های برنامه‌نویسی اولین چیزی که به عنوان بدهی فنی پیش میاد نوشتن Unit Test، استفاده از دیزاین پترن‌ها برای بهینه‌سازی یا قابلیت استفاده مجدد یا پیروی از اصول های توسعه نرم افزار مانند ۵ اصل SOLID یا DRY و خیلی از موارد دیگه که در توسعه پذیر بودن پروژه نرم‌افزاری نقش‌های مهمی دارن.
در مهندسی نرم‌افزار، به ویژگی‌ها یا نشانه‌هایی در کد یک برنامه که حاکی از وجود مشکلاتی در عمق برنامه باشند، Code Smell گفته میشود. بوهای کد خطا نیستند، اما می‌توانند کد را برای نگهداری، درک و گسترش دشوارتر کنند.
بوی کد به ۳ سطح از پروژه نرم افزاری اشاره میکنه:
هر کدوم از موارد بالا یک لیستی از اشتباهات رایج رو شامل میشه که عدم رعایت اون موارد تو پروژه نرم افزاری حکایت از بوی بد کد داره.
اینجا به چندتا از موارد خیلی عمومی اشاره میکنم:
راه حل دقیق برای همه تیم های برنامه نویسی و پروژه ها وجود نداره و خیلی بستگی به نوع پروژه و وضعیت پروداکت داره، ولی دو راه حل مشترک وجود داره که بیشترین مشکلات رو پوشش میده:
مورد اول زمانی اتفاق میوفته که پروژه به حدی از پیچیدگی و بدهی‌های فنی رسیده که دیگه قابل توسعه نیست و راه حل کم هزینه میتونه گزینه ساخت پروژه جدید و توجه زیاد به نقطه ضعف های پروژه قبلی باشه.
مورد دوم ریفکتور کردن بخش‌های مختلف پروژه در کنار انجام نیازمندی‌های پروداکت، با یک مثال توضیح بیشتری میدم:
فرض کنید روی یک پروژه کار میکنید که بدهی فنی در رابطه با معماری و ساختار پروژه وجود داره و تستی برای قسمت‌های مختلف پروژه نوشته نشده، در همین حین، تیم پروداکت فیچرهایی رو برای توسعه نیاز داره.
تو این شرایط احتمالا امکان ساخت پروژه جدید وجود نداره و از طرفی هم بدهی‌فنی های زیادی هم وجود داره، یکی از راه حل‌های موجود میتونه این باشه که تیم برنامه‌نویسی واقعیت بدهی فنی رو به تیم پروداکت یا مدیر پروژه شرح بده و ازشون وقت برای حل کردن این مشکلات بگیره و شرح کار به این شکل میشه که در هر دوره(ماه، هفته، هر اسپرینت اسکرام، ...) چند درصد از زمان رو برای ریفکتور کردن و حل کردن بدهی‌های فنی اختصاص داده بشه، و چند درصد از زمان تیم رو به پیاده کردن نیازمندی‌های تیم پروداکت اختصاص دهیم.
با این راه حل احتمالا حل کردن تمام بدهی‌های فنی امری زمان بر باشه، ولی میتونیم با این شرایط، هم کدهای موجود رو ریفکتور کنیم، هم به نیاز مندی‌های بیزینس برسیم که معمولا باعث روند پیشرفت تدریجی پروژه و بیزینس میشه.
بدهی‌فنی لزوما خیلی بد یا خیلی خوب نیست، پروژه های برنامه نویسی میتونه بدهی‌های فنی متعددی داشته باشه ولی تا زمانی که توسعه محصول رو تحت تاثیر قرار نده میتونیم باهاشون کنار بیایم و درگیر موارد با اولویت بالاتر بشیم، از جمله حل مشکلات مهم و ریفکتور کردن، یا حتی استفاده از تکنولوژی جدیدتر.
اگه در حال شروع یک پروژه هستید و از لحاظ زمانی محدودیت دارید، باید دونسته هزینه‌های بدهی فنی در آینده رو انتخاب کنید.
همیشه ساخت پروژه جدید بهترین راه حل برای حل کردن بدهی فنی های زیاد نیست و میتونیم به صورت خرد موارد مهم رو انجام بدیم در حالی که نیازمندی های بیزینس هم رفع بشه.
همیشه باید به Code smell توجه داشته باشیم تا بدهی های فنی پروژه روز به روز بیشتر نشه و کدهای کثیف باعث ایجاد کدهای کثیف بیشتر نشه.
