تحقیق و توسعه آرتیفکت‌های معماری نرم‌افزار (توجه به شناسایی ریسک و بدهی فنی)

گزارش پایانی درس معماری نرم‌افزار

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

مقدمه

معماری نرم‌افزار، به عنوان ریشه اصلی توسعه سیستم‌های نرم‌افزاری پیچیده، نقشی حیاتی در تضمین کیفیت، مقیاس‌پذیری، نگهداری، امنیت و کارایی ایفا می‌کند. این حوزه، مسئول تعیین ساختار کلی یک سیستم، انتخاب فناوری‌ها، تعریف ارتباط بین مؤلفه‌ها و تصمیم‌گیری در مورد ویژگی‌های غیرکاربردی (non-functional requirements) است. آرتیفکت‌های معماری، که شامل انواع مدل‌های ساختاری، مستندات تصمیم‌گیری، دیاگرام‌ها، کد مستند شده، الگوها و مستندات طراحی می‌شوند، نمود عینی این تصمیمات معماری هستند. این آرتیفکت‌ها نه تنها پل ارتباطی بین نیازمندی‌ها و پیاده‌سازی محسوب می‌شوند، بلکه ابزارهایی قدرتمند برای مدیریت پیچیدگی، کنترل تغییرات، ارزیابی کیفیت و بهبود مستمر نرم‌افزار را فراهم می‌آورند.

در پروژه‌های نرم‌افزاری مدرن، به ویژه آن‌هایی که در مقیاس بزرگ و با تیم‌های توسعه توزیع‌شده اجرا می‌شوند، قابلیت اطمینان به این آرتیفکت‌ها و به‌روز بودن آن‌ها از اهمیت ویژه‌ای برخوردار است. تولید و نگهداری صحیح و به‌موقع این آرتیفکت‌ها، نه تنها به عنوان یک گام ضروری در چرخه عمر توسعه نرم‌افزار (SDLC) تلقی می‌شود، بلکه به طور مستقیم بر موفقیت یا شکست پروژه تأثیر می‌گذارد. آرتیفکت‌های معماری با کیفیت، می‌توانند به کاهش سوءتفاهم‌ها، افزایش کارایی تیم، کاهش هزینه‌های نگهداری و تسریع فرآیند توسعه کمک کنند. در مقابل، آرتیفکت‌های ناقص، منسوخ یا نامفهوم، می‌توانند منجر به بروز مشکلات جدی از قبیل اشکالات طراحی، عدم همگام‌سازی بین بخش‌های مختلف سیستم و در نهایت، شکست پروژه شوند.

اهمیت و چالش‌های بهبود و تولید آرتیفکت‌های معماری

در این بخش، به تفصیل به اهمیت حیاتی آرتیفکت‌های معماری در چرخه عمر توسعه نرم‌افزار، چالش‌های پیچیده مرتبط با تولید و نگهداری آن‌ها، و ضرورت بهبود مستمر این آرتیفکت‌ها برای اطمینان از موفقیت پروژه‌های نرم‌افزاری پرداخته می‌شود.

اهمیت آرتیفکت‌های معماری

آرتیفکت‌های معماری، بیش از صرف مستندات، ابزارهایی استراتژیک برای مدیریت پیچیدگی و اطمینان از کیفیت در پروژه‌های نرم‌افزاری هستند. اهمیت آن‌ها را می‌توان در چهار بعد کلیدی خلاصه کرد:

1. مستندسازی تصمیمات کلیدی: معماری نرم‌افزار، نتیجه تصمیمات متعددی است که در طول فاز طراحی و توسعه گرفته می‌شوند. این تصمیمات شامل انتخاب الگوهای طراحی، فناوری‌ها، چارچوب‌ها و ساختار کلی سیستم است. آرتیفکت‌ها به عنوان سوابق دقیق این تصمیمات عمل می‌کنند و دلایل پشت انتخاب‌ها را ثبت می‌کنند. این امر نه تنها برای توسعه‌دهندگان فعلی مفید است، بلکه برای تیم‌های آینده که مسئول نگهداری یا توسعه سیستم هستند، مرجعی ارزشمند فراهم می‌کند. مستندسازی تصمیمات (Architecture Decision Records - ADRs) به ویژه در این زمینه حیاتی است و به جلوگیری از تکرار اشتباهات و حفظ یکپارچگی معماری کمک می‌کند.

2. تسهیل ارتباط بین ذی‌نفعان فنی و غیرفنی: پروژه‌های نرم‌افزاری شامل ذی‌نفعان متعددی با پیش‌زمینه‌ها و سطوح دانش فنی متفاوت هستند. آرتیفکت‌های معماری، مانند دیاگرام‌های UML یا SysML، یک زبان بصری مشترک فراهم می‌کنند که به ذی‌نفعان مختلف، از جمله مدیران پروژه، تحلیل‌گران کسب‌وکار، توسعه‌دهندگان، آزمایش‌کنندگان و حتی کاربران نهایی، امکان درک ساختار و رفتار سیستم را می‌دهند. این ارتباط مؤثر، سوءتفاهم‌ها را کاهش داده و همسویی را در اهداف پروژه افزایش می‌دهد.

3. پایه‌گذاری برای تحلیل و ارزیابی کیفیت نرم‌افزار: آرتیفکت‌های معماری، به خصوص مدل‌های ساختاری و رفتاری، بستری محکم برای تحلیل و ارزیابی ویژگی‌های کیفی سیستم (Quality Attributes) مانند کارایی، مقیاس‌پذیری، امنیت، قابلیت نگهداری و قابلیت اطمینان فراهم می‌کنند. تحلیل‌های مبتنی بر مدل (Model-Based Analysis) می‌توانند قبل از پیاده‌سازی، نقاط ضعف احتمالی معماری (ریسک ها، بدهی های فنی و ...) را شناسایی کرده و به تیم‌ها امکان می‌دهند تا قبل از صرف زمان و هزینه زیاد برای کدنویسی، تغییرات لازم را اعمال کنند. این رویکرد به ویژه در مدیریت ریسک و بهینه‌سازی منابع مؤثر است.

4. کاهش پیچیدگی و مدیریت تغییر: با افزایش اندازه و پیچیدگی سیستم‌های نرم‌افزاری، مدیریت تغییرات به یک چالش بزرگ تبدیل می‌شود. آرتیفکت‌های معماری به تیم‌ها کمک می‌کنند تا تأثیر تغییرات را پیش‌بینی کنند، وابستگی‌ها را شناسایی کنند و تغییرات را به صورت کنترل‌شده و با حداقل اختلال پیاده‌سازی کنند. یک معماری خوب مستند شده، به عنوان نقشه‌ای عمل می‌کند که در صورت نیاز به اعمال تغییرات، راهنمایی‌های لازم را ارائه می‌دهد.

چالش‌های اصلی

با وجود اهمیت فراوان، تولید و نگهداری آرتیفکت‌های معماری با چالش‌های متعددی روبرو است که در ادامه به برخی از مهم‌ترین آن‌ها اشاره می‌شود:

1. همگام‌سازی میان مستندات و کد منبع: یکی از بزرگترین چالش‌ها، حفظ همگام‌سازی بین مستندات معماری و کد منبع واقعی سیستم است. با گذشت زمان و با اعمال تغییرات در کد، معمولاً مستندات به‌روز نمی‌شوند و این امر منجر به انحراف معماری (Architectural Drift) می‌شود. این انحراف می‌تواند باعث سردرگمی، تصمیم‌گیری‌های نادرست و افزایش هزینه‌های نگهداری شود. این مشکل اغلب به دلیل فشار زمانی، نبود ابزارهای مناسب برای به‌روزرسانی خودکار و عدم توجه کافی به مستندسازی در طول چرخه توسعه ایجاد می‌شود. از منظر ریسک، این وضعیت به‌طور مستقیم منجر به ریسک انحراف معماری و شکل‌گیری بدهی فنی همگام‌سازی می‌گردد که بازپرداخت آن در آینده بسیار پرهزینه است.

2. هزینه بالا و نیاز به تخصص برای تولید و نگهداری مستندات: تولید آرتیفکت‌های معماری با کیفیت، به زمان، تلاش و تخصص قابل توجهی نیاز دارد. معماران نرم‌افزار باید دانش عمیقی از الگوهای طراحی، فناوری‌ها و استانداردهای مستندسازی داشته باشند. علاوه بر این، نگهداری مستمر این آرتیفکت‌ها نیز خود مستلزم هزینه است. کوتاهی در این بخش، سبب افزایش بدهی فنی ناشی از مستندسازی ناقص و ایجاد ریسک کاهش کیفیت تصمیم‌گیری معماری می‌شود.

3. تفاوت سطوح انتزاعی و نیاز به مدل‌سازی چندلایه: معماری نرم‌افزار در سطوح مختلفی از انتزاع قابل بیان است، از سطح کلی سیستم گرفته تا جزئیات مربوط به مؤلفه‌ها و کلاس‌ها. ایجاد و حفظ مدل‌ها در این سطوح مختلف و اطمینان از سازگاری آن‌ها، نیازمند رویکردهای مدل‌سازی چندلایه و ابزارهایی است که بتوانند از این پیچیدگی پشتیبانی کنند. مدیریت این سطوح انتزاعی و ارتباط بین آن‌ها می‌تواند بسیار دشوار باشد .عدم مدیریت درست این سطوح منجر به ریسک ناسازگاری مدل‌ها و انباشته شدن بدهی فنی معماری (ATD) می‌شود که در آینده روند توسعه را کند و پرهزینه می‌کند.

4. فقدان استانداردها و الگوهای ثابت در مستندسازی: با وجود استانداردهایی مانند UML، هنوز هم تنوع زیادی در نحوه مستندسازی معماری وجود دارد. فقدان یک استاندارد جهانی یکپارچه باعث ایجاد ریسک فهم‌پذیری پایین و سوءتفاهم تیمی شده و زمینه را برای بروز بدهی فنی در هماهنگی و مدیریت تغییرات فراهم می‌کند.

اهمیت بهبود و بهینه‌سازی

با توجه به چالش‌های مطرح شده، بهبود و بهینه‌سازی فرآیندهای تولید و نگهداری آرتیفکت‌های معماری از اهمیت حیاتی برخوردار است. این بهبودها می‌توانند به نتایج زیر منجر شوند:

1. دستیابی به معماری Agile و قابل توسعه: بهبود فرآیندهای تولید آرتیفکت، به ویژه با تمرکز بر اتوماسیون و ابزارهای پشتیبانی، می‌تواند به ایجاد معماری‌هایی کمک کند که نه تنها پایدار هستند، بلکه به سرعت و با انعطاف‌پذیری بالا می‌توانند با تغییرات سازگار شوند. این امر برای پیاده‌سازی رویکردهای چابک و DevOps بسیار مهم است. این رویکرد، ریسک انباشته شدن بدهی فنی ناشی از تغییرات سریع را کاهش می‌دهد و از شکل‌گیری بدهی‌های ناشی از نیاز به بازطراحی‌های گسترده در آینده جلوگیری می‌کند.

2. کاهش خطاهای طراحی و افزایش قابلیت نگهداری: با داشتن آرتیفکت‌های دقیق و به‌روز، تیم‌ها می‌توانند خطاهای طراحی را در مراحل اولیه شناسایی و رفع کنند. این امر هزینه رفع اشکالات را کاهش داده و ریسک بروز بدهی فنی را به حداقل می‌رساند. ضمن آن‌که، با کاهش ابهام و ناسازگاری‌ها، بدهی فنی مستندات نیز کنترل شده و کیفیت نگهداری افزایش می‌یابد.

3. کاهش هزینه تغییرات در طول چرخه عمر نرم‌افزار: تقویت کیفیت آرتیفکت‌های معماری کمک می‌کند تصمیمات کلیدی در مراحل ابتدایی اتخاذ شوند، جایی که اعمال تغییرات کم‌هزینه‌تر است. این اقدام، ریسک پیدایش بدهی فنی ناشی از تغییرات دیرهنگام را پایین آورده و همچنین مانع از رشد بدهی‌های پنهان می‌شود که ممکن است در فازهای عملیاتی آشکار شوند.

4. افزایش درک مشترک و هم‌افزایی تیم: آرتیفکت‌های معماری که به خوبی نگهداری می‌شوند و به‌روز هستند، ابزاری قدرتمند برای افزایش درک مشترک بین اعضای تیم و ذی‌نفعان هستند. این درک مشترک، به هم‌افزایی بیشتر در تیم منجر شده و کارایی کلی توسعه را بهبود می‌بخشد. این موضوع احتمال سوءتفاهم‌های فنی را کاهش داده و بدهی فنی ناشی از ارتباطات ناقص و تصمیم‌گیری ناهماهنگ را محدود می‌کند. به همین ترتیب، ریسک بروز خطاهای تکرار شونده در طراحی نیز کاهش می‌یابد.

به طور خلاصه، بهبود و بهینه‌سازی آرتیفکت‌های معماری نه تنها یک فعالیت مستندسازی، بلکه یک راهبرد مدیریتی برای کنترل و کاهش ریسک‌ها و بدهی‌های فنی است. اجرای این فرآیندها، نیازمند رویکردهای نوین، ابزارهای پیشرفته و تمرکز بر اتوماسیون برای مواجهه با پیچیدگی‌های روزافزون معماری نرم‌افزار است.

رویکردهای نوین بهبود آرتیفکت‌های معماری نرم‌افزار

با پیشرفت فناوری و افزایش نیاز به سرعت و اتوماسیون در توسعه نرم‌افزار، رویکردهای نوین برای تولید و بهبود آرتیفکت‌ها ظهور کرده‌اند:

تولید خودکار آرتیفکت‌ها با بهره‌گیری از مدل‌های زبانی (Language Models): با ظهور مدل‌های زبانی بزرگ (LLMs) و قابلیت‌های آن‌ها در تولید متن، کد و حتی دیاگرام‌ها، امکان تولید خودکار توضیحات معماری، ADRها، و حتی دیاگرام‌های ساده از ورودی‌های متنی یا کدهای موجود فراهم شده است. این رویکرد می‌تواند به کاهش بار مستندسازی دستی کمک کند.

استخراج از کد منبع و DevOps pipelines: ابزارهای مهندسی معکوس (Reverse Engineering) می‌توانند از کد منبع سیستم، مدل‌های ساختاری مانند دیاگرام‌های کلاس یا کامپوننت را استخراج کنند. ادغام این فرآیندها در خطوط DevOps (CI/CD) می‌تواند به حفظ همگام‌سازی بین کد و مستندات کمک کند و آرتیفکت‌ها را به صورت خودکار به‌روز نگه دارد.

استفاده از چارچوب‌های ارزیابی کیفیت (Quality Attribute Scenarios): این چارچوب‌ها (مانند ATAM - Architecture Tradeoff Analysis Method) به ارزیابی سیستم در برابر ویژگی‌های کیفی خاص کمک می‌کنند. با تعریف سناریوهای مشخص برای ویژگی‌هایی مانند کارایی یا امنیت، می‌توان معماری را در مقابل این سناریوها ارزیابی و نقاط ضعف احتمالی را شناسایی کرد.

مدل‌سازی مبتنی بر کد (Code-Centric Modeling): به جای ایجاد مدل‌های جداگانه، این رویکرد بر استفاده از کد به عنوان منبع اصلی حقیقت تأکید دارد و ابزارهایی برای استخراج یا تولید آرتیفکت‌ها به صورت خودکار از کد ارائه می‌دهد. این رویکرد به خصوص در محیط‌های چابک محبوب است.

شناسایی ریسک و بدهی‌های فنی (Risk & Technical Debt Identification): این رویکرد نوین، از ترکیب تحلیل داده‌محور (Data-Driven Analysis)، داده‌های Issue Trackerها (مانند GitHub Issues)، و روش‌های یادگیری ماشین برای شناسایی انواع بدهی‌های فنی، به‌ویژه بدهی فنی معماری (ATD)، استفاده می‌کند. با تحلیل الگوهای زبانی و ساختاری موجود در گزارش‌های مشکل، کامیت‌ها و ADRها، می‌توان ریسک‌های معماری را زودتر شناسایی و مدیریت کرد. مزیت اصلی این رویکرد شناسایی پیش‌دستانه نقاط ضعف و ریسک‌های معماری قبل از تبدیل‌شدن به بحران، کاهش هزینه رفع اشکال، و جلوگیری از انباشت بدهی فنی می‌باشد.

این تنوع در انواع آرتیفکت‌ها و رویکردهای مرتبط، نشان‌دهنده پیچیدگی و پویایی حوزه معماری نرم‌افزار است. انتخاب آرتیفکت‌های مناسب و به کارگیری ابزارهای صحیح، نقش کلیدی در موفقیت پروژه‌های نرم‌افزاری ایفا می‌کند.

در ادامه با تمرکز بر آخرین رویکرد گفته شده پیش می‌رویم و جزییات بیشتری را بیان می‌کنیم.

شناسایی بدهی فنی معماری از آرتیفکت‌ها

بررسی‌ها نشان می‌دهد که بخشی از بدهی‌ها، به‌ویژه بدهی‌های مرتبط با معماری، نه‌تنها در کد منبع بلکه در سیستم‌های ردیابی خطا و وظایف مانند GitHub Issues نیز قابل شناسایی هستند.

مطالعات متعددی این موضوع را تأیید کرده‌اند (مشاهده بیشتر در قسمت مراجع). این مطالعات نشان دادند که بسیاری از بدهی‌های فنی ثبت‌شده در Issue Trackerها ریشه در تغییرات یا تصمیمات معماری دارد و چرخه عمر آن‌ها معمولاً طولانی‌تر از سایر بدهی‌هاست. Zhang و همکاران (2023) با آموزش مدل BERT-base بر روی Issue حاوی Self-Admitted Technical Debt (SATD)، به دقت بالایی در طبقه‌بندی نوع بدهی فنی دست یافتند. در مقاله‌ای برای 2025 با ارائه دیتاست BEACon‑TD شامل ۱۳ نوع بدهی فنی استخراج‌شده از ۳۵ پروژه GitHub، نشان دادند که ترکیب داده‌های Issue با متادیتاهای ADR می‌تواند شناسایی بدهی معماری را بهبود دهد.

معماری نرم‌افزار چارچوب بنیادینی است که ساختار، رفتار و تعاملات اجزا را در یک سامانه نرم‌افزاری تعیین می‌کند. کیفیت تصمیمات معماری به‌طور مستقیم بر کارایی، توسعه‌پذیری، قابلیت نگهداشت و مقیاس‌پذیری سیستم اثرگذار است. هرچند این تصمیمات بر اساس بهترین دانش و منابع موجود در زمان اخذ اتخاذ می‌شوند، اما محدودیت‌های زمانی، فشار بازار، کمبود منابع و تغییر نیازمندی‌ها سبب می‌شود برخی تصمیمات منجر به ایجاد بدهی فنی (Technical Debt – TD) شوند.

بر اساس پژوهش‌های انجام شده بیش از نیمی از بدهی‌های فنی شناسایی‌شده در مخازن نرم‌افزاری ریشه در تصمیمات معماری دارد. این بدهی‌ها نه‌تنها در کد منبع بلکه در بایگانی Issue Tracker ها نیز مستند می‌شوند. داده‌های Issue Tracker (نظیر GitHub Issues) به دلیل انعکاس مستقیم تجربه توسعه‌دهندگان، یک منبع واقع‌گرایانه و کم‌هزینه برای شناسایی بدهی فنی محسوب می‌شود.

به‌طور سنتی، شناسایی TD عمدتاً بر تحلیل کد و متریک‌های استاتیک متمرکز بوده است. رویکردهای جدیدتر – به ویژه بعد از سال ۲۰۱۸ – نشان داده‌اند که تحلیل متون موجود در Issues و Pull Requests می‌تواند موارد Self-Admitted Technical Debt (SATD) را آشکار کند؛ مواردی که خود توسعه‌دهندگان به‌صراحت به وجودشان اعتراف کرده‌اند.

اهمیت موضوع شناسایی ریسک و بدهی فنی

مدیریت بدهی فنی نه‌تنها در پروژه‌های متن‌باز که غالباً مشارکت‌کنندگان متعدد و توزیع شده دارند، بلکه در سامانه‌های صنعتی نیز اهمیت مضاعف دارد. وجود بدهی‌های معماری می‌تواند چرخه توسعه را کند، زمان رفع باگ را طولانی و خطر بروز اشکالات امنیتی یا افت کارایی را افزایش دهد. در مقابل، تصمیمات معماری مستندشده (Architectural Decision Records – ADRs) امکان رهگیری ریشه‌های بدهی و بررسی پیامدهای انتخاب‌ها را فراهم می‌کند.

استفاده از اطلاعات ADR و داده‌های Issues برای:

- شناسایی بدهی‌های معماری زودهنگام

- پیش‌بینی نقاط بحرانی در توسعه آینده

- مدیریت ریسک

امکان ایجاد رویکردی داده‌محور در مدیریت معماری را فراهم می‌آورد. در دیتاست BEACon‑TD نشان دادند که تلفیق متادیتاهای معماری و توصیف Issues می‌تواند در شناسایی ۱۳ نوع مختلف TD کارایی بالایی داشته باشد.

پیشینه پژوهش و کارهای مرتبط

بدهی فنی نخستین بار به‌عنوان یک استعاره در مهندسی نرم‌افزار، مطرح شد، اما بعدتر رویکردهای سیستماتیک برای شناسایی و مدیریت آن مورد توجه جامعه علمی قرار گرفت. با گسترش پروژه‌های متن‌باز و استفاده وسیع از Issue Trackerها مانند GitHub Issues، محققان دریافتند که اطلاعات ارزشمندی درباره بدهی فنی در این داده‌ها نهفته است.

پژوهش‌های اولیه

Fontana و همکاران (2015) نخستین مطالعات صنعتی را در شناسایی «ریشه‌های معماری» بدهی فنی ارائه کردند. آن‌ها در یک پروژه طول‌عمر بالا نشان دادند که عمده ATD ناشی از تصمیماتی است که بدون تحلیل اثرات بلندمدت اتخاذ شده‌اند و هیچ بازبینی‌ای روی پروژه‌ها صورت نگرفته است . نتیجه کلیدی این مطالعه: کد اسمل‌ها (Code Smells) می‌توانند نشانه‌هایی از فرسودگی کد و مشکلات بالقوه نگهداری باشند که با به‌کارگیری بازآرایی (Refactoring) مناسب قابل پیشگیری‌اند.

در همین بازه، Maldonado و Shihab مفهوم Self-Admitted Technical Debt (SATD) را به Issue Trackerها تعمیم دادند. آن‌ها با تحلیل تعداد زیادی Issue در پروژه‌های متعدد، نشان دادند که توسعه‌دهندگان اغلب خود به وجود بدهی اذعان می‌کنند و این اطلاعات می‌تواند مبنای برچسب‌گذاری داده برای یادگیری ماشین باشد.

گسترش رویکردهای NLP و یادگیری ماشین (۲۰۱۹–۲۰۲۲)

با پیشرفت پردازش زبان طبیعی و مدل‌های یادگیری عمیق، پژوهشگران شروع به استفاده از مدل‌های word embedding و Transformer برای شناسایی TD در متون Issues کردند.

در مطالعات اخیر رویکردی نوین برای شناسایی بدهی فنی اظهارشده که تلفیقی از مدل‌سازی برداری واژگان با Word2Vec و طبقه‌بندی با استفاده از ماشین بردار پشتیبان (SVM) بوده است. این روش با بهره‌گیری از نمایش‌های معنایی متراکم، توانست محدودیت رویکردهای سنتی مبتنی بر کلیدواژه را پشت سر بگذارد و در شاخص‌های دقت و recall عملکرد بالاتری ارائه کند. مزیت کلیدی این رویکرد در آن بود که مدل قادر شد حتی مواردی را که دارای اصطلاحات مستقیم بدهی فنی نبودند، ولی از نظر معنایی مشابه بودند، شناسایی کند.

در ادامه محققان متعددی با روش‌های مختلف با ایجاد یک مجموعه‌ داده‌ی عمومی و بزرگ شامل ‌Issueهای برچسب‌گذاری‌شده از پروژه‌های متن‌باز، زیرساختی برای ارزیابی منسجم روش‌های شناسایی بدهی فنی فراهم کردند. آن‌ها با به‌کارگیری روش‌های نوین یادگیری ماشین از جمله شبکه‌های عصبی حافظه بلندمدت (LSTM) نشان دادند که مدل‌های توالی‌محور به‌واسطه‌ی توانایی در حفظ و تحلیل وابستگی‌های زمانی در متن، قادرند نشانه‌های پراکنده و غیرپیوسته بدهی فنی را که در طول چند جمله یا پاراگراف توزیع شده‌اند، به‌طور مؤثر شناسایی کنند.

در یک مطالعه مهم دیگر، Parra و همکاران (2022) در مقاله «On the documentation of self‑admitted technical debt in issues» (Empirical Software Engineering) کارایی BERT-base را در طبقه‌بندی SATD با F1-score نزدیک به ۰.۸۵ گزارش کردند.

از ۲۰۲۳ به بعد، مطالعات بیش‌ از پیش به ارتباط بین ADRs و TD توجه کرده‌اند.

بررسی‌ها نشان داده‌اند که بخش قابل‌توجهی از بدهی‌های فنی ثبت‌شده در سامانه‌های ردیابی، ریشه در تصمیمات معماری دارد. به‌کارگیری روش‌های یادگیری عمیق توانسته عملکرد قابل قبولی در شناسایی این بدهی‌ها ارائه دهد، و ترکیب داده‌های مربوط به تصمیمات معماری با محتوای متنی Issues منجر به بهبود چشمگیر دقت شناسایی شده است.

در یک جمع‌بندی کلی، روند پژوهش‌ها در حوزه بدهی فنی نشان می‌دهد که ابتدا تلاش‌ها بر تعریف مفاهیم و شناسایی پایه‌ای انواع بدهی، به‌ویژه بدهی‌های معماری و بدهی‌های فنی اظهارشده، متمرکز بوده است. به مرور زمان، استفاده از داده‌های سامانه‌های ردیابی مسئله‌ها به عنوان منبعی ارزشمند برای شناسایی و تحلیل این بدهی‌ها جایگاه ویژه‌ای پیدا کرده است. با ورود روش‌های پردازش زبان طبیعی و یادگیری ماشین، به‌ویژه مدل‌های مبتنی بر نمایش برداری اسناد و سپس معماری‌های پیشرفته‌تر مانند ترنسفورمرها، دقت و کارایی شناسایی به شکل قابل ملاحظه‌ای افزایش یافته و امکان تحلیل ابعاد مختلف از جمله ماهیت معماری بدهی‌ها فراهم شده است. این مطالعات همچنین به بررسی چرخه عمر بدهی‌ها، ارتباط تنگاتنگ آن‌ها با تصمیمات معماری، و کاربرد ابزارهای خودکار برای ردیابی و پیش‌بینی روندها پرداخته‌اند. در نهایت، ترکیب داده‌های معماری با اطلاعات متنی Issues به عنوان رویکردی نوین، نتایج بهتری در شناسایی و مدیریت بدهی فنی ارائه کرده است.

جمع‌بندی شکاف‌ها و مسیر پژوهش حاضر

طی یک دهه‌ی گذشته، مسیر پژوهش در حوزه شناسایی و تحلیل بدهی فنی اظهارشده (SATD) و بدهی فنی معماری (ATD) پیشرفت قابل‌توجهی داشته است. با این حال، مرور نظام‌مند مطالعات پیشین نشان می‌دهد که چند خلأ اصلی همچنان پابرجاست. نخست آن‌که، چارچوبی یکپارچه و عملیاتی که بتواند داده‌های حاصل از سامانه‌های ردیابی مسئله‌ها (Issue Trackers) و سوابق تصمیمات معماری (Architectural Decision Records – ADRs) را به صورت همزمان پردازش و تحلیل کند، هنوز شکل نگرفته است. دوم، بسیاری از پژوهش‌ها صرفاً بر یک نوع ویژگی( معمولاً ویژگی‌های متنی) تمرکز داشته‌اند و استفاده‌ی همزمان و هدفمند از ویژگی‌های متنی و ساختاری در مدل‌های یادگیری عمیق کمتر مورد توجه قرار گرفته است. سوم، نبود یک مجموعه داده‌ی عمومی و جامع که به طور خاص پیوند میان ATD و تصمیمات معماری را پوشش دهد و یا جامعیتی برای شناسایی، تحلیل و پیشنهاد برای حل ریسک‌ها و بدهی فنی را دارا باشد، باعث شده مطالعات مقایسه‌ای و بازتولید نتایج به سختی ممکن باشد؛ تنها در سال ۲۰۲۵ و با معرفی مجموعه داده و چارچوب BEACon‑TD بخشی از این نیاز پاسخ داده شد، ولی همچنان شکاف موجود به طور کامل پر نشده است.

پیشنهادهای ادامه کار

برای توسعه این حوزه، چند مسیر کلیدی پیشنهاد می‌شود:

1. گسترش دامنه داده به پروژه‌های صنعتی و تجاری برای بررسی الگوهای عملی ATD.

2. پشتیبانی از چند زبان و ارزیابی عملکرد مدل در محیط‌های غیرانگلیسی.

3. توسعه ماژول پیش‌بینی بدهی قبل از وقوع، بر پایه شاخص‌های فرآیندی (تعداد Pull Requestهای باز و بسته‌شده در ماه، مدت‌زمان بررسی کد (Code Review Time)، تعداد تغییرات در مستندات معماری در بازه‌های زمانی، میزان تأخیر در Merge یا پیاده‌سازی فیچرها، فاصله زمانی باز شدن یک issue تا بسته شدن آن و ...).

4. تحلیل اثرات عوامل اجتماعی–فنی بر شکل‌گیری و رفع بدهی.

5. ادغام چارچوب پیشنهادی با ابزارهای DevOps و ایجاد داشبورد نظارت بلادرنگ.

6. گسترش دامنه داده به پروژه‌های صنعتی و تجاری برای بررسی بیشتر و بهتر Issue Tracker ها.

با توجه به شکاف‌های شناسایی‌شده و نتایج به‌دست‌آمده، تحقیق حاضر بنیانی فراهم کرده که می‌تواند در مطالعات بعدی و بهبودهای عملی، گامی مهم در جهت مدیریت مؤثر بدهی‌های معماری و بهبود آرتیفکت های معماری نرم‌افزار باشد.

سخن پایانی

با توجه به گسترش و پیچیدگی روزافزون سیستم‌های نرم‌افزاری، مدیریت فعالانه‌ی ATD نباید یک فعالیت جانبی باشد، بلکه باید بخشی بنیادین از چرخه توسعه تلقی شود. یافته‌های این پژوهش نشان می‌دهد که تحلیل متنی و ساختاری Issues و داده‌های ADR، می‌تواند حفره بسیاری از تلاش‌های مدیریت بدهی فنی را پر کند و در نتیجه موجب رشد بهتر و دقیق‌تر آرتیفکت‌های معماری نرم‌افزار شود. این مسیر، هم در حوزه‌ی پژوهشی و هم در کاربرد صنعتی، ظرفیتی برای بهبود کیفیت و پایداری محصولات نرم‌افزاری فراهم می‌آورد.