البرمجة القصوى (بالإنكليزية Extreme programming) هي إحدى منهجيات تطوير البرمجيات وهدفها تحسين جودة البرمجيات وتجاوبها للتغير في متطلبات الزبون. كونها واحدة من أساليب أجايل لتطوير البرمجيات، فهي تروج لإصدارات متكررة في دورات تطوير قصيرة من أجل تحسين الإنتاجية.
البرمجة القصوى تعدّ نسخة معدلة عن نموذج التسليم التدريجي تعتمد على الكثير من المفاهيم مثل: تطوير أجزاء صغيرة جدا من النظام ومشاركة الزبون في كل اجرائات التطوير وتحسين الشيفرة البرمجية بشكل دائم.[1][2][3][2][3][4][5]
التاريخ
تم إنشاء البرمجة القصوى من قبل كينت بيك أثناء عمله على (C3) مشروع الرواتب كرايسلر نظام التعويض الشامل. حيث أصبح بيك رئيس المشروع C3 في مارس 1996 وبدأ لتحسين منهجيةالتطوير المستخدمة في المشروع، وكتب كتابا عن منهجية البرمجة القصوى (في أكتوبر 1999، وسماه البرمجة المتطرفة).[5] وألغت كرايسلر المشروع C3 في فبراير 2000، بعد سبع سنوات، عندما فازت شركة دايملر بنز.[6]
على الرغم من أن البرمجة القصوى نفسها هي جديدة نسبيا، وكانت العديد من الممارسات في جميع أنحاءالعالم لبعض الوقت. ويأخذ «أفضل الممارسات» على سبيل المثال، تم استخدام «ممارسة اختبار أول تطويروتخطيطوالاختبارات قبل كل-زيادة صغيرة» في وقت مبكر من ناسا مشروع الزئبق، في 1960s في وقت مبكر (Larman 2003). لتقصير الوقت اللازم لتطوير الكلي، وقد وضعت بعض الوثائق اختبار رسمي (مثل لاختبار القبول) بالتوازي (أو قبل فترة وجيزة)حتى يكون البرنامج جاهز للاختبار. ويمكن لاختبار مجموع ناسا كتابة إجراءات الاختبار، استنادا إلى الشروط الشكلية وحدود منطقية، قبل أن يُكْتَب البرنامج على الأجهزة. في XP، يؤخذ هذا المفهوم على مستوى الموقع من خلال كتابة اختبارات مؤتمتة (ربما داخل وحدات البرمجيات) التي تحقق من صحة العملية حتى أجزاء صغيرة من برنامج الترميز، وليس فقط اختبار الميزات الكبيرة.
الأصل
يرجع تطوير البرمجيات في 1990 من قبل اثنين من التأثيرات الرئيسية:
2_ خارجيا، أكد انتشار الإنترنت وازدهار دوت كوم السرعة إلى السوق ونمو الشركة والعوامل التنافسية في قطاع الأعمال. بسرعة طالبت المتطلبات المتغيرة أقصر دورات حياة المنتج، وكثيرا ما كانت متوافقة مع الأساليب التقليدية لتطوير البرمجيات.
وقد بدأت كرايسلر نظام التعويض الشامل (C3) من أجل تحديد أفضل طريقة لاستخدام تقنيات الكائن، وذلك باستخدام نظم كشوف المرتبات في كرايسلر كموضوع للبحث، مع من Smalltalk كلغة والأحجار الكريمة وطبقة الوصول إلى البيانات. أحضروا في كينت بيك، لمن Smalltalk طبيب بارز، للقيام بضبط الأداء على النظام، ولكن توسع دوره كما أشار إلى العديد من المشاكل التي كانت تواجهها مع عملية التنمية. وقد انتهز هذه الفرصة لاقتراح وتنفيذ بعض التغييرات في الممارسات على أساس عمله مع معاونه المتكرر، وارد كانينغهام. يصف بيك المفهوم المبكر للسائل:[5]
أول مرة طلب مني أن قيادة الفريق، وطلب منهم أن تفعل قليلا من الأشياء اعتقدت كانت معقولة، مثل اختبار والاستعراضات. للمرة الثانية كان هناك الكثير على المحك. فكرت: «اللعنة على طوربيدات، على الأقل هذا سيجعل مادة جيدة،» وطلب من فريق لكرنك حتى جميع المقابض إلى 10 على الأشياء اعتقدت كانت ضرورية وترك كل شيء آخر.[7]
ودعت بيك رون جيفريز للمشروع للمساعدة في تطوير وصقل هذه الأساليب. جيفريز تصرف بعد ذلك كمدرب لغرس الممارسات العادات في الفريق C3.
تم نشر المعلومات حول مبادئ وممارسات وراء XP إلى العالم الأوسع من خلال مناقشات حول ويكي الأصلي. أدت مختلف المساهمين مناقشتها وتوسع فيها الأفكار، وبعض المنهجيات العرضية (تطوير البرمجيات رشيقة). أيضا، تم شرح المفاهيم XP، لعدة سنوات، وذلك باستخدام خريطة النظام الإلكتروني على موقع XP في حوالي عام 1999.
التعديل الأخير تم بيك سلسلة من الكتب حول XP، بدءا بنفس البرمجة المتطرفة، ونشر أفكاره إلى جمهور أكبر من ذلك بكثيرعام 1999. ذهب الكتاب في سلسلة من خلال الجوانب المختلفة حضور XP وممارساته. تضمنت سلسلة الكتاب الذي كان ينتقد الممارسات.
الوضع الحالي
البرمجة القصوى ولدت اهتماما كبيرا بين مجتمعات البرامج في أواخر 1990 و 2000 في وقت مبكر، ورؤية تبني في عدد من بيئات مختلفة جذريا عن أصولها.
الانضباط العالية المطلوبة من قبل الممارسات الأصلية وغالبا ما يذهب على جانب الطريق، مما تسبب في بعض من هذه الممارسات، مثل تلك التي يعتقد انها جامدة جدا، إلى أن إهمال أو تخفيضها، أو حتى لم ينته من كتابتها، على المواقع الفردية. على سبيل المثال، يمكن أن تتغير ممارسة نهاية اليوم اختبارات التكامل لمشروع معين لجدول نهاية الأسبوع، أو تخفيض ببساطة لمواعيد متفق عليها بصورة متبادلة. هذا جدول زمني أكثر استرخاء يمكن أن تجنب الناس شعور هرع لتوليد بذرة مصطنعة فقط لتمرير اختبار نهاية اليوم. جدول زمني أقل جامدة يسمح، بدلا من ذلك، بالنسبة لبعض الميزات المعقدة لتكون أكثر تطورا على مدى عدة أيام. ومع ذلك، فإن بعض مستوى اختبار التكامل الدوري يمكن الكشف عن مجموعة من الأشخاص الذين يعملون في غير متوافقة، والجهود المبذولة الظل قبل الكثير من العمل واستثمرت في، الاتجاهات الخاطئة متباينة.
وفي الوقت نفسه، لم يقف ممارسات التنمية بل ما زال XP يتطور، واستيعاب المزيد من الدروس من تجارب في هذا المجال، لاستخدام غيرها من الممارسات. في الطبعة الثانية (نوفمبر 2004)من البرمجة المتطرفة شرح بعد خمس سنوات من الطبعة الأولى، وأضاف بيك المزيد من القيم والممارسات وفرق بين الممارسات الأولية، ونتيجته الطبيعية.
المفاهيم
الاهداف
البرمجة المتطرفة وأوضح وصف البرمجة المتطرفة كتخصص تطوير البرامج التي تنظم الناس لإنتاجبرامج ذات جودة أعلى وأكثر إنتاجية.
و محاولات للحد من تكلفة التغييرات في متطلبات من خلال وجود عدة دورات تطوير قصيرة، بدلا من واحدة طويلة. في هذه العقيدة، والتغييرات هي الجانب الطبيعي، الذي لا مفر منه ومرغوب فيه من مشاريع البرمجيات التنمية، ويجب التخطيط له، بدلا من محاولة تحديد مجموعة مستقرة من المتطلبات.
وتقدم البرمجة المتطرفة أيضا عددا من القيم الأساسيةوالمبادئ والممارسات على الجزء العلوي من إطار برمجة رشيقة.
الانشطة
يصف XP أربعة أنشطة الأساسية التي يتم تنفيذها في إطار عملية تطوير البرمجيات: الترميز، والاختبار، والاستماع، والتصميم. يتم وصف كل من هذه الأنشطة أدناه.
الترميز
جادل دعاة XP أن المنتج فقط المهم حقا من عملية تطويرالنظام هو الترميز - تعليمات البرامج التي لا يمكن للكمبيوتر تفسيرهادون رمز.
ويمكن أيضا أن تستخدم الترميز لمعرفة الحل الأنسب. يمكن للترميز أيضا أن يساعد على تواصل الأفكار حول مشاكل البرمجة.والمبرمج يتعامل مع مشكلة البرمجة المعقدة، أو تجد صعوبة في شرح حل لزميل المبرمجين، قد الكود بطريقة مبسطة واستخدام رمز لإثبات ما يعني انه أو انها. رمز، يقول أنصار هذا الموقف، هو دائما واضحة وموجزة، ولا يمكن أن تفسر في أكثر من طريقة واحدة. يمكن للمبرمجين الآخرين إعطاء ردود فعل على هذا الرمز من خلال ترميز أيضا أفكارهم.
الاختبار
نهج البرمجة المتطرفة هو أنه إذا كان اختبار القليل يمكن القضاء على بعض العيوب، والكثير من الاختبارات يمكن القضاء على الكثير من العيوب.
وحدة الاختبارات تحدد ما إذا كانت ميزة معينة تعمل على النحو المنشود. والمبرمج يكتب عن العديد من التجارب الآلية لأنه يمكن أن أفكر فيه ل«كسر» رمز.إذا تم الترميز بالكامل إذا تشغيل جميع الاختبارات سيتم بنجاح، يتم اختبار كل قطعة من التعليمات البرمجية التي تم كتابتها قبل أن ينتقل إلى ميزة المقبله واختبارات القبول التحقق من أن الشروط التي يفهمها المبرمجين تلبي متطلبات العملاء الفعلية.
وقد شجع على نطاق المنظومة اختبار التكامل، في البداية، كنشاط يومي نهاية اليوم، للكشف المبكر عن واجهات غير متوافقة، لإعادة قبل تباينت قطاعات منفصلة على نطاق واسع من وظائف متماسكة. ومع ذلك، فقد تم تخفيض اختبار التكامل على نطاق المنظومة، لأسبوعيا أو أقل في كثير من الأحيان، وهذا يتوقف على استقرار واجهات الشاملة في النظام
الاستماع
يجب على المبرمجين الاستماع إلى ما يحتاجه العملاء للنظام للقيام به، وما هو المطلوب أي «منطق الأعمال». يجب أن نفهم هذه الاحتياجات جيدا بما فيه الكفاية لإعطاء ملاحظات العملاء حول الجوانب التقنية لكيفية حل المشكلة، أو لا يمكن حلها. وكذلك تناول الاتصال بين العميلوالمبرمج في لعبة التخطيط.
التصميم
بطبيعة الحال يمكن القول أن تطوير النظام لا يحتاج إلى أكثر من الترميز، واختبار والاستماع. إذا يتم تنفيذ تلك الأنشطة بشكل جيد، ويجب أن تكون النتيجة دائمان النظام يعمل. في الواقع، هذا لن يعمل. يمكن للمرء أن قطعنا شوطا طويلا من دون تصميم ولكن في وقت معين واحد سوف تتعثر. يصبح نظام معقد للغاية وتبعيات داخل وقف النظام ليكون واضحا. يمكن للمرء تجنب ذلك عن طريق إنشاء هيكل التصميم الذي ينظم المنطق في النظام. والتصميم الجيد تجنب الكثير من تبعيات داخل النظام؛ وهذا يعني أن تغيير جزء واحد من النظام لن يؤثر على أجزاء أخرى من النظام
القيم
البرمجة المتطرفة اعترفت في البداية بأربع قيم في عام 1999: الاتصالات، والبساطة، وردود الفعل، والشجاعة. والاحترام. وصفت تلك القيم خمسة أدناه.
الاتصال
يتطلب بناء نظم البرمجيات تواصل متطلبات النظام لمطوري النظام. في منهجيات تطوير البرمجيات الرسمية، ويتم إنجاز هذه المهمة من خلال الوثائق. يمكن الاطلاع على تقنيات البرمجة المتطرفة وسائل لبناء بسرعة ونشر المعرفة المؤسسية بين أعضاء فريق التطوير. والهدف من ذلك هو إعطاء جميع المطورين وجهة نظر مشتركة للنظام الذي يطابق وجهة نظر من قبل المستخدمين للنظام. تحقيقا لهذه الغاية، والبرمجة المتطرفة تفضل تصاميم بسيطة والاستعارات المشتركة، والتعاون من المستخدمين والمبرمجين، والتواصل اللفظي المتكرر، وردود الفعل.
البساطة
البرمجة المتطرفة تشجع بدءا من أبسط الحلول. ويمكن بعد ذلك إضافة وظائف إضافية في وقت لاحق. الفرق بين هذا النهج والمزيد من أساليب تطويرالنظام التقليدي هو التركيز على التصميموالترميز لتلبية احتياجات اليوم بدلا من تلك التي غدا، الأسبوع المقبل أو الشهر المقبل. تتلخص هذه في بعض الأحيان يصل باسم «أنت لست ستعمل في حاجة إليها» [8] أنصار XP يعترف العيب أن هذا يمكن أن يترتب عليه في بعض الأحيان المزيد من الجهد غدا لتغيير النظام؛ ادعائهم هو أن هذا هو أكثر من كاف للتعويض عن ميزة عدم الاستثمار في المتطلبات المستقبلية المحتملة التي قد تتغير قبل أن تصبح ذات الصلة. بالترميز والتصميم لمتطلبات مستقبلية غير مؤكدة ينطوي على مخاطر الموارد الإنفاق على شيء قد لا تكون هناك حاجة اليه، في حين ربما تأخير الميزات الحاسمة. تتعلق ب «الاتصالات» تكون قيمة، يجب أن يكون بساطة في التصميم والترميز وتحسين نوعية الاتصالات. وهو تصميم بسيط مع رمز بسيط جدا يمكن فهمه بسهولة من قبل معظم المبرمجين في الفريق.
ردود الافعال
تصل ردود الفعل على الأبعاد المختلفة لتطوير النظام:
1-ردود الفعل من النظام: من خلال كتابة الاختبارات وحدة[5]، أو تشغيل اختبارات التكامل الدورية، والمبرمجين لديهم ردود فعل مباشرة من ولاية النظام بعد تنفيذ التغييرات.تتم كتابة الاختبارات الوظيفية (ويعرف أيضا باسم اختبارات القبول) من قبل العميل.
2- ردود الفعل من العملاء: أنها سوف تحصل على ردود فعل ملموسة حول الوضع الحالي لنظام الحكم القائم فيها. ومن المقرر هذا الاستعراض مرة واحدة في كل يومين أو ثلاثة أسابيع حتى يمكن للعميل توجيه متطلباته بسهولة .
3-ردود الفعل من الفريق: عندما يأتي الزبائن مع المتطلبات[5] الجديدة في لعبة تخطيط الفريق يعطي مباشرة تقدير الوقت الذي سيستغرق لتنفيذها، وردود الفعل ترتبط ارتباطا وثيقا بالاتصالات والبساطة. يتم إبلاغ العيوب في النظام بسهولة من خلال كتابة اختبار وحدة يثبت أن قطعة معينة من التعليمات البرمجية وردود الفعل المباشر من النظام يقول المبرمجين لإعادة رمز هذا الجزء. والعميل قادر على اختبار النظام بشكل دوري وفقا لمتطلبات وظيفية، والمعروفة«باسم قصص المستخدم» على حد تعبير كينت بيك، «التفاؤل هو الخطر المهني للبرمجة وردود الفعل هو العلاج».[9]
الشجاعة
هناك عدة ممارسات تجسد الشجاعة. واحد هو وصية التصميم دائما ورمز لهذا اليوم وليس غدا. هذا هو محاولة لتجنب التورط في التصميم وتتطلب الكثير من الجهد لتنفيذ أي شيء آخر. الشجاعة يتيح للمطورين الشعور بالراحة مع إعادة بيع ديون رمز عند الضرورة. وهذا يعني إعادة النظر في النظام القائم وتعديله بحيث يتناسب مع التغيرات المستقبلية ويمكن تنفيذها بسهولة أكبر. مثال آخر من الشجاعة: هو معرفة متى لرمي كود بعيدا: الشجاعة لإزالة شفرة المصدر أن عفا عليه الزمن، ومهما بذل الكثير من الجهد تم استخدامه لإنشاء هذا شفرة المصدر. أيضا، والشجاعة تعني استمرار: قد يكون المبرمج عالقا في مشكلة معقدة لمدة يوم كامل، ثم حل المشكلة بسرعة في اليوم التالي، وهنا يتميز المبرمج بالشجاعة .
الاحترام
وتشمل قيمة الاحترام احترام الآخرين واحترام الذات. يجب على المبرمجين عدم ارتكاب الاخطاء في التغييرات المطلوبة من العميل، التي تؤدي إلى فشل وحدة الاختبارات الحالية، أو إلى تأخير العمل مع الفريق . وأعضاء الفريق يكون بينهم احترام عملهم من خلال السعي دائما للحصول على جودة عالية، والسعي للحصول على أفضل تصميم لحليكون في متناول اليد .اعتماد القيم الأربع السابقة ويؤدي إلى احترام المكتسبة من الآخرين في الفريق. لا أحد في الفريق يجب أن يشعر غير مقدر ولا انه تم تجاهله . وهذا يضمن مستوى عال من التحفيز وتشجيع الولاء تجاه الفريق ونحو هدف المشروع. هذه القيمة تعتمد كثيرا على القيم الأخرى، وموجهة إلى حد كبير نحو شخص في الفريق.
القواعد
تم نشر النسخة الأولى من قواعد لXP في 1999[10] من دون ويلز على موقع XP. يتم إعطاء 29 قواعد في فئات تخطيط وإدارة وتصميموالترميز، والاختبار. ويطلق على تخطيط وإدارة وتصميم بشكل صريح لمواجهة مزاعم بأن XP لا يدعم تلك الأنشطة.واقترح إصدار آخر من القواعد XP كين أوير[11] في XP / رشيق الكون عام 2003. ورأى وعرف XP بقواعدها، لا ممارساته (التي تخضع لمزيد من التباين والغموض). عرف فئتين: «قواعد الاشتباك» التي تملي البيئة لتطوير البرمجيات يمكن أن تتم على نحو فعال، و«قواعد اللعب» التي تحدد الأنشطة وقواعد دقيقة تلو الدقيقة في إطار قواعد الاشتباك.
المبادئ
وتستند هذه المبادئ التي تشكل أساس XP على القيم. وتهدف إلى تعزيز القرارات في مشروع تطوير النظام. والغرض من هذه المبادئ أن تكون أكثر واقعية من القيم وترجمتها بسهولة إلى توجيهات في الواقع العملي.
الممارسات
البرمجة القصوى ترى ردود الفعل، أكثر فائدة إذا تم القيام به في كثير من الأحيان وعلى الفور. ويؤكد أن تأخير الحد الأدنى بين العمل وردود الفعل عنصر بالغ الأهمية في التعلم وإجراء تغييرات. خلافا لأساليب تطوير النظام التقليدية، والاتصال مع العميل يحدث في التكرار أكثر تواترا. العميل لديه فكرة واضحة عن النظام الذي طور الإعداد، ويمكن أن تعطي ردود فعل وتوجيه التنمية حسب الحاجة. مع ردود الفعل المتكرر من عملاء، وسوف تلاحظ قرار تصميم الخاطئ الذي أدلى به المطور وتصحيح بسرعة، قبل المطور تنفق الكثير من الوقت تنفيذها.وتساهم وحدة الاختبارات لمبدأ ردود الفعل السريعة. عند كتابة التعليمات البرمجية، وتشغيل اختبار وحدة توفر ردود الفعل المباشر لكيفية رد فعل النظام على التغييرات التي تم إجراؤها. ويشمل هذا العمل ليس فقط على وحدة الاختبارات التي تختبر رمز المطور، ولكن تعمل في إضافة جميع الاختبارات وحدة ضد كل البرامج، وذلك باستخدام عملية الآلية التي يمكن أن تبدأ من قبل قيادة واحدة. بهذه الطريقة، إذا كانت تغييرات المطور تسبب فشلا في بعض جزء آخر من النظام أن المطور يعرف القليل أو لا شيء، فإن الآلية نجاح كل وحدة اختبار والكشف عن الفشل فورا، وتنبيه مطور على عدم التوافق على تغيير رأيه مع أجزاء أخرى من النظام، وضرورة إزالة أو تعديل تغيير رأيه. تحت ممارسات التنمية التقليدية، وعدم وجود آلية وشامله لنجاح وحدة الاختبار يعني أن مثل هذا التغيير رمز، يفترض مؤذية من قبل المطور، قد تركت في المكان، والتي تظهر فقط أثناء اختبار التكامل - أو ما هو أسوأ، فقط في الإنتاج؛ وتحديد أي رمز التغيير سبب المشكلة، من بين جميع التغييرات التي أجراها كل المطورين خلال أسابيع أو حتى أشهر السابقة لاختبار التكامل، كان مهمة هائلة.
المراجع
^"Human Centred Technology Workshop 2005", 2005, PDF webpage: Informatics-UK-report-cdrp585.
^ اب"Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns.
