قواعد Clean Code التي تجعل مشاريع البرمجة أسهل للصيانة

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

الفكرة الأساسية

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

مثال برمجي عملي

def calculate_invoice(items, tax_rate):
    subtotal = sum(item["price"] * item["quantity"] for item in items)
    tax = round(subtotal * tax_rate, 2)
    return {
        "subtotal": round(subtotal, 2),
        "tax": tax,
        "total": round(subtotal + tax, 2)
    }

items = [
    {"name": "كتاب", "price": 12.5, "quantity": 2},
    {"name": "دفتر", "price": 3.0, "quantity": 1}
]

print(calculate_invoice(items, 0.15))

شرح المثال

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

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

طريقة العمل قبل كتابة الكود

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

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

اختبار المثال في حالات مختلفة

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

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

ملاحظات تتعلق بجودة الكود

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

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

متى تعرف أن الحل يحتاج إلى تطوير؟

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

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

أخطاء ينبغي تجنبها

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

خطوة تالية مناسبة

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

مراجعة الكود على مراحل

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

الخلاصة

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

تعديل المقال

إيفلون

قواعد Clean Code التي تجعل مشاريع البرمجة أسهل للصيانة