بازار توسعه نرم‌افزار به قدری رقابتی و پرشتاب شده که گاهی برای رسیدن به مقصد چاره‌ای جز میان‌بر زدن نمی‌ماند. یکی از میان‌برها «بدهی فنی» است که به شما اجازه می‌دهد محصول ناتمامی را راهی بازار کرده و بعدا نواقص آن را رفع کنید. این روش شاید شما را سریعتر به مقصد برساند اما مثل قرضی است که دیر یا زود باید آن را پرداخت کنید. در ادامه مطلب انواع بدهی فنی، علل و پیامدهای آن را بررسی کرده و به شما نشان می‌دهیم چگونه آن را را به فرصتی برای پیشرفت تبدیل کنید.
اصطلاح بدهی فنی یا Technical Debt هزینه‌های ناشی از انتخاب راه‌حل آسان و سریع به جای راه‌حل مناسب را توصیف میکند. به عبارت دیگر تصور کنید برای رسیدن به مقصد، به جای اتوبان از میان‌بر خاکی و پر پیچ و خم می‌روید. هرچند این مسیر سریعتر است اما در درازمدت برای تعویض لاستیک و تعمیر ماشین باید هزینه بیشتری بپردازید. علاوه بر این خطرات پیش‌بینی نشده هم در مسیر بیراهه وجود دارد. در توسعه نرم‌افزار هم زمانی که به خاطر نبود وقت یا دانش کم توسعه‌دهنده، از گوشه و کنار محصول می‌زنیم و آن را با طراحی ضعیف به دست کاربر می‌رسانیم، بدهی فنی ایجاد کرده‌ایم. اصطلاح Technical Debt نتیجه ذهنیت «بساز و بفروش» است که می‌خواهد فعلا فقط بفروشد و کیفیت محصول در اولویت نیست. مثال‌هایی برای درک بهتر اینکه بدهی فنی چیست:
Technical Debt در بسیاری از موارد می‌تواند یک ابزار استراتژیک برای توسعه نرم‌افزار باشد. این مفهوم به توسعه‌دهندگان اجازه می‌دهد تا برای رسیدن به اهداف کوتاه‌مدت، مانند تحویل سریعتر محصول یا آزمایش ایده‌ها، تصمیمات فنی موقتی بگیرند. از جمله دلایل روی آوردن به بدهی فنی باید به این موارد اشاره کرد:
بدهی فنی مثل یک وام همیشه روی دوش شماست و هرچه بازپرداخت را عقب بیندازید، اصل بدهی و بهره آن تلنبار شده و عواقبی از این دست دامن‌گیر شما خواهد:
برای جلوگیری از این مشکلات باید در فرایند توسعه محصول قابلیت‌ها و تسک‌های پروژه را اولویت‌بندی کنیم. در ادامه روش صحیح انجام این کار را توضیح می‌دهیم.
اولویت‌بندی ویژگی‌ها در توسعه نرم‌افزار حیاتی است که و موفقیت یا شکست پروژه‌ها را تعیین میکند. روش‌های مختلفی برای اولویت‌بندی وجود دارد که از میان آنها MoSCoW از همه محبوب‌تر است. مدل MoSCoW روشی ساده و در عین‌حال قدرتمند برای اولویت‌بندی نیازمندی‌های پروژه است. این مدل به شما کمک میکند تا با تقسیم‌بندی کارها به چهار دسته، یک دید کلی از اهمیت هر فیچر داشته باشید:
برای مثال تصور کنید که در هر حال راه‌اندازی یک اپلیکیشن آموزش زبان هستید.
طبقه‌بندی ویژگی‌ها با روش MoSCoW به این ترتیب خواهد بود:
Must have:
Should have:
Could have:
Won’t have:
اگر روش MoSCoW به هر دلیلی برای شما مناسب نیست، می‌توانید سراغ دیگر روش‌های اولویت‌بندی فیچر در توسعه محصول بروید:
این مدل به تحلیل و ارزیابی رضایت مشتریان از ویژگی‌های مختلف می‌پردازد و آنها را به دسته‌های زیر تقسیم میکند:
نیازهای پایه: ویژگی‌هایی که بدون آنها محصول ناقص به نظر می‌رسد.
نیازهای عملکردی: مواردی که بهبود آنها به افزایش رضایت کاربر منجر می‌شود.
نیازهای هیجانی: موارد غیر منتظره که کاربر را هیجان‌زده میکند.
این مدل هم با استفاده از چهار فاکتور به اولویت‌بندی ویژگی‌ها کمک میکند:
بدهی فنی ریشه یک چیز دارد: تصمیم به حل نکردن مشکل در زمان فعلی. در ادامه چند نمونه از این مشکلات را معرفی می‌کنیم که به بدهی فنی (Technical Debt) منجر می‌شوند.
اگر نیازهای پروژه از ابتدا به روشنی تعریف نشود، پس از توسعه محصول ناچار می‌شوید کدها را اصلاح کرده یا به کلی تغییر دهید. بنابراین پیش از شروع فرایند کدنویسی با روش‌های مذکور اولویت‌ها و نیازها را دقیق و شفاف مشخص کنید.
کدی که به شکل نامرتب و بدون مستندات نوشته شده، مثل یک معما پیچیده است که درک آن برای اعضای جدید یا حتی توسعه‌دهندگان اولیه پروژه دشوار خواهد بود. این کدهای غیر استاندارد در بلندمدت به سیستمی پیچیده و شکننده تبدیل می‌شوند که مدیریت و توسعه آن بسیار دشوار و هزینه‌بر خواهد بود. ماژولار نبودن کد هم باعث می‌شود که تغییرات کوچک در یک قسمت، بر سایر بخش‌ها تأثیر گذاشته و باعث بروز مشکلات ناخواسته شود.
عرضه محصول بدون تست مثل نشستن پشت ماشینی است که ترمز ندارد. شاید ابتدا همه‌چیز خوب پیش برود اما در اولین پیچ یا مانع، حادثه رخ می‌دهد. تست نادرست محصول یعنی ایجاد یک بدهی فنی برای تیم توسعه در قالب خطاهایی که به زودی مشخص خواهند شد.
ضعف دانش در تیم توسعه یکی از دلایل اصلی ایجاد بدهی فنی است. وقتی تیم توسعه درک درستی از اصول برنامه‌نویسی، الگوریتم‌ها، الگوهای طراحی و متدهای جدید ندارد، کدهایی تولید میکند که پیچیده، غیر قابل نگهداری و سراسر باگ است. به مرور زمان مشکلات کدها روی هم جمع شده و Technical Debt را برای سازمان به بار می‌آورند.
وقتی کدها بدون مستندات کافی رها شوند، تشخیص نحوه کارکرد سیستم برای توسعه‌دهنده دشوار می‌شود. این موضوع باعث کندی در توسعه و نگهداری سیستم می‌شود چون دولوپر زمان زیادی را صرف درک کدها میکند. همچنین احتمال بروز خطا در زمان تغییر یا به‌روزرسانی افزایش می‌یابد.
کسانی که تجربه سال‌ها کار در زمینه توسعه نرم‌افزار را داشته باشند، تجربه برخورد با انواع بدهی فنی در برنامه‌نویسی را پیدا کرده‌اند. بدهی فنی به سه دسته اصلی تقسیم برنامه‌ریزی شده، ناخواسته و اجتناب‌ناپذیر تقسیم می‌شود که در ادامه به معرفی آنها می‌پردازیم.
این مورد به‌صورت آگاهانه و عمدی ایجاد می‌شود و هدف از آن تحویل هرچه سریعتر محصول برای ورود فوری به بازار رقابت است. برای مثال توسعه‌دهندگان قسمت‌هایی از کد را به صورت موقت با کیفیت پایین پیاده‌سازی می‌کنند تا محصول زودتر آماده شود.
این مورد به مشکلات و نقص‌های فنی اشاره دارد که به‌صورت ناخواسته و به دلیل کدنویسی ضعیف، دانش ناکافی، عجله در توسعه یا عدم رعایت استانداردها در محصول ایجاد می‌شود.
نحوه رسیدگی به بدهی فنی ناخواسته شناسایی: کد را بررسی و مشکلات فنی مانند پیچیدگی زیاد، عدم تست و غیره را شناسایی کنید.
این مورد معمولا در دو حالت رخ می‌دهد. در حالت اول کارفرما یا سازمان به هر دلیلی در میانه‌راه توسعه محصول، می‌خواهد تغییراتی پایه‌ای ایجاد کند. حالت دوم زمانی رخ می‌دهد که یک فناوری یا ابزار در زمان توسعه بهترین انتخاب ممکن بوده، اما با گذشت زمان و پیشرفت فناوری قدیمی و ناکارآمد می‌شود.
بدهی فنی برنامه‌ریزی‌شده آگاهانه و به شکل عمدی برای رسیدن سریعتر به اهداف کوتاه‌مدت ایجاد می‌شود؛ با علم به اینکه در آینده رفع خواهد شد. در مقابل بدهی فنی خارج از برنامه و بیشتر به‌دلیل اشتباهات، عدم دقت یا ناآگاهی در طراحی و توسعه به‌وجود می‌آید و برنامه‌ریزی نشده است.
این سوال مثل این است که بپرسیم قرض گرفتن خوب است یا بد؟ بدهی فنی هم مثل وام گرفتن زمانی خوب است که هم برای سرمایه‌گذاری و هم برای بازپرداخت آن برنامه داشته باشیم. بدهی فنی در ابتدای پروژه این مزیت را دارد که محصول سریعتر آماده شده و سازمان از رقابت عقب نمی‌ماند. اگر در زمان مناسب بدهی پرداخت شده و مشکلات اولیه رفع شود، سازمان از آن سود برده است. از سوی دیگر اگر بازپرداخت پشت گوش انداخته شده و روی هم تلنبار شود، عواقب آن عمیق‌تر شده و دامن‌گیر سازمان خواهد شد. بنابراین بدهی فنی تا زمانی که مدیریت شود، مفید است اما اگر کنترل نشود، مشکلات جدی ایجاد میکند.
اکثر محصولات نرم‌افزاری تا حدی بدهی فنی دارند اما برای به حداقل رساندن یا حذف آن این مراحل را دنبال کنید:
تصمیم‌گیری در مورد زمان پرداخت به عوامل مختلفی بستگی دارد؛ با این حال نشانه‌هایی وجود دارد مبنی بر اینکه موعد پرداخت فرا رسیده است:
پرداخت بدهی فنی به صورت کامل و یکجا همیشه امکان‌پذیر نیست. بنابراین می‌توانید آن را به بخش‌های کوچک‌تر تقسیم و به تدریج پرداخت کنید. چرخه معیوب بدهی فنی در صورت عدم پرداخت تجربه ثابت کرده بدهی فنی هیچ‌وقت به‌طور کامل پرداخت نمی‌شود. به مرور زمان اصل بدهی و بهره آن به قدری زیاد می‌شود که بازپرداخت آن ممکن نیست. سازمان زمانی به خود می‌آید که تیم توسعه دیگر توان تمرکز روی رشد و ارائه قابلیتهای جدید را ندارد و صرفا روی سمبل کردن کارها با ارائه راه‌حل کوتاه‌مدت تمرکز میکند.
بدهی تلنبار شده، دومینو وار به بخش‌های دیگر سرایت کرده و کل تیم توسعه را به ورشکستگی می‌کشاند. زمانی متوجه این فاجعه می‌شوید که اضافه کردن قابلیت جدید یا رفع مشکلات بدون بازنویسی کامل کدها ممکن نیست. به عبارت دیگر هزینه توسعه یک سیستم جدید از بدهی فنی کمتر است.
برای رهایی از بدهی فنی، باید قبل از هرچیز مفاهیم برنامه‌نویسی را به طور اصولی یاد بگیرید. بهترین روش برای یادگیری اصولی این مفاهیم شرکت در دوره‌های پروژه‌محور نظیر بوتکمپ DevOps (دواپس) کلاسور است که با رویکرد عملی، نحوه صحیح پیاده‌سازی و مدیریت نرم‌افزار را به شما آموزش می‌دهد. پس از شرکت در این دوره روی استانداردهای DevOps، تست‌های خودکار و پیاده‌سازی CI/CD، مسلط خواهید شد. پس از آشنایی با این مفاهیم می‌توانید بدهی فنی را به راحتی شناسایی و برطرف کنید.
