هنا نكمل ما قد بدأناه في الجزء الأول المتعلق بالبرمجة القصوى وأهم الممارسات والطرق الخاصة بال XP
نتابع الممارسات:
– التصاميم البسطية (Simple Design):
البساطة نصف الجمال, وهذه قاعدة مهمه في ال XP فلا داعي لزيادة تعقيد التصاميم الخاصة بالتطوير وعمل رسومات تفصيليه بل فقط على قدر المطلوب لأن القيمة في المنتج النهائي وليست في هذه الرسوم.
– التطوير الموجه بالفحص (Test Driven Development):
“كل الكود مدان حتى تثبت براءته” هذه بإختصار فكرة التطوير الموجه بالفحص بمعنى بناء كود الإختبار قبل كتابة الكود الفعلي, ومن ثم يتم كتابة الكود الفعلي وإختباره بكود الإختبار فإن نجح يكون كود فعال. أما إن فشل يتم تغيير الكود إلى أن ينجح, ويمكنكم العودة إلى تدوينة الوحدة الإختبارية.
– إعادة بنية التعليمات البرمجية (Refactoring):
يحتاج الكود من فترة إلى أخرى للمراجعة ليكون مقروء ومفهوم بشكل جيد, ولذى هناك مرحلة إعادة بنية الأكواد لتتأكد من عدم وجود أكواد شاذة أو غير فعالة, يتم التحسين على الكود دون تغيير المهام الرئيسية. يمكنكم الإطلاع على التدوينات التالية المتعلقة بالأمر:
– ال Refactoring إعادة بنية التعليمات البرمجية , سنن فأسك من جديد !
– Code Smell , تخلص من السباجيتي , الجزء الأول !
– Code Smell , تخلص من السباجيتي , الجزء الثاني!
– البرمجة المزدوجة (Pair Programming):
يكون هناك شخص يقوم بكتابة الكود واخر يتابع تفاصيل المهمة, ويتم التبادل بينهما حتى إنهاء المهمة المطلوبة. هناك كثير من يستهجن هذه الفكرة حيث لا يتصور كيف يمكن لإثنين العمل في الوقت ذاته على نفس الكود, ولكن الحقيقه أن هذه العملية توفر الكثير من الأخطاء وتساعد في إنهاء المهام بشكل أسرع.
– ملكية المجموعة (Collective Ownership):
نموذج ال XP يقوم على المشاركة حتى على مستوى الكود, بمعنى أنه لا يمكن لأحد أن يملك جزء معين من الكود, فيمكن لأي أحد أن يضيف أو يعدل أو يحذف أي كود كتب من الأخرين إذا كانت المهمة تتطلب ذلك.
– التكامل المستمر (Continuous Integration):
عند تطوير أي جزئية جديدة والتأكد من عملها بشكل مستقل, ووضعها مع باقي أجزاء النظام السابقة فربما تقوم بإحداث مشكلة في أجزاء أخرى, لذلك ينبغي عند إضافة أي جزء برمجي جديد التأكد من عدم تأثيره على الأجزاء الأخرى. هناك أدوات مساعدة مثل Jenkins حيث تقوم كل ما تم إضافة جديده بتشغيل كل الوحدات الإختبارية والتأكد من عدم إحداث مشكلة على البقية.
– 40 ساعة في الأسبوع (40 Hours a week):
المطورين هم بشر بالنهاية, ولا يمكن بأي حال التعامل معهم على أنهم آلات تعمل دون تأثر, لذلك إذا ما أردنا إبداعا في الحلول و سرعة في الإنجاز فيجب توفير المناخ المناسب والتوازن للمطورين. فإضافة ساعات أكثر من اللازم لا يحل المشاكل بل يزيدها تعقيدا. قد نحتاج في بعض الأحيان إلى عمل زيادة في الساعات ولكن لا ينبغي أن تصبح هذه القاعدة قاعدة معممة ودائمة.
– العميل في الميدان (On-Site Customer):
الهدف الرئيسي هو تحقيق مطلب العميل أو الزبون, وفي حال ما أردنا ذلك بشكل أسرع فوجود العميل سيساعد في مشاركته في القرارات, وكذلك تأكيد أن سير التطوير على مايرام وحسب المطلوب. بالتأكيد هناك أحيان كثيرة لا يمكن فيها وجود العميل, لذلك يجب أن يكون هناك صوت له أو ممثل عنه مثل ما يسمى بال Product Owner والذي يفترضه نموذج سكروم, يمكنكم الإطلاع على تدونية إطار سكروم ماهو وكيف ؟.
– القياسات البرمجية (Coding Standard):
هذه الممارسة تؤكد الممارسة الخاصة بملكية المجموعة, بمعنى يجب أن يكون الكود الذي ينتج من الجميع ضمن معايير وقياسات محددة بحيث يسهل للجميع فهمه والتعامل معه. وهذه المعايير يتم الإتفاق عليها مسبقا قبل الشروع في كتابة الكود.
كانت هذه أهم الممارسات الخاصة بال XP, بالتأكيد هناك من ينفذها بكل حذافيرها وهناك من يختار منها حسب الأنسب لطبيعة العمل.
دمتم بود إلى تدوينة أخرى.
