البرمجة المتطرفة (XP)(بالانجليزية Extreme programming) هو منهجية تطوير البرمجيات الذي يهدف إلى تحسين نوعية البرامج والاستجابة لمتطلبات العملاء المتغيرة. كنوع من تطوير البرمجيات الرشيقة[1][2][3]، التي تنادي "البيانات"المتكررة في دورات تطوير قصيرة، الذي يهدف إلى تحسين الإنتاجية وإدخال نقاط التفتيش الى متطلبات العملاء الجديدة التي يمكن اعتمادها.وغيرها من عناصر البرمجة المتطرفة تشمل: البرمجة في أزواج أو القيام مراجعة التعليمات البرمجية واسعة النطاق، واختبار وحدة من كل رمز، ومن الميزات :ان تكون هناك حاجة إليها في الواقع، وهيكل إداري موحد يمتاز بالبساطة والوضوح في التعليمات البرمجية، وان نتوقع تغييرات في متطلبات الزبون كلما مر الوقت ويفهم المشكلة بشكل أفضل[4][5][6]، والاتصال المتكرر مع العميل وبين المبرمجين.وهي منهجية تأخذ اسمها من فكرةهندسة البرمجيات الرشيقة إلى "المتطرفة ". وكمثال على ذلك، تعتبر نقل الكود ممارسة مفيدة؛ نقل إلى رمز الموقع يمكن مراجعتها بشكل مستمر[7]، أي ممارسة البرمجة الزوج.وقد لاحظ النقاد عدة عيوب محتملة، بما في ذلك مشاكل مع متطلبات غير مستقرة، لا تنازلات موثقة من الصراعات المستخدم، وعدم وجود مواصفات التصميم العام أو وثيقة.

التاريخ عدل

تم إنشاء البرمجة المتطرفة من قبل كينت بيك أثناء عمله على (C3) مشروع الرواتب كرايسلر نظام التعويض الشامل. حيث أصبح بيك رئيس المشروع C3 في مارس 1996 وبدأ لتحسين منهجية التطوير المستخدمة في المشروع، وكتب كتابا عن منهجيةالبرمجة المتطرفة (في أكتوبر 1999، وسماه البرمجة المتطرفة)[8]. و ألغت كرايسلر المشروع C3 في فبراير 2000، بعد سبع سنوات، عندما فازت شركة دايملر بنز. [9]

على الرغم من أن البرمجة المتطرفة نفسها هي جديدة نسبيا، وكانت العديد من الممارسات في جميع أنحاءالعالم لبعض الوقت. ويأخذ "أفضل الممارسات" على سبيل المثال، تم استخدام "ممارسة اختبار أول تطوير وتخطيط و الاختبارات قبل كل-زيادة صغيرة" في وقت مبكر من ناسا مشروع الزئبق، في 1960s في وقت مبكر (Larman 2003). لتقصير الوقت اللازم لتطوير الكلي، وقد وضعت بعض الوثائق اختبار رسمي (مثل لاختبار القبول) بالتوازي (أو قبل فترة وجيزة)حتى يكون البرنامج جاهز للاختبار. ويمكن لاختبار مجموع ناسا كتابة إجراءات الاختبار، استنادا إلى الشروط الشكلية وحدود منطقية، قبل أن يتم كتابة البرنامج على الأجهزة. في XP، يؤخذ هذا المفهوم على مستوى الموقع من خلال كتابة اختبارات مؤتمتة (ربما داخل وحدات البرمجيات) التي تحقق من صحة العملية حتى أجزاء صغيرة من برنامج الترميز، وليس فقط اختبار الميزات الكبيرة.

الاصول عدل

وقد شكل تطوير البرمجيات في 1990s من قبل اثنين من التأثيرات الرئيسية:1- داخليا:وهي البرمجة كائنية التوجه واستبدال البرمجة الإجرائية مثل نموذج البرمجة التي يفضلها البعض في الصناعة؛2_ خارجيا، أكد انتشار الإنترنت وازدهار دوت كوم السرعة إلى السوق ونمو الشركة والعوامل التنافسية في قطاع الأعمال. بسرعة طالبت المتطلبات المتغيرة أقصر دورات حياة المنتج، وكثيرا ما كانت متوافقة مع الأساليب التقليدية لتطوير البرمجيات. وقد بدأت كرايسلر نظام التعويض الشامل (C3) من أجل تحديد أفضل طريقة لاستخدام تقنيات الكائن، وذلك باستخدام نظم كشوف المرتبات في كرايسلر كموضوع للبحث، مع من Smalltalk كلغة والأحجار الكريمة وطبقة الوصول إلى البيانات. أحضروا في كينت بيك، لمن Smalltalk طبيب بارز، للقيام بضبط الأداء على النظام، ولكن توسع دوره كما أشار إلى العديد من المشاكل التي كانت تواجهها مع عملية التنمية. وقد انتهز هذه الفرصة لاقتراح وتنفيذ بعض التغييرات في الممارسات على أساس عمله مع معاونه المتكرر، وارد كانينغهام. يصف بيك المفهوم المبكر للسائل:[10] أول مرة طلب مني أن قيادة الفريق، وطلب منهم أن تفعل قليلا من الأشياء اعتقدت كانت معقولة، مثل اختبار والاستعراضات. للمرة الثانية كان هناك الكثير على المحك. فكرت: "اللعنة على طوربيدات، على الأقل هذا سيجعل مادة جيدة،" [و] طلب من فريق لكرنك حتى جميع المقابض إلى 10 على الأشياء اعتقدت كانت ضرورية وترك كل شيء آخر.[11] ودعت بيك رون جيفريز للمشروع للمساعدة في تطوير وصقل هذه الأساليب. جيفريز تصرف بعد ذلك كمدرب لغرس الممارسات العادات في الفريق C3.

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

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

الوضع الحالي عدل

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

المفاهيم عدل

الاهداف عدل

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

الانشطة عدل

يصف XP أربعة أنشطة الأساسية التي يتم تنفيذها في إطار عملية تطوير البرمجيات: الترميز، والاختبار، والاستماع، والتصميم. يتم وصف كل من هذه الأنشطة أدناه.

الترميز عدل

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

الاختبار عدل

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

الاستماع عدل

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

التصميم عدل

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

القيم عدل

البرمجة المتطرفة اعترفت في البداية بأربع قيم في عام 1999: الاتصالات، والبساطة، وردود الفعل، والشجاعة. والاحترام، . وصفت تلك القيم خمسة أدناه.

الاتصال عدل

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

البساطه عدل

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

ردود الافعال عدل

تصل ردود الفعل على الأبعاد المختلفة لتطوير النظام: 1-ردود الفعل من النظام: من خلال كتابة الاختبارات وحدة[13]، أو تشغيل اختبارات التكامل الدورية، والمبرمجين لديهم ردود فعل مباشرة من ولاية النظام بعد تنفيذ التغييرات.تتم كتابة الاختبارات الوظيفية (ويعرف أيضا باسم اختبارات القبول) من قبل العميل . 2- ردود الفعل من العملاء: أنها سوف تحصل على ردود فعل ملموسة حول الوضع الحالي لنظام الحكم القائم فيها. ومن المقرر هذا الاستعراض مرة واحدة في كل يومين أو ثلاثة أسابيع حتى يمكن للعميل توجيه متطلباته بسهولة . 3-ردود الفعل من الفريق: عندما يأتي الزبائن مع المتطلبات[14] الجديدة في لعبة تخطيط الفريق يعطي مباشرة تقدير الوقت الذي سيستغرق لتنفيذها,وردود الفعل ترتبط ارتباطا وثيقا بالاتصالات والبساطة. يتم إبلاغ العيوب في النظام بسهولة من خلال كتابة اختبار وحدة يثبت أن قطعة معينة من التعليمات البرمجيةو ردود الفعل المباشر من النظام يقول المبرمجين لإعادة رمز هذا الجزء. والعميل قادر على اختبار النظام بشكل دوري وفقا لمتطلبات وظيفية، والمعروفة" باسم قصص المستخدم" على حد تعبير كينت بيك، "التفاؤل هو الخطر المهني للبرمجةوردود الفعل هو العلاج".[15]

الشجاعه عدل

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

الاحترام عدل

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

القواعد عدل

تم نشر النسخة الأولى من قواعد لXP في 1999[16] من دون ويلز على موقع XP. يتم إعطاء 29 قواعد في فئات تخطيط وإدارة وتصميم والترميز، والاختبار. ويطلق على تخطيط وإدارة وتصميم بشكل صريح لمواجهة مزاعم بأن XP لا يدعم تلك الأنشطة.واقترح إصدار آخر من القواعد XP كين أوير[17] في XP / رشيق الكون عام 2003. ورأى وعرف XP بقواعدها، لا ممارساته (التي تخضع لمزيد من التباين والغموض). عرف فئتين: "قواعد الاشتباك" التي تملي البيئة لتطوير البرمجيات يمكن أن تتم على نحو فعال، و "قواعد اللعب" التي تحدد الأنشطة وقواعد دقيقة تلو الدقيقة في إطار قواعد الاشتباك.

المبادئ عدل

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

الممارسات عدل

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

المراجع عدل

  1. ^ "Human Centred Technology Workshop 2005", 2005, PDF webpage: Informatics-UK-report-cdrp585.
  2. ^ "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns.
  3. ^ "Extreme Programming" USFCA-edu-601-lecture.
  4. ^ "Design Patterns and Refactoring", University of Pennsylvania, 2003, webpage: UPenn-Lectures-design-patterns.
  5. ^ "Extreme Programming" USFCA-edu-601-lecture.
  6. ^ "Manifesto for Agile Software Development", Agile Alliance, 2001, webpage: Manifesto-for-Agile-Software-Dev
  7. ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
  8. ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
  9. ^ Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP. Apress. ISBN 1-59059-096-1.
  10. ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
  11. ^ "Interview with Kent Beck and Martin Fowler". informit.com.
  12. ^ "Everyone's a Programmer" by Clair Tristram. Technology Review, November 2003. p. 39.
  13. ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
  14. ^ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
  15. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. ISBN 978-0-321-27865-4.
  16. ^ Extreme Programming Rules". extremeprogramming.org.
  17. ^ Ken Auer