تدفق الحمم البركانية.

في مصطلحات برمجة الكمبيوتر، يُعتبر تدفق الحمم البركانية (lava flow) هو نمط مضاد (anti-pattern) يحدث عندما يتم نشر كود برمجي مصدري كُتب تحت ظروف غير مثالية في بيئة الإنتاج، ثم يتم التوسع في البناء عليه وهو لا يزال في حالة تطويرية. هذا المصطلح مشتق من ظاهرة تدفق الحمم البركانية الطبيعية التي بمجرد أن تبرد، تتحول إلى صخور صلبة يصعب إزالتها. وبالمثل، يصبح مثل هذا الكود صعب إعادة الهيكلة (refactor) أو الاستبدال بسبب التبعيات التي تنشأ مع مرور الوقت، مما يستدعي الحفاظ على التوافق الرجعي مع التصميم الأصلي غير المكتمل.

الأسباب

يمكن أن يحدث تدفق الحمم البركانية لعدة أسباب ضمن عملية تطوير البرمجيات:

• الضغط للالتزام بالمواعيد النهائية مما يؤدي إلى تحول الحلول المؤقتة إلى حلول دائمة
• عدم كفاية التوثيق مما يمنع فهم الغرض من الكود البرمجي
• نقص الاختبارات المؤتمتة مما يجعل إعادة الهيكلة محفوفة بالمخاطر
• التغييرات المتكررة في فريق التطوير مما يؤدي إلى فقدان المعرفة التراكمية

العواقب

إن الكود غير المصقول الذي يصبح جزءاً من البنية التحتية للبرمجيات يزيد من تعقيد النظام، وتصبح قاعدة الكود صعبة الفهم والصيانة بشكل متزايد. ويؤدي ذلك إلى:

• الحاجة إلى التوافق الرجعي (backward compatibility) الذي يمكن أن يعيق الابتكار ويمنع تبني حلول جديدة وأكثر كفاءة
• زيادة الديون التقنية (technical debt) التي تتراكم بمرور الوقت، مما يؤدي إلى ارتفاع تكاليف التغيير والصيانة
• وجود عقبات أمام إعادة الهيكلة أو تحسين النظام بسبب الخوف من تعطل المكونات المعتمدة عليه

الأثر على الفرق

غالباً ما تواجه فرق التطوير تأثير تدفق الحمم البركانية عند تبدل أعضاء الفريق وانتقالهم:

• فقدان المعرفة ببعض جوانب كود النظام عند مغادرة المطورين الأصليين
• تردد المطورين الجدد في إعادة هيكلة كود غير مألوف، مما يؤدي إلى مزيد من التعقيد حيث يفضلون الإضافة بدلاً من التنظيف

استراتيجيات الحد من المشكلة

يمكن لعدة ممارسات التخفيف من آثار النمط المضاد تدفق الحمم البركانية:

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

مثال

ينجو الفرع الموروث أدناه من كل عملية تنظيف: لا اختبار له ولا تذكرة ولا توثيق، بل مجرد تعليق تحذيري، فلا أحد يعرف الغرض منه ولا أحد يجرؤ على حذفه.

class Pricing {
    // لا أحد يتذكر من يفعّل هذا العلم؛ لا تحذفه، فقد يتعطل شيء ما
    private static final boolean LEGACY_MODE = Boolean.getBoolean("pricing.legacy");

    double price(Order order) {
        double total = order.total() * 1.1;
        if (LEGACY_MODE && order.items() > 10) {
            total = legacyAdjust(total); // ???
        }
        return total;
    }

    private double legacyAdjust(double total) {
        return Math.floor(total * 0.97);
    }
}

المخرج هو تسجيل السلوك الحالي باختبارات توصيف، ثم التأكد من أن الفرع غير مستخدم، ثم حذفه:

// 1. تثبّت اختبارات التوصيف السلوك الحالي قبل أي تعديل
@Test
void addsTenPercentMarkup() {
    assertEquals(110.0, new Pricing().price(new Order(100.0, 1)), 1e-9);
}

// 2. يُظهر البحث في الكود وإعدادات الإنتاج أن أحداً لا يضبط pricing.legacy،
//    لذا حُذف الفرع؛ وتؤكد الاختبارات أن شيئاً آخر لم يتغير
class Pricing {
    double price(Order order) {
        return order.total() * 1.1;
    }
}

الكود الذي لا يمكن الوصول إليه ليس سوى كود ميت، ونظام التحكم في الإصدارات يحتفظ به على أي حال، فلا داعي لإبقائه «احتياطاً».

مقتبس من مقالة ويكيبيديا “Lava flow (programming)” (المراجعة 1309138267)، والمتاحة بموجب رخصة CC BY-SA 4.0؛ تمت ترجمة النص وتحريره وإضافة أمثلة.