تنقسم مبادئ التصميم عادة إلى 3 مستويات متميزة ولكن مترابطة. اليوم، سنركز بالكامل على مستوى الشيفرة (Code Level)؛ وهو المستوى الذي يوجه المطور أثناء كتابة الدوال الصغيرة، ووحدات المنطق الفردية، والأسطر اليومية.
1. مبدأ KISS (Keep It Simple, Stupid)
القاعدة: اجعل الحل بسيطا قدر الإمكان.
لا تعقد الأمور بدون حاجة فعلية، وتجنب المبالغة في الهندسة (Overengineering). الحل الأبسط هو دائما الأوضح، الأسهل في الفهم، الأسرع في الاختبار، والأقل عرضة للأخطاء (Bugs).
مثال: إذا كان المطلوب هو مجرد التحقق مما إذا كان موعد الطبيب متاحا أم لا، فلا تبدأ ببناء نظام تخزين مؤقت معقد (Cache System)، وطبقات معمارية متعددة، ونظام تحقق من الـ Cache قبل أن تطلبها الحاجة الفعلية. إذا كانت المشكلة بسيطة، فالحل يجب أن يكون بسيطا أيضا.
2. مبدأ YAGNI (You Aren’t Gonna Need It)
القاعدة: لن تحتاجها الآن، فلا تبنِها.
لا تقم ببناء ميزات مستقبلية بناء على توقعات قد لا تحدث. ابنِ فقط ما تحتاجه لخدمة المتطلبات الحالية.
مثال: لديك عيادة طبية واحدة حاليا، لكنك تقوم ببناء النظام وكأنه يخدم 500 عيادة (Multi-tenant، وقواعد بيانات متعددة، وغيرها). هذا يعيدنا إلى زيادة التعقيد بلا فائدة؛ فربما لن تحتاج إلى هذه التوسعة أبدا، وإن احتجتها مستقبلا، يمكنك تطوير النظام حينها بناء على معطيات حقيقية.
3. مبدأ DRY (Don’t Repeat Yourself)
القاعدة: لا تكرر المنطق البرمجي (Logic).
يجب أن توجد كل معلومة أو منطق عمل في مكان واحد محدد داخل الشيفرة، لضمان عدم تشتت الكود.
- المنطق الخاطئ (تكرار الرسالة):
php
$message1 = "Appointment confirmed for " . $slot;
$message2 = "Appointment confirmed for " . $appointment->getSlot();المشكلة: إذا أردت تغيير صيغة الرسالة لاحقا، يجب أن تعدلها في عدة أماكن، وقد تنسى أحدها.
- المنطق الصحيح (تطبيق DRY):
javascript
class MessageFormatter {
public function appointmentConfirmation($slot) {
return "Appointment confirmed for " . $slot;
}
}الفائدة: مكان واحد للتعديل، تقليل الأخطاء، وكود أنظف. (تنبيه: DRY لا يعني تحويل كل شيء إلى Abstraction مبالغ فيه).
4. قاعدة الكشاف (Boy Scout Rule)
القاعدة: اترك الكود أنظف مما وجدته عليه.
المبدأ مأخوذ من عالم الكشافة (تنظيف المكان قبل مغادرته). عند الدخول لتعديل كود قديم أو إضافة ميزة، لا تكتفِ بمهمتك الأساسية فقط، بل حسّن الكود قليلا.
- مثال (قبل التحسين): وجود متغيرات غامضة أو قيم (Magic Numbers).
php
if ($user->status == 1) { // ماذا يعني الرقم 1؟
$a = $user->getAppointment();
}- مثال (بعد التحسين):
php
if ($user->isActive()) { // استخدام دالة واضحة الاسم
$appointment = $user->getAppointment(); // اسم متغير معبر
}الفائدة: حذف تعليق قديم، تحسين اسم متغير، أو تقسيم دالة كبيرة.. هذه التحسينات الصغيرة اليومية تتراكم وترفع جودة المشروع مع الوقت.
5. مبدأ الفشل المبكر (Fail Fast)
القاعدة: اكتشف الأخطاء فورا، ولا تسمح للنظام بالاستمرار في حالة خاطئة.
- المنطق الخاطئ: تترك الدالة تستقبل أي مدخلات وتكمل عملها، ليظهر الخطأ لاحقا في أعماق قاعدة البيانات.
javascript
class AppointmentService {
public function book($date) {
// الكود يستمر حتى لو كان التاريخ في الماضي
$this->saveToDatabase($date);
}
}
- المنطق الصحيح: تحقق من صحة البيانات في أول سطر من الدالة.
javascript
class AppointmentService {
public function book(DateTime $date) {
if ($date < new DateTime()) {
throw new Exception("Cannot book in the past"); // الفشل فورا
}
$this->saveToDatabase($date);
}
}الفائدة: يظهر الخطأ فورا، مما يجعل التنقيب عن الأخطاء (Debugging) أسهل لأن السبب واضح ومحدد.
6. مبدأ المسؤولية الواحدة على مستوى الدالة (SRP - Single Responsibility Principle)
القاعدة: على مستوى الدالة؛ يجب أن تقوم الدالة بشيء واحد فقط.
- مثال سيء (دالة تقوم بثلاث مهام مختلفة):
javascript
function processOrder($order) {
// 1. كود طويل للتحقق من البيانات (Validation Logic)
// 2. كود طويل للحفظ في قاعدة البيانات (Database Logic)
// 3. كود طويل لإرسال بريد إلكتروني (Email Logic)
}- مثال جيد (تقسيم المهام ليكون لكل دالة مسؤولية واحدة):
javascript
function processOrder($order) {
$this->validator->validate($order);
$this->repository->save($order);
$this->mailer->sendConfirmation($order);
}7. مبدأ "أخبر، لا تسأل" (Tell, Don’t Ask)
القاعدة: أخبر الكائن بما يجب أن يفعله، بدلا من سحب بياناته واتخاذ القرار بنفسك.
يجب الحفاظ على تغليف المنطق (Encapsulation) داخل الكائن الذي يملك البيانات.
- مثال سيء (تسأل الكائن عن بياناته لتأخذ قرارا يخصه):
bash
if ($doctor->getAvailable() == true) {
$doctor->setReserved(true);
}
- مثال جيد (تأمر الكائن وهو يتولى إدارة حالته الداخلية):
bash
$doctor->reserveSlot();لماذا؟ لأن الطبيب ($doctor) يعرف نفسه أفضل، ويجب أن يتحكم في منطقه الداخلي.
8. مبدأ أقل دهشة (POLA - Principle of Least Astonishment)
القاعدة: يجب أن يتصف سلوك الكود بالوضوح والتوقع.
يجب ألا تفاجئ المبرمج الآخر (أو نفسك مستقبلا) بسلوك خفي وغير متوقع للدالة.
- مثال: استدعاء دالة باسم
$user->delete();يتوقع منها الجميع حذف المستخدم فقط. لكن إن كانت الدالة داخليا تقوم بحذف المستخدم، وإرسال إيميلات وحذف الطلبات (orders) وتعديل سجلات النظام (logs)؛ فهذا أمر مفاجئ ومربك. الكود الجيد يجعل الاسم متطابقا مع السلوك الفعلي تماما.
9. فصل الأمر عن الاستعلام (CQS - Command Query Separation)
القاعدة: الدالة إما أن تغير حالة البيانات (Command) أو ترجع قيمة (Query)، ولكن ليس الاثنين معا.
- مثال سيء (الدالة تفعل الشيئين معا):
javascript
class Account {
private $balance = 10000;
public function withdraw($amount) {
$this->balance -= $amount; // تغيير الحالة (Command)
return $this->balance; // إرجاع قيمة (Query)
}
}- مثال جيد (فصل التعديل عن الاستعلام):
javascript
class Account {
private $balance = 10000;
public function withdraw($amount) { // أمر فقط (تغيير حالة)
$this->balance -= $amount;
}
public function getBalance() { // استعلام فقط (جلب قيمة)
return $this->balance;
}
}10. إبقاء الدوال قصيرة (Keep Functions Small)
القاعدة: الدوال الصغيرة هي المفتاح الأساسي للشيفرة النظيفة.
- مثال سيء: دالة واحدة باسم processEverything() تحتوي على مئات الأسطر المتشابكة التي يصعب قراءتها أو تتبع أخطائها.
- مثال جيد: تقسيم العمل إلى دوال صغيرة متسلسلة:
javascript
function validateData($data){...}
function createUser($data){...}
function sendWelcomeEmail($data){...}الفائدة: الدوال القصيرة أسهل في الفهم، أسرع في القراءة، مرنة جدا عند الكتابة للاختبارات البرمجية (Unit Testing)، وتجعل الصيانة مستقبلا غير مقلقة.
الخلاصة
الهدف الأسمى من تطبيق هذه المبادئ العشرة على مستوى الشيفرة (Code Level) ليس الالتزام بقواعد جامدة لمجرد الالتزام، بل تحقيق أربعة أهداف جوهرية للأعمال والبرمجيات:
- تقليل التعقيد البرمجي.
- زيادة وضوح الرؤية للمطورين.
- تحسين وتسهيل عملية الصيانة والتطوير المستقبلي.
- تقليل الأخطاء (Bugs) في بيئة الإنتاج.