كانت قاعدة الكود مستنقعاً: كيف أنقذتنا ‘قاعدة الكشافة’ من جحيم التدهور التدريجي؟

أذكر جيدًا ذلك المساء من ليالي الشتاء الباردة، كنت أجلس في مكتبي وفنجان الميرمية الساخن بجانبي. كنا في سباق مع الزمن لإطلاق ميزة جديدة ومهمة في أحد المشاريع الكبيرة. وفجأة، ظهر “بَق” (Bug) بسيط في نظام تسجيل الدخول… أو هكذا ظننا في البداية.

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

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

ما هو “الدين التقني” (Technical Debt)؟

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

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

دوامة التدهور التدريجي

عندما يتراكم الدين التقني، يدخل الفريق في دوامة خطيرة:

• بطء التطوير: كل تغيير صغير يتطلب جهدًا كبيرًا.
• زيادة الأخطاء: الكود المعقد والمترابط يسبب أخطاء غير متوقعة.
• إحباط الفريق: لا أحد يحب العمل في بيئة فوضوية ومحبطة.
• صعوبة ضم أعضاء جدد: يحتاج المبرمج الجديد لأسابيع أو أشهر فقط لفهم “الطلاسم” المكتوبة.

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

المنقذ: ‘قاعدة الكشافة’ (The Boy Scout Rule)

وسط هذا الجحيم، وجدنا ضالتنا في كتاب “البرمجة النظيفة” (Clean Code) لروبرت مارتن (العم بوب). يقدم الكتاب قاعدة بسيطة ومذهلة في فعاليتها، تُعرف بـ “قاعدة الكشافة”:

“اترك المخيم أنظف مما وجدته.”

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

“اترك الكود دائمًا أنظف قليلًا مما وجدته.”

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

كيف نطبق القاعدة عمليًا؟

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

1. إعادة تسمية متغير أو دالة

هذا هو التحسين الأسهل والأكثر تأثيرًا. اسم جيد يغني عن ألف سطر من التوثيق.

قبل:

// what is d? what is n?
function proc(d, n) {
    let val = d * n;
    return val;
}

بعد (بنفس المهمة):

// Clear and self-documenting
function calculateTotalSalary(daysWorked, dailyRate) {
    let totalSalary = daysWorked * dailyRate;
    return totalSalary;
}

مجرد تغيير الأسماء جعل الكود مفهومًا على الفور.

2. تبسيط الشروط المعقدة

الجمل الشرطية المتداخلة (Nested if-else) هي وصفة للكوارث. يمكنك تبسيطها باستخدام تقنية “الحارس” (Guard Clauses).

قبل:

function processPayment(user, payment) {
    if (user) {
        if (user.isActive) {
            if (payment.amount > 0) {
                // ... process the payment
                return "Success";
            } else {
                return "Error: Invalid amount";
            }
        } else {
            return "Error: User is not active";
        }
    } else {
        return "Error: User not found";
    }
}

بعد (بنفس المهمة):

function processPayment(user, payment) {
    if (!user) {
        return "Error: User not found";
    }
    if (!user.isActive) {
        return "Error: User is not active";
    }
    if (payment.amount <= 0) {
        return "Error: Invalid amount";
    }

    // ... process the payment
    return "Success";
}

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

3. استخلاص دالة (Extract Method)

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

قبل:

function createUserReport(userId) {
    // 1. Fetch user from database
    console.log("Fetching user data...");
    const user = db.fetchUser(userId);

    // 2. Get user posts
    console.log("Fetching user posts...");
    const posts = db.fetchPosts(user.id);

    // 3. Format the report
    let report = `Report for ${user.name}n`;
    report += `Total Posts: ${posts.length}n`;

    // 4. Save report to a file
    console.log("Saving report...");
    fs.saveToFile(`${user.name}_report.txt`, report);
}

بعد (بنفس المهمة):

function createUserReport(userId) {
    const user = fetchUserData(userId);
    const posts = fetchUserPosts(user.id);
    const reportContent = formatUserReport(user, posts);
    saveReportToFile(user.name, reportContent);
}

// Each function now has a single responsibility
function fetchUserData(userId) { /* ... */ }
function fetchUserPosts(userId) { /* ... */ }
function formatUserReport(user, posts) { /* ... */ }
function saveReportToFile(username, content) { /* ... */ }

ليست مجرد قاعدة فردية، بل ثقافة فريق

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

• مراجعات الكود (Code Reviews): أصبحت مراجعات الكود هي المكان الذي نشجع فيه بعضنا البعض. بدلًا من البحث عن الأخطاء فقط، بدأنا نقول: “شغل نظيف! شو رأيك لو نغير اسم هذا المتغير ليصير أوضح؟” أو “هذه الدالة طويلة بعض الشيء، هل يمكن استخلاص جزء منها؟”.
• الاتفاق على معايير مشتركة: استخدمنا أدوات مثل Linters و Formatters لتوحيد شكل الكود، مما قلل النقاشات حول التنسيق وسمح لنا بالتركيز على جودة المنطق.
• الصبر والاستمرارية: لم يتغير الكود بين عشية وضحاها. استغرق الأمر أشهرًا، ولكن مع كل مهمة، كان “المستنقع” يجف قليلًا، وكانت الأرض تصبح أصلب تحت أقدامنا.

نصائح من خبرتي الشخصية (من أبو عمر)

بعد سنوات من تطبيق هذه القاعدة، اسمحوا لي أن أقدم لكم خلاصة خبرتي في نقاط عملية:

1. لا تكن طموحًا جدًا: لا تحاول إصلاح العالم في مهمة واحدة. قم بتحسين صغير واحد فقط. تغيير اسم متغير يكفي. إضافة تعليق توضيحي يكفي. الهدف هو التحسين المستمر، وليس الكمال الفوري.
2. اربط التنظيف بمهمتك: نظّف فقط الكود الذي تعمل عليه مباشرة. إذا كنت تصلح خطأ في دالة `A`، فلا تذهب لتنظيف دالة `Z` في ملف آخر، حتى لا تضيع في حفرة الأرنب (Rabbit Hole).
3. الاختبارات هي شبكة الأمان: قبل أن تبدأ أي عملية إعادة هيكلة (Refactoring)، تأكد من وجود اختبارات آلية (Automated Tests). الاختبارات هي التي تمنحك الثقة لتغيير الكود وأنت مطمئن أنك لم تكسر شيئًا.
4. احتفل بالانتصارات الصغيرة: عندما تجد أن إضافة ميزة جديدة كانت سهلة وسريعة لأن الكود أصبح أنظف، احتفل مع فريقك. هذا يعزز الثقافة ويحفز الجميع على الاستمرار.

الخلاصة: الكود هو بيتنا الرقمي

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

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

في النهاية يا جماعة، الكود الذي نكتبه هو بيتنا الرقمي الذي نقضي فيه ساعات طويلة. فلماذا لا نجعله مكانًا نظيفًا، مرتبًا، ومريحًا للعيش والعمل؟ ✨