ممارسات البرمجة المتطرفة

البرمجة الثنائية هي أسلوب برمجة يقوم فيه شخصان بكتابة الكود معًا على مهمة واحدة. يتحكم أحدهما في محطة العمل ويركز بشكل أساسي على تفاصيل الكود، بينما يركز الآخر على الصورة الكلية ويراجع باستمرار الكود الذي كتبه الأول. يتبادل المبرمجان الأدوار كل دقيقة إلى ساعة.

لا تُعدّ الأزواج ثابتة؛ إذ يُبدّل المبرمجون شركاءهم باستمرار، بحيث يعرف كل فرد ما يفعله الآخر، ويبقى الجميع على دراية بالنظام بأكمله، حتى الأجزاء التي تقع خارج نطاق مهاراتهم. وبهذه الطريقة، يُمكن للبرمجة الثنائية أن تُحسّن التواصل على مستوى الفريق ككل. (وهذا يتوافق أيضاً مع مفهوم الملكية الجماعية).

تُسمى عملية التخطيط الرئيسية في البرمجة المتطرفة "لعبة التخطيط". وتُعقد هذه اللعبة مرة واحدة في كل دورة، عادةً مرة واحدة أسبوعيًا. وتنقسم عملية التخطيط إلى جزأين:

• تخطيط الإصدار : يركز هذا التخطيط على تحديد المتطلبات التي ستُدرج في كل إصدار من الإصدارات القريبة، وموعد تسليمها. ويشارك في هذه العملية كل من العملاء والمطورين. ويتكون تخطيط الإصدار من ثلاث مراحل:
  • مرحلة الاستكشاف: في هذه المرحلة، سيقدم العميل قائمة مختصرة بالمتطلبات ذات القيمة العالية للنظام. وسيتم تدوين هذه المتطلبات على بطاقات قصص المستخدم .
  • مرحلة الالتزام: خلال مرحلة الالتزام، يلتزم كل من قسم الأعمال والمطورين بالوظائف التي سيتم تضمينها وتاريخ الإصدار التالي.
  • مرحلة التوجيه: في مرحلة التوجيه، يمكن تعديل الخطة، ويمكن إضافة متطلبات جديدة و/أو تغيير المتطلبات الحالية أو إزالتها.
• تخطيط التكرار : يهدف هذا التخطيط إلى تحديد أنشطة ومهام المطورين، ولا يشارك فيه العميل. ويتكون تخطيط التكرار من ثلاث مراحل:
  • مرحلة الاستكشاف: في هذه المرحلة، سيتم تحويل المتطلبات إلى مهام مختلفة. تُسجل هذه المهام على بطاقات المهام.
  • مرحلة الالتزام: سيتم إسناد المهام إلى المبرمجين وسيتم تقدير الوقت اللازم لإكمالها.
  • مرحلة التوجيه: يتم تنفيذ المهام ومطابقة النتيجة النهائية مع قصة المستخدم الأصلية.

تهدف لعبة التخطيط إلى توجيه المنتج نحو التسليم. فبدلاً من التنبؤ بالتواريخ الدقيقة لاحتياج المنتج للمخرجات وإنتاجها، وهو أمر يصعب تحقيقه، فإنها تسعى إلى "توجيه المشروع" نحو التسليم باستخدام منهجية مباشرة. ^{[ 2 ]} يُستخدم أسلوب لعبة التخطيط في أطر التطوير، وليس فقط في أنظمة البرمجيات. على سبيل المثال، تستخدمه الفرق في سياق مرونة الأعمال . ^{[ 3 ]}

اختبارات الوحدة هي اختبارات آلية تختبر وظائف أجزاء من الكود (مثل الفئات والأساليب). في منهجية البرمجة القصوى (XP)، تُكتب اختبارات الوحدة قبل كتابة الكود النهائي. يهدف هذا النهج إلى تحفيز المبرمج على التفكير في الظروف التي قد يفشل فيها الكود. تنص منهجية البرمجة القصوى على أن المبرمج قد انتهى من جزء معين من الكود عندما يعجز عن إيجاد أي ظروف أخرى قد يفشل فيها الكود.

تعتمد منهجية التطوير القائمة على الاختبار على المرور السريع بالخطوات التالية، بحيث لا تستغرق كل خطوة أكثر من دقائق معدودة، ويفضل أن تكون أقل من ذلك بكثير. ونظرًا لأن كل قصة مستخدم تتطلب عادةً يومًا أو يومين من العمل، فسيكون من الضروري إجراء عدد كبير جدًا من هذه الدورات لكل قصة.

• كتابة اختبار الوحدة : يقوم المبرمجون بكتابة اختبار بسيط يجب أن يفشل لأن الوظيفة لم يتم تنفيذها بالكامل في كود الإنتاج.
• شاهد فشل الاختبار الجديد: يتحقق المبرمجون من فشل الاختبار بالفعل. قد يبدو هذا مضيعة للوقت، لكن هذه الخطوة بالغة الأهمية لأنها تؤكد صحة اعتقادك بشأن حالة كود الإنتاج. إذا لم يفشل الاختبار، فعلى المبرمجين تحديد ما إذا كان هناك خطأ برمجي في كود الاختبار، أو ما إذا كان كود الإنتاج يدعم الوظائف التي يصفها الاختبار الجديد.
• كتابة الكود: يكتب المبرمجون ما يكفي من كود الإنتاج لكي ينجح الاختبار الجديد.
• تشغيل الاختبار: يتم تنفيذ اختبارات الوحدة للتحقق من أن كود الإنتاج الجديد يجتاز الاختبار الجديد، وأنه لا توجد اختبارات أخرى تفشل.
• إعادة هيكلة الكود : إزالة أي علامات تدل على وجود مشاكل في الكود من كل من كود الإنتاج وكود الاختبار.

للحصول على نسخة أكثر تفصيلاً من العملية المذكورة أعلاه، انظر قواعد العم بوب الثلاث للتطوير القائم على الاختبار. ^{[ 4 ]}

في منهجية البرمجة القصوى (XP)، لا يُقصد بـ"العميل" من يدفع الفاتورة، بل من يستخدم النظام فعلياً. تنصّ هذه المنهجية على ضرورة وجود العميل في متناول اليد دائماً، وأن يكون متاحاً للإجابة على استفساراته. على سبيل المثال، يجب أن يضمّ فريق تطوير نظام الإدارة المالية مسؤولاً مالياً. كما يجب أن يمتلك الفريق جميع المهارات اللازمة لتقديم المنتج البرمجي.

ينبغي على فريق التطوير العمل باستمرار على أحدث إصدار من البرنامج. ونظرًا لاحتمالية وجود نسخ محفوظة محليًا لدى أعضاء الفريق تتضمن تغييرات وتحسينات متنوعة، يُنصح بتحميل نسختهم الحالية إلى مستودع الشفرة كل بضع ساعات، أو عند حدوث انقطاع هام. يساهم التكامل المستمر في تجنب التأخيرات اللاحقة في دورة حياة المشروع، والناجمة عن مشاكل التكامل.

لأن منهج البرمجة القصوى (XP) يدعو إلى برمجة ما هو مطلوب فقط في الوقت الحالي، وتنفيذه بأبسط طريقة ممكنة، فقد يؤدي ذلك أحيانًا إلى تعطل النظام. ومن أعراض ذلك الحاجة إلى صيانة مزدوجة (أو متعددة): حيث تبدأ التغييرات الوظيفية في استلزام تعديلات على نسخ متعددة من نفس الكود (أو كود مشابه). ومن الأعراض الأخرى أن التغييرات في جزء واحد من الكود تؤثر على أجزاء أخرى كثيرة. ويشير منهج البرمجة القصوى إلى أنه عندما يحدث هذا، فإن النظام يطلب منك إعادة هيكلة الكود بتغيير بنيته، مما يجعله أبسط وأكثر عمومية.

يتم تسليم البرنامج عبر إصدارات متكررة من الوظائف الحية، مما يخلق قيمة ملموسة. تساعد هذه الإصدارات الصغيرة العميل على اكتساب الثقة في تقدم المشروع، مما يُسهم في الحفاظ على روح الفريق ككل، حيث يُمكن للعميل الآن تقديم اقتراحاته حول المشروع بناءً على تجربة عملية.

معيار البرمجة هو مجموعة قواعد متفق عليها يلتزم بها فريق التطوير بأكمله طوال فترة المشروع. يحدد هذا المعيار أسلوبًا وتنسيقًا متسقين لشفرة المصدر ، ضمن لغة البرمجة المختارة ، بالإضافة إلى مختلف بنيات وأنماط البرمجة التي ينبغي تجنبها لتقليل احتمالية حدوث الأخطاء. ^{[ 5 ]} قد يكون معيار البرمجة عبارة عن اتفاقيات قياسية تحددها الشركة المصنعة للغة (مثل اتفاقيات البرمجة للغة جافا، التي توصي بها شركة صن)، أو معيارًا مخصصًا يحدده فريق التطوير.

يدعو مؤيدو منهجية البرمجة المتطرفة إلى استخدام كود موثق ذاتيًا إلى أقصى حد ممكن. وهذا يقلل الحاجة إلى التعليقات البرمجية ، التي قد لا تتوافق مع الكود نفسه. ^{[ 6 ]}

ينبغي للمبرمجين اتباع نهج "البساطة هي الأفضل" في تصميم البرمجيات. فعند كتابة أي جزء جديد من الكود، يجب على المبرمج أن يسأل نفسه: "هل هناك طريقة أبسط لإضافة نفس الوظيفة؟". إذا كانت الإجابة بنعم، فيجب اختيار الطريقة الأبسط. كما يُنصح باستخدام إعادة هيكلة الكود لتبسيط الأكواد المعقدة.

استعارة النظام هي قصة يمكن للجميع - العملاء والمبرمجين والمدراء - سردها حول كيفية عمل النظام. إنها مفهوم تسمية للفئات والأساليب يُسهّل على أي عضو في الفريق تخمين وظيفة فئة/أسلوب معين من اسمه فقط. على سبيل المثال، قد يُنشئ نظام مكتبة loan_records(class)عنصرًا borrowers(class)، وإذا تأخر إرجاع هذا العنصر، فقد يُجري عملية "جعل العنصر متأخرًا" عليه catalogue(class). بالنسبة لكل فئة أو عملية، تكون الوظيفة واضحة لجميع أعضاء الفريق.

يقوم المفهوم على مبدأ ألا يعمل المبرمجون أو مطورو البرامج أكثر من 40 ساعة أسبوعيًا، وإذا تطلب الأمر ساعات عمل إضافية في أسبوع ما، فلا ينبغي أن يتضمن الأسبوع التالي ساعات عمل إضافية. ولأن دورات التطوير في منهجية البرمجة القصوى (XP) هي دورات قصيرة تعتمد على التكامل المستمر، ولأن دورات التطوير الكاملة (الإصدار) أكثر تكرارًا، فإن المشاريع في هذه المنهجية لا تخضع لضغوط العمل المعتادة التي تتطلبها المشاريع الأخرى (والتي تستلزم ساعات عمل إضافية).

كما يتضمن هذا المفهوم أن الناس يؤدون أفضل ما لديهم ويكونون أكثر إبداعاً إذا كانوا قد حصلوا على قسط كافٍ من الراحة.

من أهم العوامل المساعدة على تحقيق وتيرة عمل مستدامة هو دمج التعليمات البرمجية بشكل متكرر، وضمان جودة عالية وقابلية تنفيذ التعليمات البرمجية واختبارها بشكل كامل. يُعزز أسلوب العمل القائم على إعادة هيكلة التعليمات البرمجية باستمرار عقول أعضاء الفريق المتيقظة والنشطة. كما يُحفز أسلوب العمل التعاوني المكثف داخل الفريق الحاجة إلى الراحة والاستجمام خلال عطلات نهاية الأسبوع.

كما أن البرامج والبيئات التي تم اختبارها جيدًا، والمتكاملة باستمرار، والتي يتم نشرها بشكل متكرر، تقلل من تكرار مشاكل الإنتاج غير المتوقعة وانقطاعات الخدمة، وما يرتبط بها من عمل ليلي وعطلات نهاية الأسبوع.