برمجة زوجية

من أرابيكا، الموسوعة الحرة

هذه هي النسخة الحالية من هذه الصفحة، وقام بتعديلها عبد العزيز (نقاش | مساهمات) في 04:23، 11 سبتمبر 2023 (استبدال وسائط مستغى عنها في الاستشهاد). العنوان الحالي (URL) هو وصلة دائمة لهذه النسخة.

(فرق) → نسخة أقدم | نسخة حالية (فرق) | نسخة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث
جزء من سلسلة مقالات حول
عملية تطوير البرمجيات
نشاطات رئيسة
نماذج العمل
منهجيات التطوير وأُطُره
اختصاصات داعمة
تطبيقات بالممارسة
أدوات
منظَّمات ومعايير
شعار بوابة بوابة برمجيات

البرمجة الزوجية هي أحد تقنيات أجيل لتطوير البرمجيات حيث يعمل اثنين من المبرمجين معا في محطة عمل واحدة. يكتب أحدهم الكود المصدري في حين يستعرض الأخر كل سطر من الأكواد كما تمت كتابتها. والشخص الذي يقوم بالكتابة يُسمى المحرك. ويطلق على الشخص الذي يستعرض الكود المراقب (أو الملاح[1]). ويتبادل المبرمجان الأدوار بشكل متكرر. أثناء الاستعراض، يضع المراقب في اعتباره التوجه الاستراتيجي للعمل، والخروج بأفكار من أجل إدخال تحسينات والمشاكل المحتملة في المستقبل لمعالجتها. وهذا يتيح الفرصة للمحرك في تركيز كل اهتمامه على الجوانب «التكتيكية» لاستكمال المهمة الحالية، وذلك باستخدام المراقب كشبكة أمان ودليل.

مع انخفاض أسعار أجهزة الكمبيوتر هذه الأيام، أصبح من الشائع إعداد جديد بشاشتين يتشاركان في مكان العمل في الصناعة

التكاليف والفوائد

وجدت بعض الدراسات أن المبرمجين الذين يعملون بشكل زوجي ينتجون برامج أقصر، مع تصميمات أفضل وعدد أخطاء برمجية أقل، من المبرمجين الذين يعملون وحدهم.[2] وقد وجدت الدراسات انخفاض معدلات الخطأ من 15 ٪ إلى 50 ٪، وتتفاوت اعتمادا على خبرة المبرمج وتعقيد المهمة.[3][4] وعادة ما ينظر الأزواج في بدائل تصميمية أكثر من المبرمجين المنفردين، ويستطيعوا التوصل إلى تصاميم أكثر بساطة وأكثر ثباتا؛ كما يستطيعون اصطياد عيوب التصميم في وقت مبكر.[5] وعادة ما يعمل الأزواج بشكل أسرع من مبرمج واحد مخصص لنفس المهمة. وغالبا ما يجد الأزواج المشاكل التي تبدو «مستحيلة» سهلة أو حتى سريعة الحل، أو على الأقل من الممكن حلها عندما يعملون معا.[2][6]

ومع ذلك، وفي 2007، استنتج تحليل الميتا أن «البرمجة الزوجية ليست مفيدة بشكل موحد أو فعالة» بسبب أن العديد من العوامل الأخرى بجانب اختيار استخدام البرمجة الزوجية لها آثار كبيرة على نتائج مهمة البرمجة.[7] ووجدت دراسة الميتا أن البرمجة الزوجية تميل إلى تقليل الوقت اللازم للتطوير، وتنتج آثارا إيجابية هامشية على نوعية الكود، ولكن هذه البرمجة الزوجية تتطلب جهد أكبر من المطور، وهذا يعني، أن تكلفتها أكثر بكثير من تكلفة البرمجة المنفردة. ويقترح المؤلفان أن دراسة البرمجة الزوجية تعاني من التحيز في النشر حيث ان الدراسات التي لا تظهر أن البرمجة الزوجية مفيدة، لا تقدم للنشر، أو لا يقبل نشرها. وبالتالي يتم الاستنتاج أنه «لا يمكنك ان تتوقع أسرع وأفضل وأرخص». على الرغم من اكتمال الترميز بشكل أسرع مما يكون عليه عندما يعمل مبرمج واحد وحده، فإن مجموع وقت المبرمج (عدد المبرمجين × الوقت الممضى) يزداد. ويجب على المدير أن يوازن بين انتهاء العمل بشكل أسرع وتقليل الاختبار ووقت التصحيح ضد ارتفاع تكلفة الترميز. ويمكن للوزن النسبي لهذه العوامل أن تختلف من مشروع إلى آخر ومهمة لأخرى. ان الاستفادة من الاقتران هو أعظم بالنسبة للمهام التي لا يستعبها المبرمجين تماما قبل أن البدء: وهذا يعني، المهام الصعبة التي تدعو إلى الإبداع والتطور.إغلاق </ref> مفقود لوسم <ref>[8]

تمر المعرفة بين المبرمجان وهم يعملون. فهما يتبادلان المعرفة بخصوصيات النظام، ويلتقطان تقنيات البرمجة من بعضهما البعض.[2][9] يلتقط بسرعة الموظفون الجدد ممارسات الفريق ومعرفة تفاصيل هذا النظام.[10] تنتشر مع «الاقتران المختلط»—كل مبرمج يدور خلال سائر مبرمجين الفريق بدلا من الاقتران بشريك واحد فقط—معرفة النظام في الفريق بأكمله، وبالتالي الحد من مخاطر الإدارة في حالة ترك أحد المبرمجين الفريق.[2]

عادة ما يحسن الاقتران الانضباط وإدارة الوقت. فالمبرمجين أقل عرضة لتخطي اختبارات الوحدة، وقضاء بعض الوقت في تصفح شبكة الإنترنت أو على البريد الإلكتروني الشخصي،[11] أو الالتواء عند العمل مع شريك مقترن. فالشريك المقترن «يبقيهم صادقين».[12][13] وان الناس يكونوا أكثر ترددا في مقاطعة زوجا مما هو عليه الحال بالنسبة لشخص يعمل وحده.[14]

وبعض الفوائد الإضافية المذكورة تشمل زيادة الروح المعنوية،[15] وزيادة الثقة في صحة الكود.[2]

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

حسب الاقتصاديون

«وقد أظهرت لوري وليامز من جامعة يوتا في مدينة سولت ليك أن المبرمجين الزوجيين ليسوا سوى 15 ٪ أبطأ من اثنين من المبرمجين الفرديين المستقلين، ولكن ينتجوا 15 ٪ أخطاء برمجية أقل. (ملحوظة: أظهرت الدراسة الأصلية أن كود 'خالي من الأخطاء’ ذهبت من 70 ٪ إلى 85 ٪، بل قد تكون أكثر سهولة للقول بأن هذا هو انخفاض 50 ٪ من الأخطاء، من 30 ٪ إلى 15 ٪). ولأن الاختبار والتصحيح في كثير من الأحيان أكثر تكلفة من العديد من البرامج الأولية، فهذه نتيجة مثيرة للإعجاب.»[4]

وقد أظهرت وليامز في دراسة 2000 تحسنا في صحة الأخطاء بنحو 15 ٪ وانخفاض 20 ٪ -40 ٪ في الوقت، ولكن بين زيادة 15 ٪ و60 ٪ في الجهد، وهو، مجموع ساعات المبرمج. ودراية وليامز2000 تستشهد بدراسة سابقة (Nosek 1998) والتي اظهرت أيضا انخفاضا بنسبة 40 ٪ في الوقت وزيادة 60 ٪ في الجهد. وتعرض دراسة (لوي 2006) تجربة علمية صارمة والتي عند اختبار زوجين مبتدئين ضد منفردين مبتدئين يتم تحقيق مكاسب إنتاجية أكبر بكثير من اختبار أزواج ذو خبرة ضد منفردين خبرة.[8]

وفي دراسة حديثة أكبر (Arisholm 2007) يوجد زيادة 48 ٪ في صحة الأنظمة المعقدة، ولكن لا يوجد فرق كبير في الوقت، في حين كان النقص في الوقت في النظم البسيطة 20 ٪، ولكن لم يوجد اختلاف كبير في الصحة. وبشكل عمومي لم يكن هناك انخفاض عام في الوقت أو زيادة في الصحة، ولكن زيادة عامة 84 ٪ في الجهد.[16]

ويظهر لوي، وتشان، ونوزك (2008) أن البرمجة الزوجية تتفوق في المهام التصميمية.

وفي تحليل ميتا كامل النطاق من الدراسات التجريبية على البرمجة الزوجية، من قبل أو خلال عام 2007، يؤكد (هناي. 2009) «أنه لا يمكنك توقع أسرع وأفضل وأرخص». وتكلف الجودة الأعلى للقيام بمهام معقدة جهد مرتفع، وتخفيض المدة للمهام الأبسط يأتي مع جودة أقل بشكل ملحوظ—تحليل الميتا «تشير إلى أن البرمجة الزوجية ليست مفيدة بشكل موحد أو فعالة».[7]

أشكال البرمجة الزوجية

خبير-خبير

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

خبير-مبتدئ

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

مبتدئ-مبتدئ

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

مؤشرات التعثر

وهناك مؤشرات قليلة على أن هذا الزوج لا يعمل بشكل جيد:

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

المتغيرات

البرمجة الزوجية عن بعد

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

العديد من الأدوات الإضافية مثل مساعدات برنامج إيكليبس متوفرة لدعم الاقتران عن بعد. ولقد جربت بعض الفرق Virtual Network Computing وRealVNC مع كل مبرمج باستخدام الحاسوب الخاص بهم.[20][21][22] واستخدام آخرون وضع العرض المتعدد (-x) من خلال شاشة جنو المستندة إلى نص. ولدى شركةأبل ماك أو إس عشرة تطبيق تقاسم الشاشة مدمج.

برمجة بينغ بونغ الزوجية

في برمجة بينغ بونغ الزوجية، يكتب المراقب اختبار وحدة فاشل، يعدل المحرك كود لاجتياز الاختبار. عند هذه النقطة، يقوموا بتبادل الأدوار ويكتب المحرك الأصلي (بصفته المراقب) اختبار فاشل. يُعدل المراقب الأصلي (المحرك الآن) كود لاجتياز الاختبار الجديد، وهلم جرا. وتستمر هذه الحلقة ما دام أحد العضوين قادرا على كتابة اختبار وحدة فاشل للعضو الأخر لتنفيذه. وفي العموم، قد يستغرق هذا النهج مزيدا من الوقت عن الخطة المقدرة.[23]

انظر أيضًا

وصلات خارجية

برامج ووصلات تدعم البرمجة الزوجية

المراجع

  1. ^ Williams، Laurie (2001). "Integrating Pair Programming into a Software Development Process" (PDF). 14th Conference on Software Engineering Education and Training: abstract. مؤرشف من الأصل (PDF) في 2011-12-29."One of the programmers, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work."
  2. ^ أ ب ت ث ج Cockburn، Alistair؛ Williams، Laurie (2000). "The Costs and Benefits of Pair Programming" (PDF). Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). مؤرشف من الأصل (PDF) في 2019-04-30.
  3. ^ Canfora، Gerardo (2007). "Evaluating performances of pair designing in industry". The Journal of Systems and Software. ج. 80 ع. 80: 1317–1327. DOI:10.1016/j.jss.2006.11.004. مؤرشف من الأصل (PDF) في 2016-03-06. اطلع عليه بتاريخ 2010-06-14. {{استشهاد بدورية محكمة}}: الوسيط غير المعروف |مؤلفين مشاركين= تم تجاهله يقترح استخدام |authors= (مساعدة)
  4. ^ أ ب "Agility counts". The Economist. 20 سبتمبر 2001. مؤرشف من الأصل في 2016-07-09..
  5. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 27–28. ISBN:0-201-74576-3. With pair programming, 'four eyeballs are better than two,' and a momentous number of defects are prevented, removed right from the start. These continual reviews outperform traditional, formal reviews in their defect-removal speed.
  6. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 26. ISBN:0-201-74576-3. "Collaborative teams consistently report that together they can evolve solutions to unruly or seemingly impossible problems. … The driver might actually be working out a design or implementing a part of the problem, realizing that he or she may ultimately come to a dead end in the problem resolution. The navigator, while watching the driver's partial design or implementation, begins thinking about the next step. When the driver hits the dead end, the navigator is often prepared to take over and lead the way. Often, the cycle continues until the problem is solved."
  7. ^ أ ب Hannay، Jo E. (2009). "The Effectiveness of Pair Programming: A Meta-Analysis". Information and Software Technology. ج. 51 ع. 7: 1110–1122. DOI:10.1016/j.infsof.2009.02.001. {{استشهاد بدورية محكمة}}: الوسيط غير المعروف |شهر= تم تجاهله (مساعدة) والوسيط غير المعروف |مؤلفين مشاركين= تم تجاهله يقترح استخدام |authors= (مساعدة)
  8. ^ أ ب Lui، Kim Man (سبتمبر 2006). "Pair programming productivity: Novice–novice vs. expert–expert" (PDF). International Journal of Human–Computer Studies. ج. 64 ع. 9: 915–925. DOI:10.1016/j.ijhcs.2006.04.010. مؤرشف من الأصل (PDF) في 2017-09-18. اطلع عليه بتاريخ 2012-11-18.
  9. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 29. ISBN:0-201-74576-3. "Knowledge is constantly being passed between partners, from tool usage tips to design and programming idioms. The partners take turns being the teacher and the student. Even unspoken skills and habits cross partners."
  10. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 112. ISBN:0-201-74576-3. "[Expert-novice pairing] can even be valuable for novices who are novices only in the sense that they haven't been with their team for very long. … Watching and then doing with an expert by your side can greatly reduce the time it would require to learn 'the right way' of working with the team. It really helps when the newbie works with many of the experts (or with any team member) so he or she can learn about many different aspects of the system."
  11. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 23. ISBN:0-201-74576-3. "Two people working in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each other's time." (Ward's Wiki 1999, contributed by Paul Chisholm).
  12. ^ Beck، Kent (2000). Extreme Programming Explained. Addison-Wesley. ص. 102. ISBN:201-61641-6. {{استشهاد بكتاب}}: تأكد من صحة |isbn= القيمة: طول (مساعدة)"Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."
  13. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 24. ISBN:0-201-74576-3."With any software development process there is a constant struggle to get the software engineers to follow the prescribed process. A benefit of pair programming is improved adherence to procedures and standards."
  14. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 24. ISBN:0-201-74576-3."Others see us already working with someone else, and they leave us alone. The net effect is that we have bigger blocks of uninterrupted time, which is good for our mental state and our progress. It also reduces task-switching, which for some people generates a huge overhead."
  15. ^ Williams، Laurie؛ Kessler، Robert (2003). Pair Programming Illuminated. Addison-Wesley. ص. 21. ISBN:0-201-74576-3. "In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'"
  16. ^ Aranda، Jorge (12 مارس 2007). "Pair programming evaluated". مؤرشف من الأصل في 2014-03-29. اطلع عليه بتاريخ 2008-02-07.
  17. ^ Agile Pair Programming | Agile Sherpa نسخة محفوظة 03 أبريل 2016 على موقع واي باك مشين.
  18. ^ Flor, Nick (2006). Globally distributed software development and pair programming. Communication of the ACM, 49, 57-58.
  19. ^ Schümmer، Till (2009). "Understanding Tools and Practices for Distributed Pair Programming" (PDF). Journal of Universal Computer Science. ج. 15 ع. 16: 3101–3125. مؤرشف من الأصل (PDF) في 2016-12-03. اطلع عليه بتاريخ 2010-04-30. {{استشهاد بدورية محكمة}}: الوسيط غير المعروف |شهر= تم تجاهله (مساعدة) والوسيط غير المعروف |مؤلفين مشاركين= تم تجاهله يقترح استخدام |authors= (مساعدة)
  20. ^ Agile Ajax: Pair Programming with VNC نسخة محفوظة 02 أبريل 2008 على موقع واي باك مشين.
  21. ^ Pair Programming - The Ultimate Setup and the other options we tried. - Jonathan Cogley's Blog نسخة محفوظة 02 يناير 2014 على موقع واي باك مشين.
  22. ^ Ola Lindberg › Computer ergonomics and pair programming نسخة محفوظة 21 يوليو 2009 على موقع واي باك مشين.
  23. ^ "PairProgrammingPingPongPattern". c2.com. مؤرشف من الأصل في 2016-07-30.
مجلوبة من «https://3rabica.org/index.php?title=برمجة_زوجية&oldid=1516565»