ما وراء التصديرات المفقودة: بناء نظام مبكر لجمع المهملات
حاولت استخدام إضافة (plugin) قياسية لإصلاح الروابط المفقودة في وثائق Webpack، لكنها فشلت.
إن دمج إضافة في قاعدة كود ضخمة ليس بالمهمة السهلة، بل تحول الأمر إلى تحدٍ معماري. كان عليّ إدارة معالجة شجرة البنية المجردة (AST)، واستهلاك الذاكرة، والحلقات التكرارية (recursive loops).
المشكلة في الإضافات القياسية
أجريت ثلاث تجارب للوصول إلى حل.
التجربة 1: استعادت الإضافة 135 نوعاً (types). ومع ذلك، وضعتها في وحدة (module) داخلية، بينما قامت أداتنا بإنشاء مجلد منفصل لها، مما اضطرنا لفرزها يدوياً. كما كانت الوثائق خاطئة من الناحية الهيكلية.
التجربة 2: قمت بتفعيل إعداد لإخفاء الأنواع الخارجية. نجح هذا الأمر في بعض الجوانب، حيث قلل حجم البيانات (payload) إلى 60 نوعاً من أنواع Webpack. لكن TypeDoc تجاهل التبعيات المتداخلة (nested dependencies)، مما أبقى العديد من الأنواع مخفية بينما لا تزال تستهلك الذاكرة.
التجربة 3: حاولت ربط الأنواع بوحداتها الأصلية، مما تسبب في حلقة تكرارية (recursive loop). استمرت الإضافة في استخراج الواجهات (interfaces) المتداخلة حتى أنشأت 630 نوعاً. كانت الوثائق مليئة بالضجيج (noise)، مما أفسد تجربة المستخدم.
الحل: جمع المهملات المبكر (Early Garbage Collection)
كنت بحاجة إلى الأنواع في وحداتها الصحيحة دون الضجيج الإضافي. توقفت عن محاولة إصلاح المخرجات وبدأت في إصلاح العملية نفسها.
استخدمت خطافاً (hook) يسمى EVENT_RESOLVE_END. سمح لي ذلك باعتراض الـ AST مباشرة بعد عملية الربط (resolution). قمت بذلك قبل أن يقوم TypeDoc بتعيين الفئات أو استهلاك كمية كبيرة من الذاكرة.
اتبع منطقي ثلاث خطوات:
- البحث عن الوحدة الداخلية في الـ AST.
- فحص كل عقدة (node) باستخدام أداة مساعدة مخصصة.
- حذف الضجيج. استخدمت
project.removeReflectionلحذف 300 عقدة غير ضرورية على الفور، مما سمح لـ Node.js بتحرير الذاكرة. - نقل الأنواع المهمة. قمت بدمج الـ 300 نوع المتبقية في النطاق الجذر (root scope).
النتيجة: نجحت في إنقاذ 240 نوعاً حيوياً، وهي الآن مرئية وموجهة بشكل صحيح. كما تجنبت الضجيج التكراري الذي ظهر في التجربة الثالثة.
الدروس المستفادة
• التعامل مع الـ AST في مرحلة مبكرة؛ فحذف العقد غير الضرورية يمنع هدر الذاكرة لاحقاً. • استخدام الـ hooks بدلاً من الحلول الالتفافية (hacks)؛ ففهم دورة حياة المترجم (compiler lifecycle) يتيح عملاً نظيفاً. • الملاحظات تحسن المعمارية؛ فقد ساعدتني مراجعات المشرفين (maintainers) في بناء نظام أفضل. • زيادة البيانات لا تعني دائماً الأفضل؛ فالهندسة الجيدة تعني إيجاد التوازن بين البيانات وسهولة الاستخدام.