استكشاف تصورات المطورين لإمكانات أنظمة التوصية بالتكامل المستمر

قُبل بحثنا "استكشاف تصورات المطورين لإمكانات أنظمة التوصية بالتكامل المستمر" في مسار التقارير المسجّلة بمؤتمر ESEM 2026 في ميونخ. شاركني تأليف هذا العمل الأستاذ طاهر أ. غالب من جامعة ترنت.

يمتد هذا البحث من ورقة الرؤية التي قدّمناها في FSE Companion 2026. هناك جادلنا بأن تبنّي التكامل المستمر ينبغي أن يكون قراراً مدروساً لا خياراً افتراضياً؛ وهنا ننتقل من الرؤية إلى طلب الدليل.

لماذا تقرير مسجّل؟

في التقرير المسجّل، تُحكّم أسئلة البحث والمنهجية قبل جمع البيانات. وبذلك لا يقوم القبول على جاذبية النتائج بعد ظهورها، بل على أهمية السؤال وسلامة التصميم وقدرته على الإجابة.

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

الفجوة التي نريد سدّها

صار التكامل المستمر بنية تحتية مألوفة في البرمجيات الحديثة، وارتفع تبنّيه في المشاريع مفتوحة المصدر مع اتساع استخدام GitHub Actions. لكن سهولة التبنّي لم تُنه السؤال الأهم: سؤال الملاءمة.

18.8% من مشاريع Java تهجر التكامل المستمر كلياً بعد تبنّيه.
52% من المطورين يطلبون تهيئة أسهل.
الاختيار بين الخدمات لا يزال موازنة دقيقة بين الميزات، والتسعير، وسير العمل، وحدود البنية القائمة.

لقد وصفت الأبحاث السابقة هذه العوائق، عبر مراجعات منهجية، وتصنيفات لنقاط الألم، وتحليلات للعوامل التقنية والاجتماعية. ومع ذلك تبقى ثلاث فجوات جوهرية:

هل تقود قرارات التبنّي حاجة المشروع، أم أثر الجماعة والممارسات السائدة؟
هل يرى المطورون CI ضرورة عامة لكل مشروع، أم أداة تنفع في سياقات دون أخرى، وما الذي يمنع غير المتبنّين؟
هل يثق المطورون أصلاً بنظام آلي يقترح ملاءمة CI والخدمة والتهيئة؟

وهناك سبب بنيوي لاستمرار هذه الفجوات: كثير من الاستطلاعات السابقة سألت مستخدمي CI وحدهم، أو المتبنّين ذوي الخبرة فقط. فإذا سألنا من تبنّوا CI وحدهم عن سبب التبنّي، فلن نسمع صوت من نظروا إليه ثم أعرضوا عنه.

ثلاثة أسئلة بحثية

السؤال الأول: ما الذي يقود تبنّي CI واختيار الخدمة؟

نميّز بين الدوافع النابعة من حاجة المشروع والدوافع المتأثرة اجتماعياً، ونسأل عن المعايير التي يقدّمها المطورون عند اختيار خدمة بعينها، وكيف ينتقلون بين الخدمات أو يشغّلون أكثر من خدمة في الوقت نفسه.

السؤال الثاني: هل CI ضرورة عامة أم أداة مشروطة بالسياق؟

نسأل ما إذا كان المطورون يعدّونه أساسياً لكل مشروع، أم نافعاً في أنواع محددة من المشاريع، وما المنطق الذي يوجه التبنّي الانتقائي، وما العوائق التي يذكرها غير المتبنّين.

هذا السؤال يحدد ما ينبغي لنظام التوصية أن يفعله قبل كل شيء: هل يقترح CI لكل مشروع، أم يبدأ بتقدير ملاءمة المشروع له؟

السؤال الثالث: هل سيجد المطورون نظام توصية بالتكامل المستمر نافعاً؟

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

يستند هذا السؤال إلى نموذج قبول التقنية (TAM)، مع استعمال الفائدة المدركة والنية السلوكية، وإضافة الثقة صراحة. فالتوصية التي لا يثق بها المطور لن تتحول إلى عمل.

تصميم الدراسة

سنأخذ عينة من نحو 5,000 مطوّر نشط في المصادر المفتوحة عبر واجهة GitHub REST API، من مستودعات لديها 10 نجوم على الأقل و10 مساهمات خلال الاثني عشر شهراً الماضية. ومن كل مستودع نحدد مطورين ساهموا خلال العام الأخير، ثم نختار أحدهم عشوائياً، مع استبعاد الحسابات الآلية والحسابات غير القابلة للتواصل، وإزالة عناوين البريد المكررة حتى لا يتلقى الشخص نفسه أكثر من دعوة.

هذا الرقم، أي 5,000، هو عدد الدعوات لا عدد الإجابات المتوقعة؛ إذ نتوقع 250 إلى 500 استجابة مكتملة.

صُمم الاستطلاع بحيث لا يكون غير المتبنّين هامشاً، بل طرفاً أساسياً في السؤال:

الجزء أ — مستخدمو CI، 18 سؤالاً: دوافع التبنّي، واختيار الخدمة، وسلوك الانتقال بين الخدمات، والرأي في عمومية CI، والقيمة المدركة لأنظمة التوصية.
الجزء ب — غير المستخدمين، 14 سؤالاً: الرأي في عمومية CI، وعوائق التبنّي، والقيمة المدركة لأنظمة التوصية.

يلتقي الجزآن عند السؤال الثالث، وهو ما يتيح مقارنة حكم المتبنّين وغير المتبنّين على الأداة المقترحة نفسها.

أما التحليل، فسنعتمد إحصاءات وصفية، ونقارن توزيعات الدوافع النابعة من الحاجة بالدوافع المتأثرة اجتماعياً عبر اختبارات مربع كاي، ونستخدم اختبارات مان-ويتني U مع حجم الأثر r لمخرجات ليكرت الترتيبية.

لماذا يهم هذا الآن؟

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

قبل أن نبني أدوات تُوصي، علينا أن نفهم كيف يقرر المطورون الآن، وهل سيقبلون التوصية ويثقون بها إذا جاءت من نظام آلي. هذا هو جوهر الدراسة.

شكر وامتنان

الشكر موصول للأستاذ طاهر أ. غالب، فقد منح هذا العمل إطاره المنهجي وانضباطه، وأصر على أن تأتي الأسئلة أولاً، ثم تأتي البيانات لتجيب لا لتُزيّن.