6 أنماط برمجية تعلمتها من مهندسين كبار

في بداية مسيرتي كمطور، كنت أعتقد أن المهندسين الكبار أفضل لأنهم يعرفون Frameworks أكثر، Design Patterns أكثر، وحلولًا أكثر تعقيدًا. لكن مع الوقت اكتشفت أن الفرق الحقيقي ليس في كتابة كود يبدو ذكيًا، بل في كتابة كود واضح، آمن، وسهل التغيير.

الكود الجيد لا يظهر قيمته فقط عندما يعمل اليوم. قيمته تظهر عندما يتغير المتطلب، عندما يظهر Bug في الإنتاج، أو عندما يأتي مطور جديد ويحاول فهم ما يحدث.

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

1. اجعل المسار الطبيعي واضحًا

الكود الضعيف يخلط كل شيء معًا: Validation، شروط، Logic، Database، Response، و Error Handling داخل نفس الدالة.

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

الفكرة بسيطة: عالج الحالات الخاطئة مبكرًا، ثم اترك المسار الرئيسي واضحًا من الأعلى إلى الأسفل.

بدل أن تكتب شروطًا متداخلة كثيرة، استخدم Guard Clauses:

if (!user) {
  throw new Error("User is required");
}

if (!items.length) {
  throw new Error("Order must contain items");
}

const order = createOrder(user, items);
return order;

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

2. سمِّ الأشياء حسب معنى العمل وليس حسب التفاصيل التقنية

الأسماء العامة مثل:

processData()
handleItems()
updateRecord()

لا تقول الكثير. هي تصف أن شيئًا ما يحدث، لكنها لا توضح لماذا يحدث.

المهندسون الكبار يفضلون أسماء توضّح معنى العمل:

calculateInvoiceTotal()
markInvoiceAsPaid()
syncCustomerSubscriptions()

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

القاعدة هنا:

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

3. ضع القواعد المهمة في المكان الذي لا يمكن تجاوزه

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

في حالة وجود Requests متزامنة، قد يمر طلبان من نفس الفحص في نفس اللحظة، ويتم إنشاء سجلين مكررين.

الحل الأقوى هو وضع القاعدة في قاعدة البيانات:

$table->unique(['user_id', 'plan_id']);

ثم يتعامل التطبيق مع الخطأ ويعيد Response واضحًا.

المبدأ هنا:

القواعد الحرجة يجب أن توضع عند أقوى Boundary متاح.

أمثلة:

• Unique rules في قاعدة البيانات.

• Permissions عند حدود الدخول إلى العملية.

• Required fields في Validation.

• State transitions داخل Service واضح أو Domain Layer.

• Money calculations بطريقة دقيقة بدون Floating Point أخطاء.

4. لا تبنِ معمارية “احتياطية” قبل الحاجة

من أكثر الأخطاء شيوعًا أن تبني نظامًا كبيرًا لمتطلبات غير موجودة بعد.

تبدأ بميزة بسيطة، ثم تقول:

ماذا لو احتجنا أكثر من Provider لاحقًا؟
ماذا لو أصبح هذا Microservice؟
ماذا لو احتجنا Strategy مختلفة؟

وفجأة تصبح ميزة صغيرة مليئة بـ Interfaces و Factories و Events و Config Files.

المهندس الكبير لا يتجاهل المستقبل، لكنه لا يبني له قبل وجود سبب حقيقي.

القاعدة:

لا تضف Abstraction جديدًا قبل أن يستحقه الكود.

الكود المرن ليس هو الكود الذي يحتوي على طبقات كثيرة، بل هو الكود الواضح الذي يمكن تغييره بسهولة عند الحاجة.

5. اجعل التأثيرات الجانبية واضحة

بعض الدوال تبدو بسيطة لكنها تفعل أشياء كثيرة في الخلفية.

مثال:

updateUserProfile(user);

قد تبدو هذه الدالة بسيطة، لكنها ربما:

• تحدث قاعدة البيانات.

• تمسح Cache.

• ترسل Email.

• تسجل Audit Log.

• تطلق Event.

• ترسل Webhook.

إذا كانت الدالة تفعل كل هذا بدون وضوح، يصبح تتبع الأخطاء صعبًا.

الأفضل أن تكون التأثيرات المهمة واضحة:

updateUserProfile(user);
clearUserCache(user.id);
recordAuditLog(user);
dispatchProfileUpdatedEvent(user);

قد يكون الكود أطول قليلًا، لكنه أوضح بكثير.

القاعدة:

لا تخفِ العمليات المهمة خلف أسماء بريئة.

6. اترك الكود أسهل للتغيير

المطور المبتدئ يسأل: هل يعمل الكود؟

المهندس الكبير يسأل: هل سيكون هذا الكود مفهومًا عندما نحتاج تغييره لاحقًا؟

هذا الفرق مهم جدًا.

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

وهذا يعني:

• تجنب One-liners الذكية إذا كانت تقلل الوضوح.

• فصل المسؤوليات.

• عدم خلط Business Logic مع تفاصيل العرض.

• كتابة تعليقات تشرح السبب، وليس الواضح.

• ترك بنية مفهومة للمطور القادم.

تعليق سيئ:

// increase count by 1
count++;

تعليق مفيد:

// Payment provider may send confirmation a few seconds late,
// so we keep a short grace period before marking payment as failed.

الخلاصة

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

كانت بسيطة:

• اجعل المسار الطبيعي واضحًا.

• سمِّ الأشياء حسب معناها.

• ضع القواعد المهمة في أقوى مكان.

• لا تبنِ معمارية قبل الحاجة.

• اجعل التأثيرات الجانبية واضحة.

• اترك الكود أسهل للتغيير.

الكود الجيد ليس الكود الذي يبدو ذكيًا، بل الكود الذي يمكن فهمه، اختباره، وتعديله بثقة.