ما هو كود السباغيتي

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

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

وفقًا لـ IEEE (2022)، حوالي 35% من جميع الأخطاء في المشاريع الكبيرة ناتجة عن هيكل الكود المتشابك، وليس عن أخطاء منطقية من المطور. يرتكب المطور خطأ ليس لأنه أساء فهم المهمة، بل لأنه لم يستطع تتبع تدفق التنفيذ في كود السباغيتي.

الفرق الرئيسي عن الأنماط المعاكسة الأخرى

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

تاريخ المصطلح وعصر goto

المصطلح «كود السباغيتي» ظهر في السبعينيات مع نقد عبارة goto. في لغات البرمجة المبكرة (BASIC، FORTRAN، COBOL)، كانت goto هي الطريقة الرئيسية للتحكم في تدفق التنفيذ. كان البرنامج عبارة عن سلسلة من الأسطر المرقمة، وكانت goto تسمح بالقفز إلى أي منها. هذا خلق «تشابكًا» من القفزات كان من المستحيل فكه.

في عام 1968، نشر إدسجر دايكسترا رسالته الشهيرة «Go To Statement Considered Harmful»، التي شكلت بداية عصر البرمجة المنظمة. أثبت دايكسترا أنه يمكن تنفيذ أي خوارزمية بدون goto، باستخدام ثلاث بنيات فقط: التسلسل، التفرع (if) والحلقة (while). أصبح هذا أساس البرمجة الحديثة.

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

الأشكال الحديثة لـ goto

جحيم الاسترجاع (Callback hell) في JavaScript، و Promises المتداخلة بعمق، و async/await بدون معالجة الأخطاء، والأحداث التي لا يفهم أحد من أو متى يطلقها — كل هذه هي أنواع حديثة من كود السباغيتي. النمط المعاكس حي ومزدهر، لكنه الآن لا يستخدم عبارة goto.

علامات كود السباغيتي في المشروع

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

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

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

التشخيص من خلال الاختبارات

إذا لم تستطع كتابة اختبار وحدة لدالة بدون إنشاء 15 كائنًا وهميًا (mock) — فهذا كود سباغيتي. إذا كان اختبار وحدة واحدة يتطلب تشغيل البنية التحتية الكاملة للتطبيق — فهذا كود سباغيتي. عدم قابلية الاختبار هو مؤشر موضوعي على بنية معمارية متشابكة.

لماذا يظهر كود المعكرونة

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

التطور التدريجي — السبب الثاني. يبدأ المشروع كسكريبت صغير، ثم ينمو بالميزات، ثم يصبح تطبيقًا، ثم يصبح كتلة واحدة متراصة. وفي هذه الأثناء، لا يتم إعادة النظر في البنية المعمارية. ما كان يعمل لـ 100 سطر من الكود يصبح كارثة لـ 100,000 سطر.

انتهاك مبادئ SOLID — السبب الثالث. خاصة مبدأ المسؤولية الواحدة (S) ومبدأ عكس التبعيات (D). عندما تكون فئة مسؤولة عن كل شيء، والتبعيات صلبة، والوحدات مرتبطة بإحكام — تحصل على كود سباغيتي.

عامل الوقت

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

عواقب كود السباغيتي

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

إنتاجية الفريق تنخفض بشكل هائل. أظهرت أبحاث Microsoft Research (2023) أن وقت إضافة ميزة جديدة في كود السباغيتي ينمو تربيعيًا بالنسبة لحجم قاعدة الكود. للبنية المعمارية النظيفة، هذا النمو خطي. يصبح الفرق حاسمًا عند 50,000+ سطر من الكود.

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

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

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

كيفية إعادة هيكلة كود السباغيتي

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

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

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

// سباغيتي — كل شيء في طريقة واحدة
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// هندسة نظيفة — طبقات منفصلة
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

استراتيجية إعادة الهيكلة: الطريقة الجراحية

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

الوقاية من ظهور المعكرونة

التخطيط المعماري — أساس الوقاية. قبل بدء التطوير، اعتمد نمطًا معماريًا: MVC، MVVM، Clean Architecture، VIPER أو غيره. اكتب سجل قرار معماري (ADR) يبرر الاختيار. طالب بالامتثال للبنية المعمارية في مراجعة الكود.

مبدأ عكس التبعيات (DIP) — أداة قوية ضد كود السباغيتي. يجب ألا تعتمد الوحدات عالية المستوى على الوحدات منخفضة المستوى. يجب أن يعتمد كلاهما على التجريدات. حقن التبعيات هو التطبيق العملي لهذا المبدأ.

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

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

أدوات مكافحة كود السباغيتي

SonarQube — يتتبع التعقيد السيكلوماتي، عمق الوراثة، حجم الدوال. JDepend (Java) — يقيس التبعيات بين الحزم. PhpMetrics — يوفر مؤشر قابلية الصيانة لمشاريع PHP. راقب المقاييس في CI/CD — امنع ظهور المعكرونة بدلاً من محاربتها بعد وقوعها.