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

يجادل أنصار منهجية البرمجة القصوى (XP) بأن المنتج الوحيد المهم حقًا في عملية تطوير النظام هو الكود - أي تعليمات البرمجيات التي يستطيع الحاسوب فهمها. فبدون الكود، لا يوجد منتج قابل للاستخدام.

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

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

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

شُجِّعَ في البداية على إجراء اختبارات التكامل على مستوى النظام كنشاط يومي يُنفَّذ في نهاية اليوم للكشف المبكر عن الواجهات غير المتوافقة. ومع ذلك، فقد خُفِّضَت وتيرة إجراء اختبارات التكامل على مستوى النظام إلى مرة واحدة أسبوعيًا أو أقل، وذلك تبعًا لاستقرار الواجهات العامة في النظام. ^{[ 11 ]}

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

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

Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the "You aren't gonna need it" (YAGNI) approach.^[12] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team.

Within extreme programming, feedback relates to different dimensions of the system development:

• Feedback from the system: by writing unit tests,^[5] or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
• Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
• Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

ترتبط التغذية الراجعة ارتباطًا وثيقًا بالتواصل والبساطة. يُمكن الإبلاغ عن عيوب النظام بسهولة من خلال كتابة اختبار وحدة يُثبت أن جزءًا معينًا من الكود سيتعطل. تُخبر التغذية الراجعة المباشرة من النظام المبرمجين بإعادة كتابة هذا الجزء. يستطيع العميل اختبار النظام دوريًا وفقًا للمتطلبات الوظيفية، والمعروفة باسم قصص المستخدم . ^{[ 5 ]} وكما قال كينت بيك : "التفاؤل مخاطرة مهنية في البرمجة، والتغذية الراجعة هي العلاج." ^{[ 13 ]}

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

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

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

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

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

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

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

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