الدور المطلوب

الدور المطلوب تصرف بصفتك مهندس برمجيات ومطور أنظمة إدارية محترفًا، ومتخصصًا في تصميم أنظمة سير العمل الإداري (Workflow Management Systems)، باستخدام PHP وMySQL. أريد منك تحليل وتصميم وبناء نظام إداري إلكتروني متكامل لإدارة الطلبات والموافقات متعددة المستويات، مع واجهة عربية RTL، وكود بسيط وواضح وقابل للصيانة والتطوير مستقبلًا. المطلوب مشروع حقيقي قابل للتشغيل، وليس مجرد شرح أو نموذج واجهات تجريبي. 1. التقنيات المطلوبة استخدم التقنيات التالية: * Backend: PHP بإصدار مستقر ومدعوم. * Database: MySQL. * Database Management: phpMyAdmin لإدارة قاعدة البيانات. * Frontend: HTML5 وCSS3 وJavaScript بشكل بسيط. * واجهة المستخدم: Bootstrap 5 مع دعم اللغة العربية واتجاه RTL. * PDF: مكتبة مناسبة ومدعومة لإنشاء تقارير PDF باللغة العربية، مثل mPDF. * Notifications: نظام إشعارات داخلي داخل التطبيق. * Authentication: تسجيل دخول آمن باستخدام اسم المستخدم وكلمة المرور. * Deployment: قابلية التشغيل على خادم Ubuntu باستخدام Apache أو Nginx وPHP وMySQL. التزم بإصدارات متوافقة بين المكتبات ونسخة PHP المختارة، ووثّق متطلبات التشغيل بوضوح. لا تستخدم Docker أو Microservices أو بنية معقدة، ولا تستخدم Laravel أو أي إطار عمل ثقيل إلا إذا كان هناك سبب تقني ضروري ومبرر. الأفضل استخدام PHP منظم بأسلوب بسيط وواضح، مع فصل ملفات الاتصال بقاعدة البيانات والمنطق البرمجي والواجهات قدر الإمكان. استخدم Composer فقط عند الحاجة الفعلية لإدارة المكتبات. 2. فكرة النظام النظام مخصص لتقديم الطلبات الإدارية ومراجعتها واعتمادها عبر تسلسل وظيفي محدد. يبدأ الطلب من الموظف مقدم الطلب، ثم ينتقل بالتسلسل إلى المستويات التالية: 1. الموظف مقدم الطلب. 2. المستوى الأول: المسؤول أو المشرف المباشر. 3. المستوى الثاني: مدير القسم. 4. المستوى الثالث: مدير الإدارة. 5. المستوى الرابع: رئيس القطاع. بعد اعتماد رئيس القطاع للطلب، يعتبر الطلب معتمدًا نهائيًا، ويقوم النظام بإصدار تقرير PDF رسمي يحتوي على بيانات الطلب وسجل الاعتمادات والتوقيعات المصورة. يجب أن يكون مسار الاعتماد واضحًا، مع إمكانية تتبع الطلب من لحظة تقديمه حتى إغلاقه نهائيًا. 3. دورة حياة الطلب Workflow نفّذ دورة العمل التالية بدقة: المرحلة الأولى: تقديم الطلب * يسجل الموظف الدخول إلى النظام. * ينشئ طلبًا جديدًا من خلال نموذج إلكتروني. * يعبئ الحقول المطلوبة ويرفق الملفات إن كانت المرفقات مفعلة. * يحفظ الطلب كمسودة أو يرسله للاعتماد. * بعد الإرسال، ينشئ النظام رقمًا مرجعيًا فريدًا للطلب. * يسجل النظام تاريخ ووقت التقديم. * يحول الطلب تلقائيًا إلى المستوى الأول المحدد له. يجب ألا يستطيع مقدم الطلب تعديل الطلب بعد إرساله إلا وفق سياسة واضحة، مثل إعادته إليه للتعديل أو السماح له بتعديل المسودة فقط. المرحلة الثانية: المستوى الأول — المسؤول المباشر يستطيع المسؤول المباشر اتخاذ أحد الإجراءات التالية: 1. الموافقة: ينتقل الطلب إلى مدير القسم. 2. الرفض: ينتهي مسار الطلب باعتباره مرفوضًا. 3. إرجاع للتعديل: يعاد الطلب إلى الموظف مقدم الطلب، مع توضيح سبب الإرجاع. إذا عدّل الموظف الطلب وأعاد إرساله، يستأنف مسار الاعتماد وفق السياسة المحددة، مع الاحتفاظ بسجل الإجراءات السابقة وعدم حذفها. المرحلة الثالثة: مدير القسم تكون صلاحيات مدير القسم: 1. الموافقة: ينتقل الطلب إلى مدير الإدارة. 2. الرفض: ينتهي الطلب باعتباره مرفوضًا. 3. الإرجاع إلى المستوى السابق: يعاد الطلب إلى المسؤول المباشر لمراجعته أو استكمال النواقص. يجب تسجيل سبب الإرجاع، ولا يجوز إرجاع الطلب دون كتابة ملاحظة توضيحية. المرحلة الرابعة: مدير الإدارة تكون صلاحيات مدير الإدارة: 1. الموافقة: ينتقل الطلب إلى رئيس القطاع. 2. الرفض: ينتهي الطلب باعتباره مرفوضًا. 3. الإرجاع إلى المستوى السابق: يعاد إلى مدير القسم. المرحلة الخامسة: رئيس القطاع تكون صلاحيات رئيس القطاع: 1. الموافقة النهائية: يعتمد الطلب ويغلق مسار الموافقات. 2. الرفض النهائي: ينتهي الطلب باعتباره مرفوضًا. 3. الإرجاع إلى المستوى السابق: يعاد إلى مدير الإدارة. لا يُصدر النظام التقرير النهائي المعتمد إلا بعد الموافقة النهائية من رئيس القطاع. قواعد أساسية لمسار العمل * لا يستطيع أي مستخدم تنفيذ إجراء إلا إذا كان مخولًا به وكان الطلب في المرحلة المسندة إليه. * لا يجوز تخطي أي مرحلة من مراحل الاعتماد. * لا يجوز للمستخدم الموافقة على الطلب نيابة عن مستوى آخر دون صلاحية صريحة. * يجب منع تكرار الإجراء نفسه أو تنفيذه مرتين بسبب تحديث الصفحة أو إرسال الطلب مجددًا. * كل إجراء يجب أن يسجل في سجل تاريخي غير قابل للتعديل من خلال واجهة المستخدم. * عند إرجاع الطلب، يجب تسجيل المرحلة التي أعادته والمرحلة المستهدفة وسبب الإرجاع. * يجب تعريف سلوك إعادة الإرسال بوضوح حتى لا يتم تجاوز مراحل الاعتماد أو فقدان السجل السابق. * يجب دعم إلغاء الطلب أو سحبه من مقدم الطلب وفق سياسة إدارية محددة، إذا كان ذلك مناسبًا. 4. نموذج الطلب صمم نموذجًا مرنًا وقابلًا للتعديل، ويحتوي مبدئيًا على الحقول التالية: * الرقم المرجعي للطلب، يولده النظام تلقائيًا. * عنوان الطلب. * نوع الطلب. * اسم مقدم الطلب. * الرقم الوظيفي، إذا كان مطلوبًا. * القسم والإدارة والقطاع. * تاريخ تقديم الطلب. * موضوع الطلب. * تفاصيل الطلب وأسبابه. * المبررات. * الملاحظات. * المرفقات الاختيارية. * حالة الطلب الحالية. اجعل الحقول الأساسية قابلة للتعديل مستقبلًا دون الحاجة إلى إعادة بناء النظام بالكامل. لا تفترض أن جميع الطلبات ستكون من النوع نفسه. صمم النموذج بطريقة تسمح بإضافة أنواع طلبات وحقول جديدة لاحقًا، مع تجنب إنشاء نظام ديناميكي معقد في الإصدار الأول. 5. إدارة المستخدمين والصلاحيات أنشئ نظام مستخدمين يدعم الأدوار التالية: * Administrator: مدير النظام. * Requester: مقدم الطلب. * Supervisor: المسؤول المباشر. * Department Manager: مدير القسم. * Administration Manager: مدير الإدارة. * Sector Head: رئيس القطاع. صلاحيات مدير النظام * إنشاء المستخدمين وتعديل بياناتهم وتعطيل حساباتهم. * تحديد دور كل مستخدم. * ربط المستخدم بالقسم والإدارة والقطاع. * تعيين المسؤول المباشر ومدير القسم ومدير الإدارة ورئيس القطاع. * تحديد صورة التوقيع المعتمدة لكل مسؤول. * عرض جميع الطلبات وفق الصلاحيات الإدارية. * إدارة أنواع الطلبات والإعدادات الأساسية. * الاطلاع على سجل العمليات والتدقيق. صلاحيات مقدم الطلب * إنشاء طلب جديد. * حفظ المسودات. * إرسال الطلب. * عرض طلباته فقط. * متابعة حالة الطلب والمرحلة الحالية. * الاطلاع على الملاحظات والقرارات المتعلقة بطلباته. * تعديل الطلب عند إعادته إليه. * تنزيل التقرير النهائي بعد اعتماده. صلاحيات المسؤولين * عرض الطلبات المسندة إليهم فقط. * الاطلاع على بيانات الطلب ومرفقاته. * الموافقة أو الرفض أو الإرجاع وفق المرحلة الحالية. * كتابة الملاحظات وأسباب القرارات. * عرض سجل الطلبات التي تعاملوا معها. طبّق الصلاحيات في الخادم PHP، وليس بمجرد إخفاء الأزرار من الواجهة. 6. التوقيعات المصورة والتقرير النهائي PDF هذه من أهم وظائف النظام. عند الموافقة النهائية من رئيس القطاع، يجب أن ينشئ النظام تقريرًا رسميًا بصيغة PDF يتضمن: 1. عنوان التقرير واسم الجهة، مع إمكانية تعديلهما من الإعدادات. 2. الرقم المرجعي للطلب. 3. تاريخ تقديم الطلب. 4. بيانات مقدم الطلب. 5. نوع الطلب وعنوانه. 6. جميع بيانات النموذج المعتمدة. 7. نتيجة الطلب النهائية. 8. سجل مراحل الاعتماد. 9. اسم كل مسؤول اعتمد الطلب. 10. المسمى الوظيفي لكل مسؤول. 11. تاريخ ووقت كل موافقة. 12. صورة التوقيع المعتمدة لكل مسؤول. 13. رمز تحقق أو رقم مرجعي للتحقق من التقرير، إذا أمكن تنفيذه بصورة بسيطة. قواعد التوقيعات * تُرفع صورة التوقيع من قبل مدير النظام أو المستخدم المخول. * تربط صورة التوقيع بالمستخدم والمسمى الوظيفي الصحيحين. * تظهر صورة توقيع المسؤول فقط بعد تنفيذ ذلك المسؤول للموافقة المطلوبة. * لا تظهر توقيعات المراحل التي لم تتم الموافقة عليها. * لا يجوز اعتبار مجرد وجود صورة توقيع موافقة فعلية على الطلب. * لا يسمح للمستخدم العادي باستبدال توقيع مسؤول آخر أو تزوير اعتماده. * يسجل النظام الموافقة الفعلية في قاعدة البيانات أولًا، ثم يستخدم بياناتها الموثقة في التقرير. يجب أن يحتوي التقرير على التوقيعات على شكل صور فعلية مدمجة داخل ملف PDF، وليس مجرد أسماء مكتوبة. استخدم مكتبة mPDF أو مكتبة مناسبة أخرى تدعم العربية واتجاه RTL ودمج صور PNG أو JPG. احرص على ظهور النصوص العربية بصورة سليمة، وعدم انقطاع التوقيعات أو تداخلها مع النصوص عند الطباعة. أنشئ تصميمًا رسميًا وبسيطًا للطباعة على ورق A4. بعد إنشاء التقرير، احفظه في مسار غير متاح للوصول المباشر من الإنترنت، واجعل تنزيله يتم عبر PHP بعد التحقق من صلاحية المستخدم. يجب أن يمثل التقرير نسخة نهائية من البيانات المعتمدة. لا تسمح بتعديل التقرير المعتمد بصمت؛ وإذا تغيرت البيانات لاحقًا بصلاحية استثنائية، فيجب توثيق ذلك وإنشاء نسخة جديدة عند الحاجة. 7. تتبع الطلبات وسجل الإجراءات أنشئ صفحة لتتبع الطلب تعرض: * الرقم المرجعي. * عنوان الطلب. * مقدم الطلب. * تاريخ الإنشاء والتقديم. * الحالة الحالية. * المستوى الذي يوجد عنده الطلب. * المسؤول الذي ينتظر منه اتخاذ الإجراء، بحسب الصلاحيات. * تاريخ آخر تحديث. * سجلًا زمنيًا لجميع مراحل الطلب. اعرض مسار الطلب بصريًا، مثل: تقديم الطلب ← المسؤول المباشر ← مدير القسم ← مدير الإدارة ← رئيس القطاع ← اعتماد نهائي. استخدم حالات واضحة مثل: * مسودة. * قيد مراجعة المسؤول المباشر. * قيد مراجعة مدير القسم. * قيد مراجعة مدير الإدارة. * قيد مراجعة رئيس القطاع. * معاد للتعديل. * معاد للمستوى السابق. * معتمد نهائيًا. * مرفوض. * ملغى. يجب أن تعكس الحالة المرحلة الفعلية للطلب، وأن تكون هناك قاعدة واضحة لحالة الطلب عند إرجاعه ثم إعادة تقديمه. أنشئ سجل تدقيق Audit Log يسجل على الأقل: * المستخدم الذي نفذ الإجراء. * الإجراء المنفذ. * رقم الطلب. * الحالة السابقة. * الحالة الجديدة. * الملاحظات أو سبب القرار. * التاريخ والوقت. يجب ألا يمكن تعديل سجل التدقيق أو حذفه من خلال الواجهات الاعتيادية للنظام. 8. الإشعارات أنشئ نظام إشعارات داخلي بسيط. أرسل إشعارًا إلى المستخدم المناسب عند: * تقديم طلب جديد. * وصول الطلب إلى مرحلته. * الموافقة على الطلب ونقله إلى المرحلة التالية. * رفض الطلب. * إرجاع الطلب للتعديل. * إرجاع الطلب إلى المستوى السابق. * إعادة تقديم الطلب بعد التعديل. * صدور الاعتماد النهائي. * جاهزية تقرير PDF للتنزيل. يجب أن يتمكن مقدم الطلب من رؤية إشعاراته ومتابعة طلباته من لوحة التحكم. لا تفترض الحاجة إلى البريد الإلكتروني أو الرسائل النصية في الإصدار الأول. صمم النظام بحيث يمكن إضافة البريد الإلكتروني أو وسائل إشعار أخرى مستقبلًا دون تغيير جذري. 9. واجهات النظام أنشئ واجهة عربية RTL بسيطة، احترافية، سريعة، ومتجاوبة مع الجوال والكمبيوتر. الصفحات الأساسية: 1. تسجيل الدخول. 2. لوحة التحكم. 3. إنشاء طلب جديد. 4. مسوداتي. 5. طلباتي. 6. الطلبات الواردة للمراجعة. 7. تفاصيل الطلب. 8. سجل تتبع الطلب. 9. الإشعارات. 10. التقرير النهائي وتنزيل PDF. 11. إدارة المستخدمين. 12. إدارة الأدوار والربط الإداري. 13. إعدادات النظام. تختلف عناصر لوحة التحكم بحسب دور المستخدم. يجب أن تكون أزرار الموافقة والرفض والإرجاع واضحة، مع نافذة تأكيد قبل تنفيذ الإجراء. عند الرفض أو الإرجاع، اجعل كتابة السبب إلزامية. اعرض رسائل نجاح وخطأ مفهومة باللغة العربية، مع التحقق من المدخلات قبل حفظها. 10. قاعدة البيانات صمم قاعدة بيانات MySQL منظمة وبسيطة، مع العلاقات والفهارس والقيود المناسبة. يمكن أن تشمل الجداول الأساسية: * users * roles * departments * requests * request_attachments * workflow_steps أو workflow_actions * request_comments * notifications * audit_logs * system_settings يمكن تعديل هذه البنية إذا وجدت تصميمًا أبسط وأكثر أمانًا. المتطلبات: * استخدام InnoDB. * استخدام utf8mb4 لدعم اللغة العربية. * استخدام المفاتيح الأساسية والخارجية المناسبة. * منع التكرار غير المقصود. * حفظ التواريخ والأوقات بطريقة متسقة. * حفظ سجل كل إجراء اعتماد بصورة مستقلة. * عدم الاعتماد على اسم الحالة أو الدور المرسل من المتصفح دون التحقق منه في الخادم. * توفير ملف SQL كامل لإنشاء قاعدة البيانات والجداول والفهارس والعلاقات. * توفير بيانات تجريبية اختيارية لتجربة النظام. * توفير طريقة آمنة لإنشاء أول حساب مدير للنظام. لا تخزن كلمات المرور كنص صريح. استخدم password_hash وpassword_verify في PHP. 11. الأمان طبق الحد الأدنى الضروري من الممارسات الأمنية الصحيحة: * استخدام PDO وPrepared Statements لجميع استعلامات قاعدة البيانات. * الحماية من SQL Injection وXSS وCSRF. * التحقق من صلاحيات المستخدم على كل عملية في الخادم. * حماية الجلسات وتغيير معرف الجلسة بعد تسجيل الدخول. * تسجيل الخروج وإنهاء الجلسة بصورة صحيحة. * التحقق من أنواع الملفات المرفوعة وأحجامها. * تخزين المرفقات والتقارير خارج المجلد العام للموقع. * منع الوصول إلى الطلبات والمرفقات والتقارير غير المصرح بها. * التحقق من ملكية الطلب وصلاحية الوصول إليه. * استخدام معاملات قاعدة البيانات Transactions عند تنفيذ إجراءات الاعتماد التي تتضمن عدة عمليات مترابطة. * معالجة الأخطاء دون عرض كلمات المرور أو تفاصيل الاتصال أو الاستعلامات الحساسة للمستخدم. * توفير سجل للأخطاء التقنية مع عدم تسجيل كلمات المرور أو البيانات الحساسة غير الضرورية. يجب ألا يتمكن المستخدم من تغيير رقم الطلب في الرابط للوصول إلى طلب شخص آخر. 12. سهولة التعديل والتطوير هذه نقطة أساسية. أريد كودًا بسيطًا وواضحًا، وليس نظامًا معقدًا يصعب فهمه. التزم بما يلي: * فصل إعدادات قاعدة البيانات في ملف مستقل. * فصل وظائف المصادقة والصلاحيات عن صفحات العرض. * إنشاء وظائف واضحة لمعالجة تقديم الطلب والموافقة والرفض والإرجاع. * فصل منطق Workflow عن HTML قدر الإمكان. * تجنب تكرار الكود. * تجنب استخدام أنماط تصميم معقدة دون حاجة. * استخدام أسماء ملفات ودوال ومتغيرات مفهومة. * إضافة تعليقات عربية مختصرة للأجزاء المهمة. * وضع إعدادات النظام في مكان مركزي. * تجنب كتابة مسار الموافقات كاملًا داخل عدة صفحات مختلفة. * اجعل تغيير تسلسل المسؤولين أو إضافة مرحلة جديدة ممكنًا بتعديلات محدودة ومدروسة. لا تبنِ محرك Workflow عامًا ومعقدًا في الإصدار الأول. المطلوب هو تنفيذ المراحل الأربع المحددة بوضوح، مع تنظيم الكود بحيث يمكن توسيعها لاحقًا. 13. الاختبارات أنشئ اختبارات عملية للوظائف الأساسية، تشمل: * تسجيل الدخول والخروج. * منع الوصول دون تسجيل الدخول. * منع المستخدم من الوصول إلى طلب لا يملكه أو ليس مخولًا برؤيته. * تقديم طلب جديد. * انتقال الطلب الصحيح بين المراحل. * رفض الطلب وإنهاء مساره. * إرجاع الطلب للتعديل ثم إعادة تقديمه. * إرجاع الطلب إلى المستوى السابق. * منع تخطي مرحلة اعتماد. * منع تكرار الموافقة أو تنفيذ إجراء غير مسموح. * ظهور الإشعارات للمستخدم الصحيح. * إنشاء تقرير PDF عربي يحتوي على التوقيعات المعتمدة. * عدم إصدار تقرير نهائي قبل موافقة رئيس القطاع. * الحفاظ على سجل الإجراءات بعد إعادة الطلب. قدم خطوات واضحة لتشغيل الاختبارات. إذا لم تتمكن من تشغيلها فعليًا، فاذكر ذلك صراحة ولا تدّعِ نجاحها. 14. الملفات المطلوبة أنشئ مشروعًا كاملًا ومنظمًا، يشمل: * ملفات PHP اللازمة للتشغيل. * ملفات CSS وJavaScript. * ملفات القوالب والواجهات. * ملف إعدادات نموذجي. * ملف SQL لإنشاء قاعدة البيانات. * ملفات مكتبات PDF المطلوبة أو تعليمات تثبيتها. * ملف README باللغة العربية يشرح التشغيل. * تعليمات إعداد قاعدة البيانات من خلال phpMyAdmin. * تعليمات إنشاء أول مستخدم مدير. * تعليمات إعداد Apache أو Nginx على Ubuntu. * تعليمات ضبط صلاحيات المجلدات ورفع الملفات. * اختبارات الوظائف الأساسية. * بيانات تجريبية اختيارية. استخدم ملف إعدادات نموذجي مثل .env.example عند الحاجة، ولا تضع كلمات مرور حقيقية داخل المشروع. 15. طريقة تنفيذ المشروع نفذ العمل على مراحل واضحة: المرحلة الأولى: تحليل المتطلبات وتحديد حالات الطلب والانتقالات المسموح بها والصلاحيات. المرحلة الثانية: تصميم قاعدة البيانات والعلاقات بينها. المرحلة الثالثة: إنشاء هيكل المشروع وملفات الاتصال والمصادقة والصلاحيات. المرحلة الرابعة: بناء نموذج تقديم الطلب ومسار الاعتماد. المرحلة الخامسة: بناء تتبع الطلبات وسجل الإجراءات والإشعارات. المرحلة السادسة: إنشاء التقرير الرسمي PDF والتوقيعات المصورة. المرحلة السابعة: تنفيذ الأمان والاختبارات ومعالجة الأخطاء. المرحلة الثامنة: إعداد دليل التشغيل والنشر على Ubuntu. ابدأ بعرض تصميم مختصر للنظام ومخطط قاعدة البيانات ومسار الحالات، ثم ابدأ بإنشاء الملفات الفعلية. إذا كانت لديك صلاحية التعامل مع ملفات المشروع في بيئة التطوير، أنشئ الملفات مباشرة. وإذا كنت تعمل في بيئة لا تتيح إنشاء الملفات، اعرض الملفات كاملة بمساراتها الصحيحة ومحتوياتها دون الاكتفاء بمقاطع ناقصة أو أمثلة توضيحية. لا تتوقف عند مرحلة التخطيط؛ أكمل تنفيذ المشروع إلى أن يصبح قابلًا للتشغيل وفق الإمكانات المتاحة. 16. معايير قبول المشروع لا تعتبر المشروع مكتملًا إلا إذا تحققت الشروط التالية: 1. يستطيع الموظف تسجيل الدخول وتقديم طلب. 2. ينتقل الطلب إلى المسؤول الصحيح حسب التسلسل المحدد. 3. يستطيع كل مسؤول تنفيذ الإجراءات المسموحة لمرحلته فقط. 4. يعمل الرفض والإرجاع والتعديل وإعادة التقديم بصورة صحيحة. 5. يستطيع الموظف تتبع الطلب ومشاهدة القرارات المتعلقة به. 6. تحفظ جميع الإجراءات في سجل تاريخي. 7. تظهر الإشعارات للمستخدمين المعنيين. 8. بعد اعتماد رئيس القطاع، يصدر تقرير PDF باللغة العربية يحتوي على بيانات الطلب والتوقيعات المصورة للموافقات الفعلية. 9. لا يمكن تنزيل الطلبات أو التقارير دون صلاحية. 10. يعمل النظام باستخدام PHP وMySQL ويمكن إدارته عبر phpMyAdmin. 11. توجد تعليمات تشغيل واختبارات واضحة. 12. يكون الكود مفهومًا وسهل الصيانة والتطوير. تعليمات نهائية اتخذ القرارات التقنية البسيطة المناسبة بنفسك، ولا تكثر من الأسئلة غير الضرورية. إذا وجدت نقطة غير محددة، فاختر حلًا افتراضيًا آمنًا وعمليًا، ووثّق افتراضك حتى أستطيع تعديله لاحقًا. الأولوية بالترتيب هي: 1. صحة مسار الاعتماد والصلاحيات. 2. أمان الطلبات والتوقيعات والتقارير. 3. سهولة الاستخدام باللغة العربية. 4. بساطة الكود وسهولة صيانته. 5. إمكانية التطوير مستقبلًا. ابدأ