كودنا كان طلاسم غامضة: كيف أنقذتنا ‘الثوابت المسماة’ من جحيم الأرقام السحرية؟

يا أهلاً وسهلاً فيكم، معكم أبو عمر.

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

نزل الخبر علينا زي الصاعقة. فتحنا اللابتوبات على السريع، والقهوة صارت صديقتنا الوحيدة بهاذيك الليلة. بعد ساعات من التنبيش والتحفير في الكود، واحد من الشباب صرخ: “لقيتها!”. المشكلة كانت في سطر بسيط، بريء المظهر، لكنه كان زي اللغم:

if (user.getRole() == 2) {
    // Grant special access...
}

سألناه: “وشو يعني role رقم 2؟”. ساد الصمت في الغرفة. لا أنا ولا هو ولا أي حدا في الفريق كان عنده جواب فوري. المبرمج اللي كتب هالكود كان ترك الشركة من شهور. بلشنا رحلة عذاب ثانية: فتحنا قاعدة البيانات، وراجعنا ملفات التصميم القديمة، ونبشنا في الإيميلات… وبعد ساعة زمن اكتشفنا إنه الرقم 2 يعني “مُحرِّر” (Editor)، وكان في صلاحية جديدة أُضيفت للنظام سببت تعارض مع صلاحيات المحرر القديمة وعملت كل هالمصيبة.

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

ما هي الأرقام السحرية (Magic Numbers)؟ وليش هي ‘سحرية’ بالمعنى السيء؟

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

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

• صعوبة القراءة والفهم: لما ترجع لكودك بعد 6 شهور، أو لما يجي مبرمج جديد يشتغل على المشروع، راح يقضي ساعات بس عشان يفهم شو يعني if (status == 5). هل 5 يعني “مكتمل”؟ “ملغي”؟ “قيد الانتظار”؟ الله أعلم.
• صعوبة الصيانة والتعديل: تخيل عندك نظام فيه ضريبة القيمة المضافة (VAT) قيمتها 15%. فكتبت في 10 أماكن مختلفة بالكود price * 0.15. الآن، قررت الحكومة تغير الضريبة لـ 16%. بدك تلف على كل ملفات المشروع وتغير 0.15 لـ 0.16، وتدعي ربنا إنك ما نسيت مكان، أو إنك ما غيرت رقم 0.15 تاني كان مستخدم لشي مختلف تماماً!
• مصدر للأخطاء: ممكن بالغلط تكتب if (user.role == 3) بدل 2، والبرنامج ما راح يعطيك أي خطأ، لكن المنطق البرمجي كله راح ينضرب.

الحل السحري الحقيقي: الثوابت المسماة (Named Constants)

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

خلينا نرجع لمثالنا الأول ونشوف كيف كان ممكن نتجنب كل وجع الراس هداك.

قبل: الكود الغامض

// شو يعني 2؟ وشو يعني 3؟ لازم أرجع للمستندات... إذا لقيتها أصلاً!
if (user.getRole() == 2) {
    // ...
} else if (user.getRole() == 3) {
    // ...
}

بعد: الكود الواضح باستخدام الثوابت

// تعريف الثوابت في مكان مركزي وواضح
public static final int EDITOR_ROLE = 2;
public static final int ADMIN_ROLE = 3;

// الآن الكود يتحدث عن نفسه!
if (user.getRole() == EDITOR_ROLE) {
    // منطق خاص بالمحرر
} else if (user.getRole() == ADMIN_ROLE) {
    // منطق خاص بالمدير
}

شايفين الفرق؟ الكود صار مقروء زي اللغة الإنجليزية. أي حدا، حتى لو مش هو اللي كتب الكود، بيقدر يفهم شو القصد من الشرط فوراً.

كيف نعرّف الثوابت بلغات البرمجة المختلفة؟

الفكرة موجودة في كل لغات البرمجة تقريباً، بس طريقة الكتابة بتختلف شوي.

في JavaScript / TypeScript

const PENDING_STATUS = 1;
const COMPLETED_STATUS = 2;

if (order.status === COMPLETED_STATUS) {
  console.log('Order is completed!');
}

في Python

# عادة يتم تعريفها في بداية الملف أو في ملف خاص بالثوابت
PENDING_STATUS = 1
COMPLETED_STATUS = 2

if order.status == COMPLETED_STATUS:
    print("Order is completed!")

في PHP

define('PENDING_STATUS', 1);
const COMPLETED_STATUS = 2; // الطريقة الأحدث والأفضل داخل الكلاسات

if ($order->status == COMPLETED_STATUS) {
    echo "Order is completed!";
}

تطور الفكرة: من الثوابت البسيطة إلى الـ Enums

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

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

مثال عملي: إدارة حالات الطلب في متجر إلكتروني

تخيل عندك الحالات التالية للطلب: 1=Pending, 2=Processing, 3=Shipped, 4=Delivered, 5=Cancelled.

الطريقة السيئة (أرقام سحرية)

function handleOrderStatus(order) {
    if (order.status === 3) { // 3.. ايش يعني؟ آه يمكن Shipped
        // ... send shipping notification
    } else if (order.status === 5) { // 5.. Cancelled?
        // ... process refund
    }
}

الطريقة الأفضل باستخدام Enum (مثال بـ TypeScript)

// تعريف الـ Enum مرة واحدة في مكان مركزي
enum OrderStatus {
  Pending = 1,
  Processing = 2,
  Shipped = 3,
  Delivered = 4,
  Cancelled = 5,
}

// الآن استخدمه في أي مكان في الكود
function handleOrderStatus(order) {
    if (order.status === OrderStatus.Shipped) {
        // الكود واضح ومفهوم 100%
        // ... send shipping notification
    } else if (order.status === OrderStatus.Cancelled) {
        // مستحيل تغلط بالرقم
        // ... process refund
    }
}

// والميزة الإضافية: بيئة التطوير (IDE) بتساعدك وبتكمل لك الكود
let myOrder = { status: OrderStatus.Shipped }; 

استخدام الـ Enums بيعطيك أمان إضافي (Type Safety) وبيخلي الأخطاء شبه مستحيلة، لأنه بيجبرك تستخدم قيمة من القيم المعرفة مسبقاً، مش أي رقم عشوائي.

نصائح أبو عمر العملية للتخلص من الأرقام السحرية

من خبرتي في الميدان، هاي شوية نصائح عملية من الآخر عشان تودعوا الأرقام السحرية للأبد:

نصيحة 1: لا تؤجل عمل اليوم إلى الغد

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

نصيحة 2: لم الشمل (مكان واحد للثوابت)

اتفق مع فريقك على مكان مركزي لوضع الثوابت العامة في المشروع. ممكن يكون ملف اسمه constants.js أو config.py أو كلاس اسمه AppConstants. هذا بيسهل على أي حدا يلاقي الثوابت ويفهمها ويستخدمها، وبيمنع تعريف نفس الثابت في 10 أماكن مختلفة.

نصيحة 3: استخدم قوة مراجعة الكود (Code Review)

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

نصيحة 4: السحر يمتد للنصوص أيضاً! (Magic Strings)

نفس المبدأ ينطبق تماماً على النصوص. استخدام نص مثل "admin" مباشرة في الكود هو نفس مشكلة الرقم السحري. ممكن تكتبها مرة "admin" ومرة "Admin" بالغلط وتسبب مشكلة. الحل؟ نفس الشي، عرفها كثوابت:

const ROLES = {
  ADMIN: 'admin',
  EDITOR: 'editor',
  VIEWER: 'viewer',
};

if (user.role === ROLES.ADMIN) {
  // ...
}

الخلاصة: من طلاسم إلى قصيدة برمجية واضحة

يا جماعة، البرمجة مش بس كتابة كود بيشتغل. البرمجة هي كتابة كود واضح، مقروء، وسهل الصيانة. الأرقام السحرية هي دين برمجي (Technical Debt) بتتركه في الكود، ومع الوقت الفائدة بتزيد وبتدفع الثمن غالي من وقتك وأعصابك.

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

نصيحتي الأخيرة إلكم: حبوا الكود اللي بتكتبوه، واكتبوا كود تحبوا ترجعوا تقرأوه بعد سنة. اكتبوا كود “ابن عالم وناس”، كود واضح ومحترم. ✅

والله يوفقكم جميعاً في رحلتكم البرمجية.