الكود القذر في البرمجة: ما هو، مؤشراته وكيفية كتابة كود أنظف

ما هو الكود القذر في البرمجة

الكود القذر هو توصيف شخصي ولكن مقبول بشكل عام للكود الذي لا يلبي الحد الأدنى من معايير الجودة. روبرت مارتن في كتابه الكود النظيف (2008) يعرف الكود الرديء بأنه الكود الذي «يعيق فهم ما يفعله». يمكن أن يكون الكود القذر صحيحاً نحوياً بل ويعمل، لكن صيانته تصبح كابوساً للفريق.

المصطلح govnokod واسع الانتشار تحديداً في المجتمع الناطق بالروسية. في الإنجليزية، تُستخدم مصطلحات أكثر رسمية: spaghetti code، dirty code، technical debt code. لكن الشحنة العاطفية لـ «الكود القذر» تنقل بدقة أكبر موقف المطورين تجاه مثل هذا الكود — مزيج من الانزعاج والاشمئزاز والإهانة المهنية.

وفقاً لدراسة McKinsey (2023)، الشركات ذات المستوى العالي من الديون التقنية — والكود القذر هو مكونها الرئيسي — تنفق 20–40% موارد أكثر على تطوير الميزات الجديدة. جودة الكود تؤثر مباشرة على مؤشرات الأعمال، وهذه ليست استعارة بل حقيقة مؤكدة.

الحد الفاصل بين الكود القذر والكود العادي

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

المؤشرات الرئيسية للكود القذر

النسخ واللصق (copy-paste programming) هو أحد أكثر المؤشرات وضوحاً وسهولة في الكشف. عندما يتكرر نفس كتلة الكود في عدة أماكن مع تغييرات طفيفة، هذا ليس مجرد كود قذر — بل مصدر أخطاء مستقبلية. التصحيح في مكان واحد وتجاهله في مكان آخر هو وضع نموذجي.

أسماء المتغيرات غير ذات المعنى هي من الكلاسيكيات. متغيرات بأسماء `a`، `b`، `x`، `data`، `temp`، `tmp`، `result`، `list`، `obj` لا تحمل أي معلومات عن غرضها. يضطر قارئ الكود إلى تحليل الدالة بأكملها ليفهم ما تحتويه المتغير. روبرت مارتن يسمي هذا «كذباً في الاسم» — الاسم يعد بمعلومات لكنه لا يقدمها.

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

مؤشرات خفية

الكود الميت (dead code) — دوال ومتغيرات وفئات لا تُستخدم في أي مكان. هذا يزيد من حجم الكود، ويشتت انتباه المطور، ويخلق انطباعاً خاطئاً عن قدرات النظام. الأرقام السحرية — أرقام دون سياق. الفئات العملاقة (God classes) — فئات تفعل كل شيء دفعة واحدة، منتهكة مبدأ المسؤولية الواحدة (SOLID: S).

لماذا يظهر الكود القذر

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

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

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

عوامل ثقافية

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

عواقب الكود القذر على المشروع

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

دوران الموظفين هو نتيجة غير مباشرة لكنها خطيرة. المطورون، خاصة ذوو الخبرة، لا يريدون العمل مع كود قذر. وفقاً لاستطلاع Stack Overflow للمطورين 2024، 47% من المطورين يعتبرون جودة قاعدة الكود أحد العوامل الرئيسية عند اختيار مكان العمل. المشاريع ذات الكود الرديء تخسر أفضل موظفيها.

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

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

SonarQube والأدوات المشابهة يمكنها تقدير الديون التقنية بساعات أو أيام عمل. على سبيل المثال، 500 تحذير عن النسخ واللصق، 200 عن الأرقام السحرية و50 عن التداخل العميق تعطي تقديراً بـ 30 يوماً من الديون التقنية. هذه الأرقام يمكن ويجب عرضها على الإدارة لتبرير إعادة الهيكلة.

كيفية كتابة كود نظيف بدلاً من الكود القذر

مبدأ DRY (لا تكرر نفسك) هو أول ما يجب تطبيقه. كل جزء من المنطق يجب أن يوجد في مكان واحد. بدلاً من النسخ واللصق — استخرج الكود المتكرر في دالة أو فئة أو وحدة منفصلة. بدلاً من الأرقام السحرية — ثوابت مسماة. بدلاً من الدوال الطويلة — عدة دوال صغيرة.

مبدأ KISS (اجعله بسيطاً) يحمي من التعقيد المفرط. إذا كان يمكن حل مهمة في 10 أسطر — لا تكتب 50. إذا كانت الحلقة أبسط من stream — استخدم حلقة. إذا كانت الدالة العادية أوضح من decorator — اكتب دالة. البساطة هي الصفة الرئيسية للكود القابل للصيانة.

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

// كود قذر — نسخ ولصق، أرقام سحرية، أسماء سيئة
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// كود نظيف — أسماء واضحة، DRY، ثوابت
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

أمثلة على إعادة الهيكلة

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

# كود قذر — دالة واحدة تفعل كل شيء
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# كود نظيف — دوال وثوابت مستخرجة
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

قاعدة الأسطر الثلاثة للدوال

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

أدوات مراجعة الكود

المحللات الثابتة للكود هي خط الدفاع الأول ضد الكود القذر. ESLint (JavaScript)، Pylint (Python)، SonarQube (متعدد اللغات)، Checkstyle (Java) تكتشف تلقائياً النسخ واللصق والأرقام السحرية وكتل catch الفارغة والدوال الطويلة جداً ومئات الأنماط المعادية الأخرى.

نمط الكود والمنسقات (code style and formatters) هي المستوى الثاني من الحماية. Prettier، Black، gofmt تقوم بتنسيق الكود تلقائياً، مما يزيل مشاكل المسافات والمسافات البادئة والأقواس. النمط الموحد في الفريق يجعل الكود قابلاً للقراءة بغض النظر عمن كتبه. يجب أن تكون الخلافات حول التنسيق مؤتمتة.

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

• ESLint — لجافا سكريبت وتايب سكريبت مع قواعد للتعقيد وmax-lines وmax-nested-callbacks
• Pylint — للبايثون مع مقاييس الكود وتقييم الجودة (من -10 إلى 10)
• SonarQube — لتتبع الديون التقنية بمرور الوقت
• CodeClimate — لتقييم مؤشر قابلية الصيانة لكل ملف
• Better Code Hub — للتحقق من الامتثال لـ 10 مبادئ للكود النظيف