CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

تخيل أنك تراقب مدينة تنمو. يمكنك عدّ عدد الطوب الذي يُوضع كل يوم، أو يمكنك التحقق مما إذا كان مجلس المدينة قد اتبع القواعد. ولكن هناك طريقة ثالثة، أكثر إثارة للاهتمام، للنظر إلى المدينة: راقب كيف تتغير المباني. هل يهدم الناس الجدران القديمة لإضافة غرفة جديدة؟ هل يبنون جناحًا جديدًا يتصل بالجانب دون لمس المنزل الرئيسي؟ هل يكتفون فقط بتبديل مفتاح لتغيير الإضاءة؟ أم أنهم ببساطة يعيدون ترتيب الأثاث؟ في عالم برمجيات الكمبيوتر، هذا هو بالضبط السؤال الذي يطرحه الباحثون. البرمجيات ليست مجرد كود؛ إنها نظام حي يجب أن يتغير باستمرار ليبقى مفيدًا. إذا كان النظام يتغير فقط عن طريق هدم جدرانه الخاصة، فسيتحول في النهاية إلى فوضى مهتزة وخطيرة. أما إذا كان يتغير عن طريق إضافة أجنحة جديدة أو تبديل المفاتيح، فسيظل قويًا ومرنًا. هذا هو جوهر "جودة البرمجيات" — ليس فقط ما إذا كان الكود يعمل اليوم، بل ما إذا كان بإمكانه الاستمرار في النمو دون أن ينهار غدًا.

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

1. التعديل (Modification - M): نهج "هدم الجدران". تغيير الكود الأساسي مباشرة. إنه سريع ولكنه محفوف بالمخاطر، مثل حفر ثقب في جدار لإضافة باب.
2. التوسيع (Extension - E): نهج "الإضافة". بناء ميزات جديدة تتصل بالنظام دون لمس الجوهر، مثل إضافة غرفة جديدة إلى منزل.
3. البرمجة منخفضة الكود (Low-code - L): نهج "المخطط الانسيابي". استخدام أدوات مرئية أو قواعد لتغيير السلوك، مثل مدير أعمال يعيد ترتيب سير العمل دون كتابة كود.
4. التكوين (Configuration - C): نهج "المفتاح". مجرد تغيير الإعدادات أو المعايير، مثل تدوير قرص لتغيير مستوى الصوت.

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

دفتر ملاحظات المحقق الجديد: كيف يعمل CLEM

تخيل تطوير البرمجيات مثل مطبخ مزدحم. لسنوات، تم قياس الطهاة (المطورين) بمدى عدد الأطبى التي يطهونها (حجم النشاط) أو مدى نظافة المطبخ في نهاية الليل (فحوصات الكود الثابتة). ولكن ماذا لو كان المطبخ ينهار لأنهم في كل مرة يحتاجون فيها إلى توابل جديدة، يضطرون لتحطيم جدار للوصول إلى خزانة المؤن؟ هذه هي المشكلة التي يحلها CLEM. فهو لا يكتفي بعدّ الأطباق؛ بل يراقب الطريقة التي يستخدمها الطهاة للحصول على المكونات.

يقترح البحث أنه في كل مرة يتم فيها تحديث نظام برمجي، يحدث التغيير بواحدة من أربع طرق، ومزيج هذه الطرق يخبرنا بكل شيء عن صحة النظام.

• التعديل (M) هو أسلوب "القوة الغاشمة". إنه مثل طاهٍ يمسك بمطرقة ثقيلة لتحطيم جدار لأنه يحتاج إلى رف جديد. إنه ينجز المهمة بسرعة، ولكن إذا فعلت ذلك كثيرًا، فسيصبح المبنى بأكمله غير مستقر.
• التوسيع (E) هو الأسلوب "النمطي". إنه مثل بناء عربة جديدة قابلة للفصل تتدحرج داخل المطبخ. الطاهي لا يلمس الجدران؛ هو فقط يضيف أداة جديدة. هذا أكثر أمانًا ويحافظ على البنية الأساسية سليمة.
• البرمجة منخفضة الكود (L) هو أسلوب "المخطط". تخيل مديرًا يرسم مسارًا جديدًا على سبورة بيضاء يخبر الروبوتات بما يجب فعله، دون الحاجة إلى إعادة برمجة الروبوتات. إنها طريقة عالية المستوى لتغيير الأشياء.
• التكوين (C) هو أسلوب "القرص". هو مجرد تدوير مقبض لجعل الفرن أكثر سخونة أو جعل الأضواء أكثر سطوعًا. لا حاذجة للبناء على الإطلاق.

يجادل المؤلفون بأن أي نظام برمجيات صحي وطويل الأمد يجب أن يعتمد أكثر على التوسيع، والبرمجة منخفضة الكود، والتكوين، وأقل على التعديل. إذا كان النظام يقوم باستمرار بـ "تعديل" جوهره، فمن المرجح أنه يراكم "الديون التقنية" — وهي طريقة منمقة للقول بأنه يقترض الاستقرار من المستقبل وسيتعين عليه دفعه مع الفائدة لاحقًا.

التجربة: مراقبة ثلاثة مطابخ

ليروا ما إذا كانت هذه الفكرة تعمل، قام الباحثون برحلة ميدانية إلى ثلاثة "مطابخ" (مستودعات برمجية). لم ينظروا فقط إلى الأطباق النهائية؛ بل راقبوا أيدي الطهاة لشهور.

1. مطبخ "Fit" (fit-framework): كان مشروعًا عامًا مصممًا ليكون نظام إضافات (plugins). توقعوا أن يكون مليئًا بـ "التوسيعات" (E).
2. مطبخ "App" (app-platform): كان مشروعًا عامًا آخر، ولكنه بُني للتصميم المرئي منخفض الكود. توقعوا أن يكون مليئًا بـ "البرمجة منخفضة الكود" (L) و"التكوين" (C).
3. مطبخ "Antisuger": كان تطبيق رعاية صحية خاص لإدارة نسبة السكر في الدم. تم بناؤه بواسطة فريق مختلف وبأدوات مختلفة. توقعوا أن يكون في مرحلة مبكرة وفوضوية، ومن المرجح أن يكون مليئًا بـ "التعديلات" (M).

قام الباحثون بتحليل 607 تحديثًا محددًا (commits) عبر هذه المشاريع. استخدموا مجموعة من القواعد الشفافة للنظر في الملفات التي يتم تغييرها. إذا كان الملف في مجلد "إضافات"، فسيعدونه "توسيعًا". إذا كان ملف "تدفق"، فسيعدونه "برمجة منخفضة الكود". إذا كان ملف كود أساسي، فسيكون "تعديلاً".

ماذا وجدوا: الأنظمة بدت مختلفة

كانت النتائج تمامًا كما توقعت نظرية "المطبخ الصحي".

• كان App-platform بالفعل "خارجيًا" للغاية. حوالي 69.5% من تغييراته كانت توسيعات، مع القليل جدًا من التعديل المباشر للجوهر. سجل "CLEM-ES" الخاص به (وهو مقياس لمدى دفع التغيير بعيدًا عن الجوهر) كان قويًا عند +0.685.
• كان Fit-framework مزيجًا. كان يحتوي على الكثير من التوسيعات (33.4%)، ولكنه كان يحتوي أيضًا على جزء كبير من التعديلات (29.1%). سجله كان +0.418، مما يظهر أنه كان أكثر صحة من الفوضى المحضة، ولكنه لم يكن "خارجيًا" مثل منصة التطبيق (App platform).
• كان تطبيق الرعاية الصحية Antisuger هو العكس تمامًا. كان يهيمن عليه "التعديل" بشكل شبه كامل، حيث كانت 83.0% من تغييراته تعديلات مباشرة على الجوهر. سجله كان -0.659، مما يشير إلى أنه كان لا يزال في مرحلة هشة من "تعديل الجدران".

أثبت هذا أن CLEM يمكنه بنجاح رصد الفرق بين نظام ينمو عن طريق إضافة أجنحة ونظام ينمو عن طريق تحطيم الجدران. حتى أن الباحثين تحققوا مما إذا كانت قواعدهم عادلة من خلال جعل شخصين بشريين ينظران إلى 160 تحديثًا عشوائيًا. وقد اتفقا بنسبة 100% على الفئة الرئيسية، مما يشير إلى أن القواعد متينة وقابلة للتكرار.

التحول المفاجئ: البنية لا تتنبأ بالأخطاء (بعد)

هذا هو الجزء الذي يتوخى فيه البحث الحذر الشديد. قد تعتقد: "إذا كان النظام يحطم جدرانه (تعديل عالٍ)، فيجب أن ينكسر أكثر، أليس كذلك؟" اختبر الباحثون هذا الأمر. بحثوا فيما إذا كانت درجات CLEM يمكن أن تتنبأ بما إذا كان الشهر التالي سيشهد المزيد من "إصلاح الأخطاء".

الإجابة؟ لا يوجد رابط واضح.
في بياناتهم، لم تتنبأ درجة "التعديل" بشكل موثوق بما إذا كان الشهر التالي سيكون مليئًا بإصلاح الأخطاء. كما أن درجة "CLEM-ES" (مدى خارجية التغييرات) لم تكن لها أي ارتباط يذكر مع إصلاحات الأخطاء المستقبلية في هذه العينة المحددة.

هذه نتيجة حاسمة. يوضح المؤلفون صراحةً أن CLEM ليس بلورة سحرية للتنبؤ بالعيوب. إنه لا يحل محل الطرق القديمة لعد الأخطاء أو تغير الكود. بدلاً من ذلك، فإنه يقدم نوعًا مختلفًا من الرؤى. إنه يخبرك عن الوضعية الهيكلية للنظام. نظام ذو درجة تعديل عالية قد لا يحتوي على مزيد من الأخطاء اليوم، ولكنه يبني هيكلًا يصعب صيانته ومن المرجح أن يصبح هشًا بمرور الوقت. الأمر يشبه مبنى غير مستقر هيكليًا؛ قد لا ينهار اليوم، لكن المخطط الهندسي سيء.

لماذا هذا مهم

يخلص البحث إلى أن CLEM هو عدسة جديدة قوية لمديري البرمجيات. إنه ينقل النقاش من "كم كتبنا من الكود؟" إلى "كيف نغير نظامنا؟"

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

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

باختًا، يمنحنا CLEM لغة للتحدث عن شكل التغيير. إنه يساعدنا على رؤية ما إذا كانت برمجياتنا تبني ناطحة سحاب أم أنها مجرد تكويم للطوب فوق كومة مهتزة، وهذا التمييز قد يكون أهم شيء يمكننا قياسه من أجل البقاء طويل الأمد لأي نظام رقمي.