ملخص تقني: REFINE – نهج متعدد الوكلاء يعتمد على النماذج اللغوية الكبيرة لإعادة هيكلة الكود الموجهة بالأدلة

بيان المشكلة

بينما تُظهر النماذج اللغوية الكبيرة (LLMs) قدرات قوية في توليد وتحويل الكود، فإن تطبيقها على إعادة هيكلة البرمجيات (Refactoring) يواجه تحديات جسيمة. تتطلب إعادة الهيكلة الفعالة ليس فقط تعديل الكود لتقليل مشكلات الجودة (روائح الكود - Code Smells)، بل تضمن أيضاً عدم إدخال عيوب جديدة، أو تغيير السلوك الخارئي، أو إزالة عناصر هيكلية حرجة (مثل واجهات برمجة التطبيقات العامة - Public APIs، أو جمل التأكيد - Assertions).

تفتقر أساليب إعادة الهيكلة الحالية المدعومة بالنماذج اللغوية الكبيرة غالباً إلى التحقق الصارم، مما يؤدي إلى مخاطر مثل الاقتراحات الوهمية (Hallucinations)، والتحويلات غير المتسقة، وإزالة هياكل الكود ذات الصلة بالسلوك. هناك حاجة إلى نهج منهجي يقوم بـ:

1. توجيه النماذج اللغوية الكبيرة بالأدلة المستمدة من التحليل الساكن (Static Analysis).
2. تنسيق سير عمل متعدد الوكلاء للتخطيط، والتوليد، والتحقق من التغييرات.
3. توفير أدلة قابلة للتتبع لما تم تغييره، وما هي المخاطر المتبقية، وما إذا كان المخرج مرشحاً صالحاً لإعادة الهيكلة وليس مجرد حل مقبول تلقائياً.

المنهجية: سير عمل REFINE

يقدم المؤلفون REFINE (إعادة الهيكلة عبر تدفق مدرك للأدلة للتنفيذ المتكامل للوكلاء)، وهو إطار عمل متعدد الوكلاء، مستقل عن الأدوات، ومدرك للأدلة، مصمم لإعادة هيكلة ملفات Java على مستوى الملف. تم تنفيذ النظام كنموذج بحثي أولي باستخدام واجهة Next.js، وخلفية Java Spring Boot (للتحليل الساكن عبر PMD 7.x)، وخدمة وكيل Python (باستخدام LangGraph v1.1) للتنسيق.

يعمل سير العمل من خلال ثلاث مراحل رئيسية:

1. توصيف المهمة (Task Characterization)

• المدخلات: ملف Java واحد من مشروع مفتوح المصدر.
• جمع الأدلة: يقوم التحليل الساكن (PMD) بتحديد روائح الكود على مستوى الملف والأدلة على مستوى القواعد.
• السياق: يقوم النظام باستخراج تواقيع واجهة برمجة التطبيقات العامة (Public API signatures)، وسياق مساحة العمل، وتحديد أولويات الروائح المكتشفة لتشكيل مهمة إعادة هيكلة محددة النطاق.

2. تنسيق إعادة الهيكلة (Refactoring Orchestration)

ينسق سير العمل أحد عشر دوراً متميزاً (وكلاء) لإدارة العملية:

• وكيل التخطيط (Planning Agent): يجمع بين التوجيه الحتمي القائم على القواعد مع تحسين اختياري من النموذج اللغوي الكبير لإنشاء خطة إعادة هيكلة موجهة نحو "الرائحة".
• وكيل إعادة الهيكلة (Refactoring Agent): يستدعي نموذجاً لغوياً كبيراً لتوليد تحويل مرشح بناءً على الخطة، والمصدر الأصلي، والقيود (مثل الحفاظ على واجهات برمجة التطبيقات العامة).
• وكيل التحقق (Verification Agent): يحلل المرشح المولد مقابل فحوصات الأدلة المهيأة قبل الاحتفاظ به.

3. تتبع التحقق والتحليل (Verification Trace & Analysis)

لا يعامل REFINE مخرجات النموذج اللغوي الكبير كناتج نهائي. بدلاً من ذلك، يعيد تحليل الملف المحول لحساب:

• تقليل الروائح: التحسن المطلق ($\Delta_{smell} = B - A$) والتحسن النسبي في روائح الكود المكتشفة.
• وسطاء الحفاظ الساكن (Static Preservation Proxies): فحص الحفاظ على واجهات برمجة التطبيقات العامة، ومعالجة الاستثناءات، وعقود الإطار البرمجي (Framework Contracts)، والمنطق الشرطي، واستدعاءات assert/fail الحرجة.
• تشخيصات الفشل: تسجيل أسباب محددة للرفض (مثل إزالة طريقة عامة/Public Method).
• القابلية للتتبع: حفظ المصدر الأصلي، والمرشح المولد، وخطوات الوكيل، والمقاييس، ونتائج التحقق لربط كل قرار بأدلته.

التصميم التجريبي

• مجموعة البيانات: 450 ملف Java من 15 نظاماً مفتوح المصدر (مثل JHotDraw، Apache Ant، Guava، JabRef)، تم اختيارها عبر أخذ عينات عشوائية طبقية بناءً على عدد روائح الكود وعدد أسطر الكود (LOC).
• تكوينات النماذج اللغوية الكبيرة: تم تقييم ثلاثة نماذج رائدة: OpenAI GPT-5.5، وGoogle Gemini 3.1 Pro Preview، وAnthropic Claude Opus 4.8.
• النطاق: نتج عن ذلك 1,350 مخرجاً من عمليات مرور النماذج.
• المعيار المرجعي (Baseline): تم إجراء تجربة مباشرة (Direct-prompt baseline) على مجموعة فرعية مكونة من 150 ملفاً لمقارنة سير عمل الوكلاء المتعددين مقابل التلقين البسيط.
• المقاييس: تقليل رائحة الكود، مؤشرات الجودة (التعقيد الدوري/Cyclomatic Complexity، مؤشر القابلية للصيانة/Maintainability Index، إلخ)، التغييرات الهيكلية، ومخاطر الحفاظ.

النتائج الرئيسية

1. تقليل رائحة الكود (RQ1)

حقق REFINE تخفيضات جوهرية في روائح الكود المكتشفة عبر جميع تكوينات النماذج الثلاثة:

• إجمالي التخفيض: 68.26% (GPT-5.5)، و72.79% (Gemini 3.1)، و68.49% (Opus 4.8).
• الروائح الكبرى: كانت التحسينات الأكثر أهمية في الروائح الكبرى (تخفيض بنسبة 86.51% إلى 91.60%).
• مؤشرات الجودة: لم تكن التحسينات في مقاييس الجودة الأوسع موحدة؛ فبينما أظهر Gemini 3.1 تخفيضات كبيرة في التعقيد الدوري (Cyclomatic Complexity) وLCOM، أظهرت المقاييس الأخرى (مثل القابلية للصيانة، القابلية للاختبار، وجهد Halstead) تغييرات مختلطة أو سلبية اعتماداً على النموذج.

2. الحفاظ والمخاطر (RQ2)

• معدلات النجاح العالية: اجتازت معظم مؤشرات الحفظ الساكن (تواقيع الطرق العامة، معالجة الاستثناءات، عقود الإطار البرمجي) الاختبار بمعدلات عالية (81.8% إلى 94.2%).
• المخاطر الحرجة:
  • استدعاءات Assert/Fail: حافظت 57.1% فقط من المخرجات على استدعاءات assert/fail الحرجة عبر جميع النماذج، مما يشير إلى خطر منهجي.
  • إزالة الطرق العامة (Public Method Removal): كان هذا هو الفشل التشخيصي الأكثر وضوحاً. أظهر Gemini 3.1 أعلى معدل لإزالة الطرق العامة (71 حالة)، يليه GPT-5.5 (41 حالة)، ثم Opus 4.8 (34 حالة).

3. سلوك إعادة الهيكلة (RQ3)

حققت النماذج المختلفة تقليل الروائح من خلال ملفات تعديل متميزة:

• GPT-5.5: أنتج التعديلات الأكثر إيجازاً.
• Gemini 3.1: أظهر ملفاً "كثيف الحذف"، حيث أزال أكبر عدد من الأسطر والطرق.
• Opus 4.8: أظهر ملفاً "كثيف الاستخراج" مع أعلى عدد من استخراجات الدوال (Method Extractions).
• الارتباط: ارتبط حجم التعديلات الأكبر بتقليل مطلق أعلى في رائحة الكود، ولكن ليس بالضرورة تقليلاً نسبياً أعلى.

4. المقارنة مع التلقين المباشر (Direct Prompting)

في المجموعة الفرعية المتطابقة المكونة من 150 ملفاً، تفوق REFINE على التلقين المباشر في:

• تقليل الروائح: متوسط إجمالي التخفيض 100.0% (REFINE) مقابل 20.8% (التلقين المباشر).
• بصمة التعديل (Edit Footprint): أقل متوسط للتغيير (14 سطراً مقابل 65 سطراً).
• سلامة واجهة برمجة التطبيقات (API Safety): عدد أقل من حالات إزالة الطرق العامة (46 حالة مقابل 112 حالة).
• المقايضة: حافظ التلقين المباشر على بنى assert/fail الحرجة بشكل أكثر تكراراً (100% مقابل 58%).

الأهمية والادعاءات

تضع الورقة البحثية REFINE ليس كبديل لأدوات إعادة الهيكلة التي تحافظ على السلوك، بل كآلية قابلة للتتبع ومدركة للأدلة لتوليد وتقييم مرشحي إعادة الهيكلة.

• الإدراك بالأدلة: المساهمة الأساسية هي ربط الكود المولد بالأدلة الساكنة المحددة (الروائح) التي استدعت التغيير، وبفحوصات التحقق التي نجح فيها أو فشل.
• التوليد المنضبط: يوفر سير عمل الوكلاء المتعددة توليداً أكثر انضباطاً للمرشحين مقارنة بالتلقين المباشر، مما يؤدي إلى تعديلات أصغر وأقل في إزالة واجهات برمجة التطبيقات العرضية، رغم أنه لا يقضي على جميع المخاطر السلوكية.
• القيود: يذكر المؤلفون صراحة أن المخرجات المولدة هي مرشحات (Candidates) وليست حلولاً جاهزة للإنتاج. فحوصات الحفاظ الساكن هي مجرد "وسطاء" ولا تثبت التكافؤ السلوكي.
• الآثار العملية: تتطلب المرشحات المولدة عمليات تجميع (Compilation)، واختبار، وتحليل تبعيات، ومراجعة بشرية قبل الاعتماد، خاصة في البيئات الغنية بالاعتمادات أو الأنظمة المعقدة.

تخلص الدراسة إلى أنه بينما تعد سير العمل متعدد الوكلاء المدرك للأدلة واعدة لتخفيف روائح الكود المستهدفة على مستوى الملف، فإن لا التلقين المباشر ولا نهج الوكلاء المتعددين يوفران حالياً أدلة كافية على الحفاظ الكامل على السلوك للعمل بشكل مستقل في النظم البرمجية المعقدة.