«إذا كان يعمل، لا تلمسه» — ما هو، جوهر المبدأ والمخاطر

ما هو مبدأ «إذا كان يعمل، لا تلمسه»؟

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

المبدأ ليس عقيدة — بل هو استرشاد يساعد في اتخاذ القرارات في ظروف عدم اليقين. كلما كانت قاعدة الكود أكثر تعقيدًا وتشابكًا، زادت احتمالية أن يكسر تغيير «بريء» شيئًا لم يتوقع أحد كسره.

وفقًا لدراسة أجرتها شركة Microsoft (2024)، حوالي 60% من جميع الحوادث الحرجة في الإنتاج مرتبطة بتغييرات حديثة في الكود تم إجراؤها بنوايا حسنة ولكن لم يتم اختبارها بشكل كافٍ في ظروف التحميل الحقيقي.

تاريخ وأصل المبدأ

التعبير «إذا كان يعمل، لا تلمسه» يعود إلى ثقافة الهندسة الأمريكية في منتصف القرن العشرين. يُنسب أول استخدام موثق إلى بيرت لانس (1977)، الذي كان يعمل في لجنة المالية بمجلس الشيوخ الأمريكي وكان يعارض التنظيم المفرط.

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

من المثير للاهتمام أنه في البرمجة، للمبدأ جانب معاكس — «يعمل، لكن الأفضل عدم لمسه» غالبًا ما يصبح مبررًا لتجنب إعادة الهيكلة، مما يؤدي على المدى الطويل إلى تراكم حرج للديون التقنية. وفقًا لشركة الاستشارات Thoughtworks (2023)، حوالي 40% من المشاريع تواجه مشكلات خطيرة بسبب التحفظ المفرط تجاه التغييرات.

متى يتم تطبيق المبدأ

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

المشاريع القديمة بدون اختبارات

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

الأنظمة الحرجة

في الأنظمة حيث التوقف غير مقبول أو تكلفة الخطأ هائلة — البرمجيات الطبية، إلكترونيات الطيران، المعاملات المالية — مبدأ «إذا كان يعمل، لا تلمسه» هو المعيار الفعلي. أي تغيير يمر عبر موافقة واختبار متعدد المراحل.

المواعيد النهائية الضيقة

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

مخاطر اتباع المبدأ

اتباع المبدأ «إذا كان يعمل، لا تلمسه» بشكل أعمى يحمل مخاطر لا تقل عن إعادة الهيكلة التي لا نهاية لها. دعنا نستعرض المخاطر الرئيسية.

تراكم الديون التقنية

إذا كان كل مطور يتبع هذا المبدأ، تتحول قاعدة الكود بسرعة إلى «كعكة طبقات» من الحلول القديمة والتعديلات المؤقتة والخوارزميات غير المثلى. عاجلاً أم آجلاً، يصبح الدين التقني غير محتمل — أي تغيير يتطلب أسابيع من التحليل.

فرص التحسين الضائعة

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

فقدان الكفاءات

عندما لا يلمس الفريق أجزاء معينة من الكود لسنوات، يفقد فهم كيفية عملها. يرحل المطور الرئيسي — ويتحول الكود إلى legacy بدون إمكانية الدعم. يجب تطبيق المبدأ مع مراعاة الصيانة طويلة الأمد للمشروع.

الوسط الذهبي: إعادة الهيكلة بدون تعصب

الاستراتيجية المثلى — ليست اتباع المبدأ بشكل أعمى، بل تطبيقه بوعي مع مراعاة السياق. إعادة الهيكلة ضرورية، لكن يجب أن تكون آمنة.

قاعدة الكشاف

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

إعادة الهيكلة تحت حماية الاختبارات

الاختبارات — هي الطريقة الوحيدة لتطبيق مبدأ «إذا كان يعمل، لا تلمسه» بأمان. إذا كان الكود مغطى بالاختبارات، تصبح أي إعادة هيكلة متوقعة: يغير المطور الكود، يشغل الاختبارات ويرى إن كان هناك شيء قد انكسر. بدون اختبارات — لا تلمس. مع اختبارات — أعد الهيكلة بثقة.

// مثال: إعادة هيكلة آمنة تحت تغطية اختبار
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // كود قديم لكنه يعمل
        return basePrice - (basePrice * discount / 100.0)
    }
}

// اختبار يحمي من الانتكاس
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

هذا المثال يوضح النهج الصحيح: أولاً الاختبار، ثم إعادة الهيكلة. إذا نجح الاختبار، التغيير آمن. مبدأ «إذا كان يعمل، لا تلمسه» يتحول إلى «إذا كان يعمل تحت الاختبارات، أعد الهيكلة بجرأة».

أمثلة واقعية من الممارسة

دعنا نستعرض سيناريوهات واقعية حيث كان مبدأ «إذا كان يعمل، لا تلمسه» منقذًا ومدمرًا في نفس الوقت.

حالة منقذة: مشكلة شبيهة بـ Y2K

اكتشف مطور أن كود معالجة التواريخ يستخدم تنسيق DD/MM/YY بدلاً من YYYY. كان الكود يعمل بشكل صحيح من 2000 إلى 2025. على الرغم من الرغبة في «إصلاحه»، ترك الكود كما هو مكتفيًا بتعليق. في 2026، قامت الشركة بتحديث النظام، وكان الحل الجديد يعالج القرون بشكل صحيح. التغيير المبكر كان سيكسر المنطق العامل.

حالة مدمرة: فقدان البيانات بسبب «تحسين»

قرر مهندس «تحسين» كود استيراد البيانات القديم لكنه يعمل عن طريق استبداله بمكتبة حديثة. لم يأخذ في الاعتبار أن المكتبة القديمة كانت تعالج حالة حدية محددة غير موثقة. بعد الإصدار — فقدان هائل للبيانات. تم انتهاك مبدأ «إذا كان يعمل، لا تلمسه»، وكانت تكلفة الخطأ أسبوعين من عمل الفريق للاستعادة.