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

الموسوعة الحرة

حلقات التخطيط والتغذية الراجعة في البرمجة المتطرفة
جزء من سلسلة عن
تطوير البرمجيات
الأنشطة الأساسية
النماذج والأنماط
المنهجيات والأطر
دعم التخصصات
الممارسات
أدوات
المعايير وهيئات المعرفة
القواميس
الخطوط العريضة
  • ف
  • ت
  • هـ

البرمجة المتطرفة ( XP ) هي منهجية تطوير برمجيات تهدف إلى تحسين جودة البرمجيات واستجابتها لمتطلبات العملاء المتغيرة. كنوع من تطوير البرمجيات الرشيقة ، [1] [2] [3] فهي تدعو إلى إصدارات متكررة في دورات تطوير قصيرة، بهدف تحسين الإنتاجية وإدخال نقاط تفتيش يمكن من خلالها تبني متطلبات العملاء الجديدة.

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

تاريخ

طور كينت بيك البرمجة المتطرفة أثناء عمله في مشروع رواتب نظام التعويض الشامل لكرايسلر (C3) . [5] أصبح بيك قائد مشروع C3 في مارس 1996. بدأ في تحسين منهجية التطوير المستخدمة في المشروع وكتب كتابًا عن المنهجية ( شرح البرمجة المتطرفة ، نُشر في أكتوبر 1999). [5] ألغت كرايسلر مشروع C3 في فبراير 2000، بعد سبع سنوات، عندما استحوذت شركة دايملر بنز على الشركة. [6] كان وارد كانينجهام مؤثرًا رئيسيًا آخر على XP.

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

الأصول

كان هناك تأثيران رئيسيان أثرا على تطوير البرمجيات في تسعينيات القرن العشرين:

تطلبت المتطلبات المتغيرة بسرعة دورات حياة أقصر للمنتج ، وكثيراً ما تعارضت مع الأساليب التقليدية لتطوير البرمجيات.

بدأ نظام التعويض الشامل لشركة كرايسلر (C3) من أجل تحديد أفضل طريقة لاستخدام تقنيات الكائنات، باستخدام أنظمة الرواتب في كرايسلر كهدف للبحث، مع Smalltalk كلغة و GemStone كطبقة وصول إلى البيانات . جلبت كرايسلر كينت بيك ، [5] وهو ممارس بارز في Smalltalk، للقيام بضبط الأداء على النظام، لكن دوره توسع حيث لاحظ العديد من المشاكل في عملية التطوير. اغتنم هذه الفرصة لاقتراح وتنفيذ بعض التغييرات في ممارسات التطوير - بناءً على عمله مع متعاونه المتكرر، وارد كانينجهام . يصف بيك المفهوم المبكر للطرق: [8]

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

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

تم نشر معلومات حول المبادئ والممارسات وراء XP إلى العالم الأوسع من خلال المناقشات على ويكي الأصلي، WikiWikiWeb الخاص بـ Cunningham . ناقش العديد من المساهمين الأفكار ووسعوها، ونتج عن ذلك بعض منهجيات الإنتاج الفرعية (انظر تطوير البرمجيات الرشيقة ). كما تم شرح مفاهيم XP [ من قبل من؟ ] ، لعدة سنوات، باستخدام خريطة نظام النص التشعبي على موقع XP على الويب على http://www.extremeprogramming.org حوالي عام  1999 .

قام بيك بتحرير سلسلة من الكتب حول XP، بدءًا من كتابه Extreme Programming Explained (1999، ISBN  0-201-61641-6 )، حيث قام بنشر أفكاره لجمهور أكبر بكثير. تناول المؤلفون في السلسلة جوانب مختلفة من حضور XP وممارساته. تضمنت السلسلة كتابًا ينتقد الممارسات.

الحالة الحالية

لقد أثار نظام التشغيل XP اهتمامًا كبيرًا بين مجتمعات البرمجيات في أواخر التسعينيات وأوائل العقد الأول من القرن الحادي والعشرين، حيث تم اعتماده في عدد من البيئات التي تختلف اختلافًا جذريًا عن أصوله.

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

وفي الوقت نفسه، لم تتوقف ممارسات التطوير الرشيقة الأخرى، واعتبارًا من عام 2019، تواصل XP التطور، واستيعاب المزيد من الدروس من الخبرات في هذا المجال، لاستخدام ممارسات أخرى. في الإصدار الثاني من Extreme Programming Explained (نوفمبر 2004)، بعد خمس سنوات من الإصدار الأول، أضاف Beck المزيد من القيم والممارسات وميز بين الممارسات الأساسية والتبعية.

مفهوم

الأهداف

يصف كتاب Extreme Programming Explained البرمجة المتطرفة باعتبارها أحد تخصصات تطوير البرمجيات الذي ينظم الأشخاص لإنتاج برمجيات ذات جودة أعلى وأكثر إنتاجية.

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

كما تقدم البرمجة المتطرفة أيضًا عددًا من القيم والمبادئ والممارسات الأساسية بالإضافة إلى منهجية Agile.

أنشطة

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

الترميز

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

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

الاختبار

الاختبار هو جوهر البرمجة المتطرفة. [9] نهج البرمجة المتطرفة هو أنه إذا كان القليل من الاختبار يمكن أن يزيل بعض العيوب، فإن الكثير من الاختبار يمكن أن يزيل العديد من العيوب الأخرى.

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

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

الاستماع

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

تصميم

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

قيم

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

تواصل

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

بساطة

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

تعليق

في البرمجة المتطرفة، تتعلق ردود الفعل بأبعاد مختلفة من تطوير النظام:

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

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

شجاعة

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

احترام

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

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

قواعد

تم نشر النسخة الأولى من قواعد XP في عام 1999 بواسطة Don Wells [12] على موقع XP على الويب. تم تقديم 29 قاعدة في فئات التخطيط والإدارة والتصميم والترميز والاختبار. يتم ذكر التخطيط والإدارة والتصميم صراحةً للرد على الادعاءات بأن XP لا يدعم هذه الأنشطة.

تم اقتراح نسخة أخرى من قواعد XP بواسطة Ken Auer [13] في XP/Agile Universe 2003. لقد شعر أن XP تم تعريفها من خلال قواعدها، وليس ممارساتها (التي تخضع لمزيد من التنوع والغموض). لقد حدد فئتين: "قواعد المشاركة" التي تملي البيئة التي يمكن أن يتم فيها تطوير البرمجيات بشكل فعال، و"قواعد اللعب" التي تحدد الأنشطة والقواعد الدقيقة في إطار قواعد المشاركة.

وفيما يلي بعض القواعد (غير كاملة):

الترميز

الاختبار

مبادئ

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

تعليق

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

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

على افتراض البساطة

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

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

احتضان التغيير

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

الممارسات

تم وصف البرمجة المتطرفة بأنها تتكون من 12 ممارسة، مقسمة إلى أربعة مجالات:

ردود الفعل على نطاق دقيق

عملية مستمرة

التفاهم المشترك

رعاية المبرمجين

الجوانب المثيرة للجدل

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

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

وتشمل الجوانب الأخرى المثيرة للجدل في البرمجة المتطرفة ما يلي:

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

لاحظ النقاد العديد من العيوب المحتملة، [5] بما في ذلك مشاكل المتطلبات غير المستقرة، وعدم وجود تنازلات موثقة لصراعات المستخدم، وعدم وجود مواصفات أو وثيقة تصميم شاملة.

قابلية التوسع

ادعت شركة Thoughtworks أنها حققت نجاحًا معقولاً في مشاريع XP الموزعة التي تضم ما يصل إلى ستين شخصًا. [ بحاجة لمصدر ]

في عام 2004، تم تقديم البرمجة الصناعية المتطرفة (IXP) [15] باعتبارها تطورًا لـ XP. وهي تهدف إلى توفير القدرة على العمل في فرق كبيرة وموزعة. ولديها الآن 23 ممارسة وقيم مرنة.

قابلية الفصل والاستجابات

في عام 2003، نشر مات ستيفنز ودوج روزنبرج كتابًا بعنوان "إعادة صياغة البرمجة المتطرفة: القضية ضد XP" ، والذي شكك في قيمة عملية XP واقترح طرقًا يمكن من خلالها تحسينها. [6] وقد أثار هذا نقاشًا مطولًا في المقالات ومجموعات الأخبار على الإنترنت ومناطق الدردشة على مواقع الويب. والحجة الأساسية للكتاب هي أن ممارسات XP مترابطة ولكن قِلة من المنظمات العملية على استعداد/قادرة على تبني جميع الممارسات؛ وبالتالي فإن العملية برمتها تفشل. كما يقدم الكتاب انتقادات أخرى، ويرسم تشابهًا بين نموذج "الملكية الجماعية" الخاص بـ XP والاشتراكية بطريقة سلبية.

لقد تغيرت جوانب معينة من XP منذ نشر كتاب Extreme Programming Refactored ؛ وعلى وجه الخصوص، يستوعب XP الآن التعديلات على الممارسات طالما تم تحقيق الأهداف المطلوبة. كما يستخدم XP أيضًا مصطلحات عامة بشكل متزايد للعمليات. ويزعم البعض أن هذه التغييرات تبطل الانتقادات السابقة؛ ويزعم آخرون أن هذا ببساطة يضعف العملية.

حاول مؤلفون آخرون التوفيق بين XP والمنهجيات الأقدم من أجل تشكيل منهجية موحدة. سعى بعض هؤلاء إلى استبدال XP، مثل منهجية الشلال ؛ على سبيل المثال: دورات حياة المشروع: الشلال، وتطوير التطبيقات السريع (RAD)، وكل ذلك. حاول JPMorgan Chase & Co. الجمع بين XP وطرق برمجة الكمبيوتر لتكامل نموذج نضج القدرة (CMMI)، و Six Sigma . وجدوا أن الأنظمة الثلاثة عززت بعضها البعض بشكل جيد، مما أدى إلى تطوير أفضل، ولم تتعارض مع بعضها البعض. [16]

نقد

لقد جذبت الضجة الأولية التي أحدثتها البرمجة المتطرفة ومبادئها المثيرة للجدل، مثل البرمجة الزوجية والتصميم المستمر ، انتقادات معينة، مثل تلك التي وجهها ماك برين، [17] وبوهيم وترنر، [18] ومات ستيفنز ودوج روزنبرج. [19] ومع ذلك، يعتقد ممارسو Agile أن العديد من الانتقادات هي سوء فهم للتطوير الرشيق. [20]

على وجه الخصوص، تمت مراجعة البرمجة المتطرفة وانتقادها من قبل كتاب Extreme Programming Refactored الذي كتبه مات ستيفنز ودوج روزنبرج . [6]

انظر أيضا

مراجع

  1. ^ "ورشة عمل التكنولوجيا المرتكزة على الإنسان 2006"، 2006، PDF، ورشة عمل التكنولوجيا المرتكزة على الإنسان 2006
  2. ^ من محاضرات UPenn-Lectures-design-patterns "أنماط التصميم وإعادة الهيكلة"، جامعة بنسلفانيا، 2003 محفوظ في 2 أغسطس 2010، على موقع واي باك مشين .
  3. ^ من محاضرة USFCA-edu-601 البرمجة المتطرفة.
  4. ^ "بيان تطوير البرمجيات الرشيقة". Agilemanifesto.org. 2001. تم الاسترجاع في 26 مارس 2019 .
  5. ^ abcdefghijklm Computerworld-appdev-92 “البرمجة المتطرفة”، Computerworld (على الانترنت)، ديسمبر 2001.
  6. ^ abc روزنبرج، دوج؛ ستيفنز، مات (2003). إعادة صياغة البرمجة المتطرفة: القضية ضد XP . Apress. ISBN 978-1-59059-096-6.
  7. ^ لارمان وباسيلي 2003.
  8. ^ مقابلة مع كينت بيك ومارتن فاولر. 23 مارس 2001. {{cite book}}: |work=تم تجاهله ( مساعدة )
  9. ^ ليزا كريسبين؛ تيب هاوس (2003). اختبار البرمجة المتطرفة . أديسون ويسلي بروفيشنال. رقم ISBN 9780321113559.
  10. ^ "كل شخص مبرمج" بقلم كلير تريسترام. مراجعة التكنولوجيا ، نوفمبر 2003. ص 39.
  11. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change . Addison-Wesley. ISBN 978-0-321-27865-4.
  12. ^ "قواعد البرمجة المتطرفة". extremeprogramming.org .
  13. ^ كين أوير محفوظ في 20 سبتمبر 2008، على موقع واي باك مشين
  14. ^ جون كارول؛ ديفيد موريس (29 يوليو 2015). إدارة المشاريع الرشيقة بخطوات سهلة، الطبعة الثانية. في خطوات سهلة. ص 162. رقم ISBN 978-1-84078-703-0.
  15. ^ Cutter Consortium. "Industrial XP: Making XP Work in Large Organizations - Cutter Consortium". cutting.com .
  16. ^ البرمجة المتطرفة (XP) Six Sigma CMMI.
  17. ^ McBreen, P. (2003). Questioning Extreme Programming . Boston, MA: Addison-Wesley. ISBN 978-0-201-84457-3.
  18. ^ بوم، ب .؛ ر. تيرنر (2004). موازنة المرونة والانضباط: دليل للمحير . بوسطن، ماساتشوستس: أديسون ويسلي. رقم ISBN 978-0-321-18612-6.
  19. ^ ستيفنز، مات ؛ دوج روزنبرج (2004). مفارقة البرمجة المتطرفة. ماساتشوستس: مجلة دكتور دوبس.
  20. ^ sdmagazine محفوظ في 16 مارس 2006، على موقع Wayback Machine

قراءة إضافية

  • كين أوير وروي ميلر. البرمجة المتطرفة التطبيقية: اللعب للفوز ، أديسون ويسلي.
  • كين أوير؛ رون جيفريز ؛ جيف كانا؛ جلين ب. أليمان؛ ليزا كريسبين؛ جانيت جريجوري (2002). "هل أصبح المختبرون منقرضين؟ كيف يمكن للمختبرين المساهمة في فرق XP؟". البرمجة المتطرفة والأساليب الرشيقة — XP/Agile Universe 2002. محاضرات في علوم الكمبيوتر. المجلد 2418. Springer-Verlag. ص 287. doi :10.1007/3-540-45672-4_50. ISBN 978-3-540-44024-6.
  • كينت بيك : شرح البرمجة المتطرفة: احتضان التغيير ، أديسون ويسلي. الطبعة الأولى، 1999. الطبعة الثانية، مع سينثيا أندريس، 2004.
  • كينت بيك ومارتن فاولر : تخطيط البرمجة المتطرفة ، أديسون ويسلي.
  • أليستير كوكبيرن : تطوير البرمجيات الرشيقة ، أديسون ويسلي.
  • مارتن فاولر : إعادة الهيكلة: تحسين تصميم الكود الحالي . مع كينت بيك، وجون برانت، وويليام أوبديك، ودون روبرتس (1999). أديسون ويسلي.
  • هارفي هيريلا (2005). دراسة حالة: نظام التعويض الشامل لشركة كرايسلر. مختبر جالين، جامعة كاليفورنيا، إيرفين.
  • جيم هايسميث . أنظمة تطوير البرمجيات الرشيقة ، أديسون ويسلي.
  • رون جيفريز ، آن أندرسون وتشيت هندريكسون (2000)، البرمجة المتطرفة المثبتة ، أديسون ويسلي.
  • لارمان، سي ؛ باسيلي، في آر (يونيو 2003). "التطورات التكرارية والتزايدية. تاريخ موجز" (ملف PDF) . الكمبيوتر . 36 (6): 47-56. doi :10.1109/MC.2003.1204375.
  • مات ستيفنز ودوج روزنبرج (2003). إعادة صياغة البرمجة المتطرفة: القضية ضد XP ، Apress.
  • فالدنر، جي بي. (2008). “أجهزة الكمبيوتر النانوية وذكاء السرب”. في: ISTE، 225-256.
تحتوي ويكيميديا ​​كومنز على الوسائط المتعلقة بـ البرمجة المتطرفة .
يحتوي موقع Wikiquote على اقتباسات متعلقة بـ البرمجة المتطرفة .
  • مقدمة لطيفة
  • البرمجة الصناعية المتطرفة
  • مشاكل وحلول تنفيذ XP
  • استخدام عملية برمجيات Agile مع التطوير الخارجي – تجارب ThoughtWorks في تنفيذ XP في مشاريع موزعة كبيرة
Retrieved from "https://en.wikipedia.org/w/index.php?title=Extreme_programming&oldid=1248295986"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate