ما زلت بمرحلة التعلم اﻻساسي ﻷساليب تنظيم البرمجيات، خاصة الكبيرة منها
لكن لدي فكرة بسيطة عن كيفية ترتيب برمجية تجارية كبيرة (enterprise)
بحيث تكون قابلة للتطوير وقليلة الأخطاء، طبعًا هذا حد علمي حتى اﻻن وقد
يتغير مستقبلا ً بحكم الخبرة
طبعًا هذه اﻻمور غير ضرورية في كل المشاريع، لكن لا يمكنني تجاهلها كمبرمج ومهتم بالمجال
1)
يمكن استخدام أساليب تسمية خاصة بالبرمجية(naming conventions)
بحيث تعرف من اسم الكلاس ماذا يعني وماذا يفعل واين مكانه في ملفات المشروع.
كذلك يمكن ان يوفر عليك ذلك بعض العمليات أو التخزين في قواعد البيانات،مثلا
انت تعرف ان اﻻضافات موجودة في مجلد اسمه plugins اسم الملف سيكون TestPlugin
واسم الكلاس سيكون plugins_TestPlugin
لذلك لا داع لأن تحفظ هذه اﻻمور في قاعدة بيانات.
يمكن ان نشمل مع هذا البند استخدام ال namespaces لعمل مركبات الموقع بصورة منفصلة عن بعضها
قدر اﻻمكان.
2)استخدام ال unit test: كل متحكم او موديل يجب ان نعمل له كلاس ليفحصه عن طريق phpunit التي اصبحت مدمجة بنسخة ال php بشكل افتراضي.
الأسباب:
* نفرض انك مثلا تفحص مخرجات الكود عن طريق الطباعة داخل المتحكم ثم تحذفها فيما بعد عندما
يعمل الكود، لكن عندما تعمل تغييرات كبيرة على الكود refactoring ربما تحصل اخطاء كثيرة في اماكن
مختلفة من البرمجية، وعندها يمكن ان يخرج اﻻمر عن السيطرة، وتضطر إلى اعادة فحص اقسام كثيرة من الكود
من البداية، طبعًا هناك حل اخر وهو ابقاء جمل الفحص موجودة في الكود لكن مع استعمال ثابت باسم DEBUG_MODE تغير قيمته عندما تريد فحص السكربت، لكن هذا يقودنا للنقاط اﻻخرى.
* ال unit test يعطي تقرير عن نسبة فحص الكود يعني يعطيك الأماكن غير المفحوصة حتى اﻻن حتى تنتبه لها وتفحصها قبل فوات اﻻوان.
*في ال unit tests انت تفحص الكود من الخارج، وهذا يجبرك على ترتيب الكود بشكل انك تستطيع فحصه من الخارج، يعني سوف تقوم بتغيير الكثير في ترتيب الكود حتى يصبح قابل للفحص، وهذا يجعلك تكتب كود افضل من حيث لا تشعر .
3)استخدام ال design patterns :
وهي طرق شائعة ومعروفة مسبقًا لحل مشاكل محددة، وتساعدك على ترتيب الكود بطريقة منطقية ومفهومة لباقي المبرمجين، كما انها تمنع العبث بالكود من قبل المبرمجين وتجعله منظمًا اكثر، مثلا أسلوب ال singleton
يمنعك من تعريف الكائن اكثر من مرة في الكود، وهذا جيد جدًا لقواعد البيانات ولل front controller مثلاً
اذ انك ربما تستأجر مبرمجًا لعمل تعديل على الكود، لكن بما انه لم يكتب الكود ربما يقوم بعمل بعض الطرق غير الصحيحة نظرًا لقلة خبرته في الكود، وهذا مع ال unit tests يجعله يعرف خطأه، وبالتالي يتعلم اسرع، ايضًا ربما يكون المبرمج كسولا ويحاول وضع "أي كود يعمل" بغض النظر عن جودته، لكن ال design patterns تمنعه من ذلك.
هناك ايضًا اساليب اخرى مثل mvc وهي اكثر من مجرد فصل التصميم عن البرمجة ، ففيها ايضًا نظريات اخرى مثل fat model thin controller وغيرها...
الكثير من المبرمجين يشتكون من الصعوبات الكامنة في اطر العمل، وانها تقيد المبرمج باسلوب العمل الخاص بها،لكن هذه الصعوبات وجدت قصدًا، حتى تنظم الكود، ونحن كمبرمجين ندخل بارادتنا إلى هذا القفص المسمى اطار عمل، لمصلحة تطوير الكود بشكل سليم.لهذا يجب علينا ان ندرك ما تحاول اطر العمل ان تفعله، حتى نتجنب الوصول إلى طريق مسدود.
4)
يمكن ايضًا التحكم بنوع اﻻصدار، إذ انه من المتعارف عليه ان نقسم السكربت ل 3 اصدارات
production
test
release
وذلك لسهولة التطوير، مثلا نسخة التطوير يجب ان تكون مريحة للمبرمج من حيث اسماء الكلاسات وظهور اﻻخطاء ، إذ اننا معنيون بظهور جميع اﻻخطاء حتى ال notices .
لكن في نسخة النشر قد نغير الكثير من ال naming conventions او نخفف من ظهور اﻻخطاء وذلك لدواع امنية.
يتم التحكم بهذه اﻻصدارات عادة عن طريق apache ant
5)
يمكن ايضًا تركيب مخازن لحفظ نسخ احتياطية من الكود ، وقد قمت بتجربة ذلك
قبل فترة باستخدام supervision
طبعًا هناك انظمة اخرى لكن أنا استخدمت هذا
6) يمكن ايضًا ان تستعمل اسلوب ﻹدارة المشاريع حسب فلسفتك الخاصة، وهناك العديد منها مثل waterfall,agile
وانا اجرب استخدام agile وبالتحديد
scrum,
kanban
ال agile بشكل عام تدعو إلى السماح للزبون بعمل تغييرات متى شاء على الكود،وهي صعبة جدًا ليس منطقيًا وانما عمليًا اذ ان الزبون متطلب بطبعه، مما يعني الكثير من العمل والضغط على الفريق.
لكن هي كنظرية تستحق اﻻهتمام والتجربة، وهي عبارة عن التالي:
يقوم الزبون بكتابة كل ما يريد من خواص بورقة تسمى backlog
ثم تذهب هذه الورقة للمبرمجين، الذين يقدرون الوقت المطلوب لكل خاصية لكي تكتمل
ويقومون بتقسيم الخواص لفترات زمنية : iterations,sprints بحيث بعد كل فترة زمنية
تقدم خاصية جاهزة للزبون، مع فتح باب الملاحظات له وفتح الباب لتصحيح اخطاء الكود.
ولا يتم اﻻنتقال للفترة الثانية إلا بعد انتهاء جميع المشاكل المتعلقة بالفترة السابقة.
اللقاءات اليومية: يقوم الفريق بعقد لقاء يومي لمدة ربع ساعة (يكون الفريق واقفًا على اقدامه حتى يختصر بالمعلومات ولا يقول سوى المعلومات المفيدة
)، وكل مشارك يقول:
1-ماذا انجز
2-ما هي المشاكل التي واجهته
3-ماذا سيفعل لحل هذه المشاكل
المدير(scrum master):مسؤول عن اﻻدارة والتوجيه وحل المشاكل في الفريق.
المخطط البياناتي burn up charts:
مخطط بياني يوضح التقدم في المشروع ويعطي تقديرًا للفترة الزمنية اللازمة لانهاء المشروع.
وهو ميزة ال scrum
هذه فيديوهات تشرح النظرية:
وهذا موقع لادارة مشاريعك بهذه الطريقة:
http://www.scrumdo.com/
وهذا ما يحدث عندما تنفذ الطريقة خطأ:
المواضيع المشابهه 
مقالات ثرية بالمعلومات احببت مشاركتها 
