بدهی فنی چیست و چطور باید آن را مدیریت کرد؟

در دنیای ایده‌آل من، همه پروژه‌ها همیشه به موقع تمام می‌شوند و هیچ وقت خرجشان از بودجه تخمینی بیشتر نمی‌شود. تازه با همان بودجه، تیم‌ها نه تنها می‌توانند Featureهای اضافه بسازند، که می‌توانند قبل از بیرون دادن نسخه نهایی همه چیز را چندین بار هم تست کنند. اما حیف، دنیای واقعی این‌قدرها هم دلنشین نیست؛ بلکه در فرآیند توسعه نرم‌افزار، با هر قدمی که می‌گذاریم مشکلات جدیدی از چپ و راست جلوی پایمان سبز می‌شوند. یکی از رایج‌ترین و همه‌گیرترین این مشکل‌ها، بدهی فنی (Technical Debt) است. بدهی فنی چیست؟بدهی فنی، کارهای تکمیلی‌ای است که برای کامل کردن فرآیند توسعه نرم‌افزار، زمانی در آینده باید آنها را انجام بدهیم. بدهی فنی نتیجه عجله کردن در تحویل کارکرد یا پروژه‌ای است که در آینده، نیاز به بازسازی خواهد داشت. به عبارت دیگر، پیامد اولویت دادن تحویل سریع به نوشتن کد ایده‌آل است.بدهی فنی مثل بدهی بانکی است؛ اگر به موقع پرداختش نکنیم، جریمه می‌شویم و بدهی‌مان از قبل هم بیشتر می‌شود. بی‌توجهی به بدهی‌های فنی باعث می‌شود عملکرد نرم‌افزار ضعیف شود، تغییر دادن آن سخت یا حتی غیرممکن باشد، و احتمال ایراد پیدا کردن برنامه بعد از هر بروزرسانی بیشتر و بیشتر شود. اما همانطور که با وام گرفتن می‌شود سریع‌تر به اهداف بزرگ زندگی رسید، بدهی‌های فنی هم الزاماً بد نیستند. اگر آنها را درست مدیریت کنید، مزایای بی‌نظیری برای شرکت‌تان خواهند داشت؛ بخصوص اگر از آن شرکت‌هایی باشید که رشد سریع دارند. در چنین شرکتی باید محصولات را سریع و زودبه‌زود ارائه کنید تا بتوانید تناسب محصول/بازار را پیدا کرده، نیازهای مشتری را برآورده کنید، و از فرصت‌هایی که سر راهتان پیش می‌آید بهره ببرید. با مدیریت بدهی فنی، تضمین خواهید کرد که حرص دویدن، در بلندمدت زمینتان نخواهد زد.درست است که هیچ دستورالعملی برای همه آدم‌های روی کره زمین جوابگو نیست، اما به نظر می‌رسد آشنایی با انواع بدهی‌های فنی، به تیم‌ها کمک می‌کند تا در مورد بدهی فنی حرف بزنند و مشکلات مربوط به آن را به شکل بهتری حل کنند.دگ لیودن (Dag Liodden)، کوفاندر و CTO شرکت فناوری تبلیغاتی تپ‌اد (Tapad) بیشتر از ۱۴ سال است که دارد با بدهی فنی سر و کله می‌زند؛ در ادامه نگاهی می‌اندازیم به سه نوع اصلی بدهی فنی که توسعه‌دهندگان بیشتر از همه با آن‌ها سروکار دارند و استراتژی‌هایی که دگ لیودن برای روبه‌رو شدن با هر کدام پیشنهاد می‌کند را مرور می‌کنیم:۱. بدهی فنی عامدانهبدهی فنی و عواقب آنمهندس‌ها معمولا خودشان می‌دانند که کدام راه، راه درست انجام کار است و کدام راه، راه سریع آن. خیلی وقت‌ها، راه سریع همان کار درست است (برای جلوگیری از Over-engineering)، اما بعضی وقت‌ها هم اعضای تیم عمداً کار «اشتباه» را انجام می‌دهند، چرا که باید محصول را به سرعت به بازار برسانند.برای رساندن محصول به بازار، گاهی اوقات مجبورید خودتان عمداً بدهی فنی‌تان را زیاد کنید. وقتی این مسیر را در پیش می‌گیرید، فقط به زمانی که در آن صرفه‌جویی کرده‌اید فکر نکنید؛ بلکه به این هم بیندیشید که برای بازپرداخت بدهی‌ای که ایجاد کرده‌اید در آینده چه باید بکنید. مطمئن شوید که ذی‌نفعان محصول می‌دانند که این صرفه‌جویی، منجر به کاهش سرعت آماده شدن Featureهای دیگر در آینده خواهد شد.راه حل: شاید بگویید که این کار خیلی با فرهنگ چابک (Agile) تیم شما سازگار نیست! اما ایده خوبی است که وقت ایجاد این نوع از بدهی فنی، کارهایی که انجام نداده‌اید را در بک‌لاگ محصول (Backlog) یادداشت کنید. اگر این کارهای ناتمام به طور مشخص ثبت نشوند، بعید است که بدهی فنی در آینده پرداخت شود. بدون پرداخت بدهی‌ها، در گذر زمان بدهی فنی عامدانه تبدیل به بدهی ناشی از طراحی اتفاقی خواهد شد. مسئولیت به وجود آمدن این نوع بدهی‌ها بر عهده مالک محصول‌ (Product Owner) و ذی‌نفعان است؛ زیرا به خاطر تصمیمات تجاری است که به وجود می‌آیند.۲. بدهی فنی ناشی از طراحی تاریخ‌گذشته یا اتفاقیهنگام طراحی سیستم‌های نرم‌افزاری، سعی کنید بین «آینده‌نگری در کدنویسی» و «سادگی و سرعت تحویل» تعادل برقرار کنید. کار سختی است، و هر کسی گاهی در آن شکست می‌خورد. با گذر زمان، رشد سیستم، و تغییر نیازها، ممکن است به این نتیجه برسید که طراحی کارتان مشکل دارد و یا اینکه ایجاد یک کارکرد جدید تبدیل به کاری سخت و کند شده است. در یک طراحی خوب و اصیل، Refactor یا بازسازی تدریجی کدها خیلی آسان‌تر خواهد بود. اما بعضی وقت‌ها هم چاره‌ای نیست؛ باید خون دل خورد، نشست و یک دور Refactor مفصل و پر و پیمان انجام داد.راه حل: اینکه چطور Refactor مفصلی بکنیم خودش چندین پست جدا می‌طلبد، اما نیاز به انجام آن یک چیز طبیعی است. هرچند وقت یک بار، مثلا هر دو سال یک بار یا هر وقت که سیستم در وضعیت باثباتی بود، لازم است که چنین کاری انجام شود. اگر نشود، آنوقت ممکن است Over-engineering کنید و باعث شوید سیستم به شکل غیر ضروری‌ای مرتباً کند باشد. رهبران تیم و مالک محصول‌ها باید اطمینان حاصل کنند که برای بازپرداخت این نوع بدهی در آینده زمان کنار می‌گذارند؛ چرا که علت به وجود آمدن آن، تصمیمات مربوط به طراحی سیستم و تغییر مداوم نیازهای سیستم است.۳. بدهی فنی ناشی از فرسودگی نرم‌افزاریفرسودگی سیستم و بدهی فنی متعاقب آنبدهی فنی ناشی از فرسودگی نرم‌افزاری (Bit rot)، به مرور زمان به وجود می‌آید. تغییراتی که به تدریج در یک Component یا یک سیستم ایجاد می‌کنیم، باعث می‌شوند که کم‌کم سیستم پیچیدگی‌های غیرضروری‌ای پیدا کند. این پیچیدگی بخصوص زمانی تشدید می‌شود که چندین نفر بدون اینکه طراحی اولیه سیستم را درست فهمیده باشند، روی آن کار کنند. از جمله علایم چنین حالتی، برنامه‌نویسی کپی‌پیستی (یا به عبارتیCargo Cult Programming) است.راه حل: این تنها نوع از بدهی‌های فنی است که باید با Refactor مداوم کدها، به کلی از آن اجتناب کرد. تیم‌هایی که قوی هستند، برای فهم طراحی سیستمی که رویش کار می‌کنند، وقت کافی می‌گذارند؛ حتی اگر طراحی اولیه آن کار خودشان نبوده باشد. آنها به مرور طراحی را بهبود می‌بخشند و در طول مسیر، کدهای بد را تمیز می‌کنند. مسئولیت جلوگیری از به وجود آمدن این نوع بدهی با تیم توسعه نرم‌افزار است، زیرا این تک‌به‌تک اعضای توسعه‌دهنده هستند که آن را به وجود می‌آورند.تقسیم‌بندی انواع بدهی فنی یک راه حل معجزه‌آسا نیست. اینطور نیست که چوبدستی را تکان بدهیم و فقط با طبقه‌بندی، مدیریت کردن بدهی به طور جادویی آسان شود. اما این کار، تیم شما را قدرتمندتر می‌کند و گفتگوهای مفیدتری در این‌باره خواهید داشت. بدهی فنی شما به سیستم هرگز تمام نخواهد شد، و نباید هم بشود. نکته مهم این است که همیشه حواستان باشد که این بدهی چطور باعث کندی تیمتان می‌شود، و سعی کنید بین «تحویل Featureها در کوتاه‌مدت» و «افزایش بازدهی کلی در میان‌مدت و بلندمدت»، تعادل برقرار کنید.ترجمه و اقتباس از:"There are 3 main types of technical debt. Here’s how to manage them" @ Hackernoon“What Technical Debt Is and How to Calculate It” @ DZone“What is Technical Debt?” @ ProductPlanکوئرامگ: نسخه کارفرما، مجله‌ای تخصصی برای مدیران منابع انسانی و مدیران فنی سازمان‌ها است که به شکل ماهانه با مطلب‌هایی در زمینه چالش‌های منابع انسانی در حوزه برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید کوئرا را در لینکدین دنبال کنید.