المعلوماتية > برمجيات
3 البرمجة القصوى
اخترع كلٌّ من Kent Beck وWard Cunningham البرمجة القصوى (EXtreme Programming
تعتمد XP على الأفكارِ الأساسية الأربعِ التالية:
1. المشاركة العظيمة للمستخدمين: تتطلب XP أن يكون الزبون جزءاً من فريق التطوير وأن يتواجدَ معه طوال الوقت، بحيث يساهم في إنشاء المنتج في كل دورةٍ من حياته، وكذلك يستطيعُ طلبَ اختبارات القبول اللازمة على كلِّ نسخةٍ من المُنتج قبل وصوله إلى شكله النهائي.
2. اختبارات الوحدة المستمرة: ما يُعرف أيضاً بالتطوير المُقاد بالاختبار (Test Driven Development
3. البرمجة المزدوجة: تتطلب XP أن يكون الكود مكتوباً من قِبل أزواجٍ من المبرمجين، تتطلب البرمجة الزوجية مبرمِجَين –Driver and Navigator – يشتركان بحاسبٍ واحد، المبرمج Driver يكتب الكود بينما المبرمج Navigator يراقبه ويلتقط الأخطاء، يعطي اقتراحاتٍ ويفكّر بالتصميم والاختبار .. الخ. ويتبادل الزوجُ الأدوارَ كلَّ فترة (30 دقيقةٍ مثلاً، أو عندما يشعر أحدهما أنه أفضل في الدور الآخر).
تعتمد البرمجة الزوجية نظرية "رأسان أفضل من واحد"، وهي ليست وفيرةَ الإنتاج مثلَ البرمجة الفردية من حيث عدد الأسطر البرمجية المكتوبة في وحدة الزمن، ولكنّ الكود المكتوب بهذه الطريقة عادةً ما يحوي على عددٍ أقل من الأخطاء، وتوجد مجموعةٌ من حالات الاختبار لإثبات ذلك، مما يجعل هذه الطريقة أكثر إنتاجاً بالمجمل. الجدير بالذكر أنّ البرمجة الزوجية ليست مقتصرةً على XP، ولكنّ XP كانت السبّاقة لاستخدامها.
4. دوراتُ حياةٍ تكرارية قصيرة، وإصداراتٌ متكررة: يُصدر مستخدمو XP المثاليون سلسةً من النسخ خلال عدة أشهر، وكلُّ نسخةٍ مركبةٌ من عدة تكرارات، تتم كل منها ضمن 4-6 أسابيع. هذا المزيج من الإصدارات المكررة ووجودُ ممثلٍ للزبون مع الفريق، يعطي تغذيةً راجعةً مباشرةً على المزايا الجديدة والتصميم غير المغطى بالكامل، والمتطلبات بشكلٍ مبكر. تتطلب XP تكاملاً ثابتاً وبناءً للمنتج، كلما انتهت البرمجة الزوجية من ميزةٍ معينة ونجحت كلُّ اختبارات الوحدة مباشرةً، تُدمج هذه الميزة مع باقي النظام ويُبنى كامل المنتج. تُستخدم بعد ذلك كلُّ اختباراتِ الوحدة كحالةِ اختبارٍ راجعة للتأكد من أن المزايا الجديدة التي تمت إضافتها لم تُخرِّب أيَّ شيءٍ بالنظام الذي تم اختباره من قبل. لذلك قد يحدث الدمج وإعادة البناء في مشروع XP عدّة مراتٍ في اليوم. تُعطي هذه العمليةُ الفريقَ شعوراً جيداً حول المكان الذي وصلوا له في دورةِ حياةِ النسخة كلَّ يوم، وتعطي الزبون بناءً كاملاً ليجرِّبَ اختبارات القبول عليه.
المخاطر هي أكبر مشكلةٍ بالبرمجيات، فإدارة المخاطر صعبةٌ جداً ومكلفةٌ من حيث الوقت. تعمل XP على تقليل المخاطر عن طريق التحكم بأربعةِ متحولات رئيسية: التكلفة، الوقت، المزايا، الجودة.
1. التكلفة: ربما هي الأكثر تقييداً، فهي تحدٍّ مما يمكن بذله من إعداد الجدول الزمني والجودة، وتخضع لقوانين Brooks (إضافة مبرمجين جدد إلى مشروع متأخر سوف يأخره أكثر).
2. الوقت: يُفرض الجدول الزمني من الخارج للأسف، على سبيل المثال لا يمكنك تغيير موعد عطلة الميلاد، والحل الوحيد لمشكلة التأخير هي إما بإنقاص المزايا أو تقليل الجودة.
3 الجودة: هي عدد المخاطر والعيوب التي يمكننا تلافيها لإخراج نموذجٍ مثاليٍّ إلى حدٍّ ما، يمكن للتكلفة أن تحدَّ أو أن ترفعَ من جودة المنتج.
4. المزايا (أو المجال): هي ماذا يفعل المنتج، والأشياءُ التي على المطورين أن يركّزوا عليها. هذا المتحول هو الأهم من وجهة نظر الزبون. ويسمحُ التحكم بالمزايا للمدراء والزبائن على حدٍّ سواء أن يتحكموا بالجودة والوقت والتكاليف.
لجعل XP قابلةً للتطبيق؛ لا بدَّ من الالتزام بمجموعةٍ من القيم الأساسية، وهذه أهمُّ أربعٍ منها:
1. التواصل: يعني نشرَ المعرفة بين جميع أعضاء الفريق، لذلك تكون فرق XP عادةً صغيرة، ممّا يسهل عمليات التواصل عن طريق جعل عدد خطوط الاتصال أقل ما يمكن، تسهّل البرمجة الزوجية والملكية الجماعية للكود أو الشيفرة البرمجية التواصلَ أيضاً، عن طريق نشر المعرفة الموجودة داخل الكود في كل الفريق.
2. البساطة هي المفتاح: تركز XP على البساطة في تطوير البرمجيات، "أن تعمل شيئاً بسيطاً اليوم وتدفع غداً لتغييره إذا لزم الأمر، أفضلُ من أن تنجز شيئاً كاملاً اليوم ربما لن تستخدمه أبداً". يُسمح لكل المطورين في XP بل ويُشجَّعون على إعادة تصميم الكود لجعله أبسط في أي وقت.
3. التغذية الراجعة: "يُعتبر التفاؤل مخاطرةً مهنية في البرمجة، والتغذية الراجعة هي الحل". يُطلب من مبرمجي XP كتابة الاختبارات قبل كتابة الكود، لذلك لديهم تغذيةٌ راجعةٌ مباشرةٌ عن كودهم، تؤثّرُ بشكلٍ مباشرٍ على النظام. كذلك يكتب الزبون اختباراتِ القبول، لذلك تكون هذه الاختباراتُ متاحةً لقياسِ مدى التزام النظام بالقصص المستخدمة للتطوير.
4. الجرأة: على مبرمجي XP أن يمتلكوا القدرة على تعديل أيِّ جزءٍ من الكود بأي وقت عندما لا يشعرون بأنه مناسب، بل ويجب أن يكونوا متحضّرين للتخلص منه عندما لا يعمل بالطريقة المناسبة. يتْبعُ فريق XP جدولاً زمنياً محدداً، ويُطلبُ من الزبون إعادة ترتيب أولويات الوظائف المطلوبة كلما اقتضت الحاجة.
وتوجد مجموعة من المبادئ التي يمكن اتباعها لتحقيق القيم الأساسية السابقة ونذكر منها ما يلي:
1. تغذيةٌ راجعةٌ سريعة: الحصول على التغذية الراجعة، تفسيرُها وإعادتُها الى النظام بأسرعِ ما يمكن. الاختبارات الأوتوماتيكية حاسمةٌ هنا لأنها تمكّنُ من إجراء اختبارات الوحدة طوال الوقت، ويمكن مكاملة التغييرات بأي لحظةٍ مع باقي النظام.
2. افتراض البساطة: "التركيز في مهام اليوم وحلّها بأبسط طريقة ممكنة"، هذا يعني البحث دائماً عن طُرُقٍ لتبسيطِ الكود قدرَ الإمكان، حتى تُجرى التغييرات بأي وقت.
3. التغيير بشكل تزايدي: دمجُ ومكاملةُ الكود الجديد مع النظام كلَّ يوم، أو بالأحرى مكاملتُه عند نهاية كل مهمة؛ يسمحُ بإيجاد واجهةٍ للتفاعل مع الأخطاء بسهولة.
4. تطويق التغير: "التغير أمرٌ سيحدث حتماً، لذلك تحضَّر له". كلُّ مبادئ المنهجيات الرشيقة (Agile Methodologies) مثل XP تَعتبِرُ التغيرّ هو الثابتَ الوحيد بتطوير البرمجيات.
5. تحقيق الجودة: "الجودة ليست بالمجان"، لابدّ من بذلِ جهدٍ للحصولِ على كودٍ خالٍ من الأخطاء. البرمجة الزوجية التي تقوم على فكرة "رأسان أفضل من واحد"، والبرمجة المُقادة بالاختبار التي تركّزُ على جعل الكود يحقق المتطلبات، تقودان إلى أخطاءَ أقل.
6. تعلُّم التعلُّم: تعلُّمُ كيف تتعلَّمُ بنفسكَ إجراءَ اختبارات، إعادة التصنيع، وكتابة كود، أفضلُ من قراءةِ قواعدَ تقول: "يجب أن تختبرَ بهذه الطريقة أو تكتبَ الكود بهذا الشكل".
7. استثمارٌ بدائيٌّ صغير: التركيز هنا على الأجزاء الصغيرة خاصّةً في بداية المشروع لإدارة الموارد بحذرٍ واعتدال. البدءُ بمواردَ أقلّ وميزانيةٍ محكمة، يؤدي إلى تركيز التفكير بتعلّم التصميم والكود، وهذا يعزز ويدعم مبدأ البساطة سابق الذكر.
8. العب لتربح: "عكس أن تلعب حتى لا تخسر". إذا لم يكن المطوّرُ قلقاً حول الجدول الزمني أو المتطلبات، ستكون أيّامه أكثرَ راحة وسيكون قادراً على التركيز على المشاكل، وبالتالي سيكون كوده أفضل وسيكون منتِجاً أكثر.
9. تجاربٌ متماسكة: كلُّ قرارٍ مجرّدٍ (متطلباتٌ أو تصميم) يجب أن يُختبر. تشجّع XP والمنهجيات السريعة الأخرى على إنتاج شيءٍ يدعى السنبلة، وهي قطعةُ كودٍ سريعة وغيرُ نظيفة تحقّقُ على الأقل جزءاً مما يريده المطوِّر، وبهذا يمكنه رؤية إذا ما كان على حقٍّ فعلاً أو إذا كان على خطأ. بحيث لا يَضيعُ الكثير من الوقت لاكتشاف ذلك.
10. اتّصالات مفتوحة وصادقة: يجب أن تكون ثقافةُ الفريق قائمةً على النقدِ البنّاء وبأيِّ وقت. الفكرة أن الجميع سيحاول تحسينَ الكود الذي يكتبه من ناحية، ومن ناحيةٍ أخرى فالملكية العامة للكود تعني أنَّ كلَّ شخصٍ مُخوّلٌ لإجراء تغييراتٍ دونَ الخوف من جرح مشاعر الآخرين.
11. العمل وفق غرائز الناس وليس ضدها: يحبّ الناس الفوز عموماً، وكذلك العمل مع الآخرين، والكون جزءٌ من فريق، ويحبّون رؤية كودهم يعمل، لا يجب فعل أشياءَ عكسَ ذلك.
12. قبول المسؤولية: الفريق بكامله مسؤولٌ عن المنتج، بحيث تُقبل المسؤولية من قِبَل كلِّ الفريق، والمهمات غير موكلةٍ لأحد، بل تُطلب من قبل من يرغب بإنجازها، حيث لا تملك فرق XP مديراً يُسند المهامَ للأشخاص، وإنما لديهم مدربٌ للمساعدة التقنية، ومديرُ مشروعٍ للاعتناء بالمهام الإدارية، ويَختارُ أعضاءُ فريق التطوير بأنفسهم المهامَ ويتأكدون من إنجازها، وبالنهاية فالملكية العامة للكود تقود للملكية العامة للمنتج.
13. التكيف المحلي: تكييف XP لتناسب الظروف المحلية للمشروع، وهذا تطبيقٌ لقبول المسؤولية، يملك الفريقُ المشروعَ وبالتالي يملك العملية وفي متناول يده الإجماع على التكيف.
14. الخفة: يجب أن تبقى منتجات الفريق والعملية قليلةً بسيطةً وقيّمة، هذا يقتضي القدرة على تغيير الاتّجاهات بسرعة والتخلص من الحمولة الزائدة (كود أو تصميم) التي لا تعمل كما يجب.
15. القياسات الصادقة: القياسُ بالمستوى الصحيح من التفاصيل، وقياسُ فقط ما يُحدثُ فرقاً على المشروع.
ولجعل XP تأخذ القيم والمبادئ التي قمنا بشرحها مسبقاً. نحن بحاجةٍ لشرح الفعاليات التي سنستخدمها كقاعدة أساس، لدينا 4 فعاليات تشكل حجر الأساس:
1. صياغة الكود: الكود هو الفعالية الأساسية. الفرقُ الأساسي بين النماذج المُقادة بالخطة والنماذج السريعة، هو التركيز على الكود. في النماذج المقادة بالخطة، التأكيد على إنتاج مجموعةٍ من منتجاتٍ تعمل مع بعضها لتقدّم مشروعاً كاملاً والكود هو فقط واحدٌ من هذه المنتجات العاملة. في المنهجيات السريعة، الكود يُولد لوحده، بالتالي عبر هيكلة الكود والحفاظ على التعليقات حديثة دائماً، يصبح الكود توثيقاً للمشروع بحد ذاته.
2. الاختبار: يُخبر الاختبارُ المطورين متى تنتهي كتابة الكود. في التطوير المقاد بالاختبار فكرةٌ مصيرية وهي إدارة التغيير. تعتمد XP بقوةٍ على كتابة وحداتِ اختبارٍ قبل كتابة الكود الذي يجري اختباره، واستخدامُ بيئة اختبارٍ أوتوماتيكي لإجراء اختبارات الوحدة، بحيث كلما حدث تغيرٌ تتم مكاملته مع النظام.
3. الاستماع: إلى الشريك وإلى الزبون. في أي مشروع تطوير برمجياتٍ يوجدُ نوعان من المعرفة، يمتلك الزبون معرفةً عن التطبيق التجاري وماذا يجب أن يَدعم، وتُدعى هذه بمعرفة مجال المشروع. ويملك المطورون معرفةً عن المنصة الهدف ولغات البرمجة وقضايا التنفيذ، وتُدعى هذه بالمعرفة التقنية للمشروع. لا يعرف الزبون الجانب التقني، ولا يعرف المطورون عن المجال التجاري أو مجال العمل، لذلك الاستماع لكلا الطرفين هو فعالية مفتاحية في تطوير المنتج.
4. التصميم: التصميم أثناء كتابة الكود. التصميم هو إنشاء بنيةٍ تنظّم منطق النظام، ويحاول التصميم الجيد جعلَ التغيّرِ في جزءٍ من النظام لا يتطلب تغيرَ جزءٍ آخرَ فيه، وكذلك السماحَ بتوسيع النظام عن طريق إحداث تغيراتٍ في مكانٍ واحدٍ فقط.
المراجع:
Software Development and Professional Practice - John Dooley - 2011 - Apress Publisher
ISBN-13 (electronic): 978-1-4302-3802-7