الانحدار — ما هو، لماذا يحدث وكيفية اختباره

ما هو الانحدار في التطوير

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

المصطلح يأتي من الاختبار: اختبار الانحدار هو إعادة تنفيذ الاختبارات الموجودة بعد كل تغيير. إذا فشل اختبار كان ناجحاً سابقاً، فقد حدث انحدار. بمعنى أوسع، الانحدار ليس فقط فشل اختبار، بل أي تدهور في السلوك يلاحظه المستخدم أو فريق ضمان الجودة. وفقاً لـ Tricentis State of Testing 2023، تمثل الانحدارات 35–45% من جميع الأخطاء الموجودة في الإنتاج.

ما يميز الانحدار عن الخطأ العادي هو السياق الزمني: الخطأ العادي ربما كان موجوداً دائماً، بينما الانحدار دائماً نتيجة تغيير. هذا تمييز مهم لأن العثور على سبب الانحدار يبدأ بتحليل ما تغير بين «كان يعمل» و«توقف عن العمل». Git bisect هي الأداة القياسية للعثور على التعديل الذي تسبب في الانحدار.

أنواع الانحدار والأمثلة

الانحدار المحلي — تغيير في الوحدة A يكسر وظيفة في نفس الوحدة A. مثال: يعيد المطور كتابة دالة فرز فتتوقف عن معالجة مصفوفة فارغة بشكل صحيح. الانحدار المحلي هو الأسهل في الاكتشاف والإصلاح لأن السبب والنتيجة قريبان.

الانحدار البعيد — تغيير في الوحدة A يكسر وظيفة في الوحدة B، غير متصلة مباشرة بالكود ولكنها متصلة بالبيانات أو التوقيت. مثال: تغيير مخطط قاعدة البيانات في وحدة «المستخدمون» يكسر تقريراً في وحدة «التحليلات» التي تستخدم نفس الجدول. الانحدارات البعيدة هي الأكثر غدراً: المطور لا يشك في أن تغييره سيؤثر على وحدة أخرى.

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

انحدار الأداء — يستمر الكود في العمل بشكل صحيح وظيفياً ولكنه أبطأ من ذي قبل. مثال: خوارزمية تشفير جديدة تنتج نفس النتائج، لكن وقت التنفيذ زاد من 2 مللي ثانية إلى 200 مللي ثانية. لا يتم اكتشاف انحدارات الأداء بواسطة اختبارات الوحدة العادية — بل هناك حاجة إلى المقاييس المعيارية والتنميط.

لماذا يحدث الانحدار

السبب الأول هو اقتران الكود. كلما زاد اعتماد الوحدات على بعضها البعض، زاد احتمال أن يتسبب تغيير في واحدة في انحدار في أخرى. الأنماط المضادة الكلاسيكية: الكائن العملاق (كائن يفعل كل شيء)، جراحة البندقية (تغيير في مكان واحد يتطلب تعديلات في عشرات الأماكن)، التبعية الدائرية. تقليل الاقتران هو مسألة معمارية: مبادئ SOLID، حقن التبعية، المعمارية السداسية.

السبب الثاني هو نقص الاختبارات للوظيفة المعدلة. إذا لم يكن الكود مغطى بالاختبارات، فإن المطور لا يعلم بوجود انحدار إلا من فريق ضمان الجودة أو المستخدمين. وفقاً لمدونة Google للاختبارات، المشاريع التي تغطي اختباراتها >75% من الكود لديها انحدارات أقل بـ5 مرات من المشاريع التي تغطي <25%. يضمن التطوير الموجه بالاختبارات (TDD) كتابة الاختبارات قبل الكود، وليس «عندما يتوفر الوقت».

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

اختبار الانحدار ودوره

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

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

ينقسم اختبار الانحدار الآلي إلى مستويات وفقاً لهرم الاختبارات:

• اختبارات الوحدة — سريعة، معزولة، تغطي دوال وطرق فردية
• اختبارات التكامل — تتحقق من التفاعل بين الوحدات، قواعد البيانات، الخدمات الخارجية
• اختبارات E2E — تتحقق من سيناريوهات المستخدم الكاملة عبر واجهة المستخدم أو API
• اختبارات اللقطات — تقارن المخرجات الحالية لمكون مع مرجع

وفقاً لمدونة Google للاختبارات، النسبة المثلى هي 70% اختبارات وحدة، 20% اختبارات تكامل، 10% E2E. الانحراف عن هذه النسبة يقلل من فعالية اختبار الانحدار: كثرة اختبارات E2E تبطئ خط الأنابيب، قلة اختبارات الوحدة تترك الأخطاء الدقيقة دون اكتشاف.

استراتيجيات أتمتة اختبار الانحدار

الاستراتيجية الأولى هي الانحدار الكامل. يتم تشغيل جميع اختبارات المشروع. النهج الأكثر موثوقية ولكنه الأبطأ. مناسب للمشاريع الصغيرة (حتى 10,000 اختبار، وقت التشغيل <30 دقيقة). للمشاريع الكبيرة، قد يستغرق الانحدار الكامل ساعات، مما يجعل خط أنابيب CI/CD غير عملي.

الاستراتيجية الثانية هي الانحدار الانتقائي. يتم تشغيل الاختبارات المتعلقة فقط بالكود المعدل. يُستخدم رسم بياني لتبعيات الكود لتحديد العلاقات. الأدوات: Bazel (Google)، Nx (JavaScript)، sbt (Scala). يوفر الانحدار الانتقائي 60–80% من وقت التشغيل ولكنه يتطلب بناءً دقيقاً لرسم التبعيات — الأخطاء تؤدي إلى انحدارات غير مكتشفة.

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

كيفية منع الانحدار في المشروع

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

الخطوة الثانية هي خط أنابيب CI/CD مع تنفيذ إلزامي للاختبارات. لا يمكن دمج طلب السحب حتى تجتاز جميع الاختبارات. لا يمكن «تخطي» الاختبارات بسبب الاستعجال — التغييرات العاجلة تمر عبر مجموعة اختبارات متسارعة ولكنها إلزامية. وفقاً لـ Google DevOps Research، الفرق التي لديها CI/CD إلزامي لديها انحدارات أقل بـ3 مرات في الإنتاج.

الخطوة الثالثة هي المراقبة في الإنتاج. حتى أفضل الاختبارات لا تضمن حماية 100% ضد الانحدار. أدوات المراقبة (Sentry، Datadog، New Relic) يجب أن تتابع المقاييس الرئيسية بعد كل نشر: معدل الخطأ، زمن الاستجابة، الإنتاجية. الاسترجاع التلقائي عند تجاوز الحدود هو شبكة أمان إذا وصل الانحدار إلى الإنتاج.

الخطوة الرابعة هي مراجعة الكود بعقلية الانحدار. يجب على المراجع أن يسأل: «ما الوحدات الأخرى التي قد تتعطل بسبب هذا التغيير؟». لا يكفي التحقق من صحة الكود — بل يجب التحقق من أنه لن يخل بالوظائف ذات الصلة. يجب أن تتضمن قائمة التحقق لمراجعة الكود بند «التحقق من الانحدار في الوحدات ذات الصلة».