stanford-oval/wikipedia huggingface dataset:
تحليل البرنامج الساكن
أنواع الأدوات

نشرت مجموعة إدارة الهدف (أو إم جي) دراسة تتعلق بأنواع تحليل البرمجيات المطلوب لقياس جودة البرمجيات وتقييمها. يصف هذا المستند عن «كيفية تسليم أنظمة تكنولوجيا معلومات المرنة والآمنة والفعالة وسهلة التغيير وفقًا لتوصيات اتحاد جودة برمجيات تكنولوجيا المعلومات (سي إس آي كيو)» ثلاثة مستويات من تحليل البرمجيات.
أنواع الأدوات > مستوى الوحدة

التحليل الذي يتم داخل برنامج أو روتين فرعي معين، دون الاتصال بسياق ذلك البرنامج.
أنواع الأدوات > المستوى التقني

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

التحليل الذي يراعي التفاعلات بين برامج الوحدة، لكن دون تقيد بتقنية أو لغة برمجة واحدة محددة.
يمكن تعريف مستوى آخر من تحليل البرمجيات.
أنواع الأدوات > مستوى المهمة/العمل

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

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

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

يعرف التطوير مقاد بالسلوك (بالإنجليزية: Behavior-driven development، واختصارًا: BDD)، في هندسة البرمجيات، على أنه عملية تطوير البرمجيات وفقًا لمنهجية أجايل تشجع التعاون بين المطورين ومختبري ضمان الجودة وممثلي العملاء في مشروع برمجي. يشجع الفرق على استخدام المحادثة والأمثلة العملية لإضفاء الطابع الرسمي على الفهم المشترك لكيفية عمل التطبيق. نشأ من التطوير المقاد بالاختبار (تي دي دي). يجمع التطوير المقاد بالسلوك بين التقنيات العامة ومبادئ التطوير المقاد بالاختبار مع أفكار من التصميم المقاد بالمجال والتحليل والتصميم كائنيا التوجه لتزويد فرق تطوير وإدارة البرمجيات بأدوات مشتركة وعملية مشتركة للتعاون في تطوير البرمجيات.
رغم أن التطوير المقاد بالسلوك يعتبرأساسًا فكرة تتعلق بكيفية إدارة تطوير البرمجيات وفقًا للمصالح التجارية والرؤية التقنية، لكن يفترض تطبيق التطوير المقاد بالسلوك استخدام أدوات برمجية مخصصة لدعم عملية التطوير. ورغم أن هذه الأدوات تطور غالبًا للاستخدام خصيصًا في مشاريع التطوير المقاد بالسلوك، ولكن يمكن اعتبارها أشكالًا متخصصة من الأدوات التي تدعم التطوير المقاد بالاختبار. تعمل الأدوات على إضافة أتمتة إلى اللغة السائدة والتي تعد موضوعًا رئيسيًا للتطوير المقاد بالسلوك.
يسهل التطوير المقاد بالسلوك كثيرًا بفضل استخدام لغة مجال محدد (دي إس إل) بسيطة تستخدم تراكيب اللغة الطبيعية (الجمل الشبيهة بالإنجليزية مثلًا) التي يمكن أن تعبر عن السلوك والنتائج المتوقعة. لطالما كانت نصوص الاختبار تطبيقًا شائعًا للغات المجال المحدد بدرجات متفاوتة من التعقيد. يعتبر التطوير المقاد بالسلوك ممارسة تقنية فعالة خاصةً عندما تكون «مساحة المسألة» لمسألة العمل التي يجب حلها معقدة.
مبادئ التطوير المقاد بالسلوك

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

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

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

1 2 3  North، Dan (مارس 2006). "Introducing BDD". Dan North. مؤرشف من الأصل في 2021-05-23. اطلع عليه بتاريخ 2019-04-25.
1 2  "Behaviour-Driven Development". مؤرشف من الأصل في 2015-09-01. اطلع عليه بتاريخ 2012-08-12.
↑  Keogh، Liz (7 سبتمبر 2009). "Introduction to Behavior-Driven Development". SkillsMatter. مؤرشف من الأصل في 2021-02-25. اطلع عليه بتاريخ 2019-05-01.
↑  John Ferguson Smart (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN:9781617291654.
1 2 3 4  Haring, Ronald (Feb 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". Java Magazine (بالهولندية). Veen Magazines (1): 14–17. ISSN:1571-6236.
↑  Solis، Carlos؛ Wang، Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on: 383–387. DOI:10.1109/SEAA.2011.76. hdl:10344/1256. ISBN:978-1-4577-1027-8.
1 2 3 4  Bellware، Scott (يونيو 2008). "Behavior-Driven Development". Code Magazine. مؤرشف من الأصل في 2012-07-12. اطلع عليه بتاريخ 2019-05-01.
↑  Tharayil، Ranjith (15 فبراير 2016). "Behavior-Driven Development: Simplifying the Complex Problem Space". SolutionsIQ. مؤرشف من الأصل في 2020-10-21. اطلع عليه بتاريخ 2018-02-15.
1 2  North، Dan (11 فبراير 2007). "What's in a Story?". Dan North. مؤرشف من الأصل في 2021-03-23. اطلع عليه بتاريخ 2012-08-12.
↑  Mabey، Ben. "Imperative vs. Declarative Scenarios in user stories". مؤرشف من الأصل في 2010-06-03. اطلع عليه بتاريخ 2008-05-19.
↑  "nutshell — Lettuce 0.2.23 (kryptonite release) documentation". lettuce.it. مؤرشف من الأصل في 2020-11-01. اطلع عليه بتاريخ 2020-02-06.
↑  "Gherkin". مؤرشف من الأصل في 2021-06-11. اطلع عليه بتاريخ 2020-06-07.
↑  "What is JBehave?". JBehave.org. مؤرشف من الأصل في 2021-03-03. اطلع عليه بتاريخ 2015-10-20.
↑  "behave is behaviour-driven development, Python style". مؤرشف من الأصل في 2018-01-22. اطلع عليه بتاريخ 2018-01-30.
↑  "Writing Features - Behat 3.0.12 documentation". behat documentation. مؤرشف من الأصل في 2015-09-19. اطلع عليه بتاريخ 2015-10-20.
↑  Evans، Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN:978-0-321-12521-7. مؤرشف من الأصل في 2021-05-07. اطلع عليه بتاريخ 2012-08-12.
↑  North، Dan (31 مايو 2012). "BDD is like TDD if…". faster organisations, faster software. Dan North & Associates. مؤرشف من الأصل في 2021-06-08. اطلع عليه بتاريخ 2012-08-12.
↑  Geneca (16 مارس 2011). "Why Software Projects Fail". مؤرشف من الأصل في 2016-12-30. اطلع عليه بتاريخ 2011-03-16.
↑  Mahmudul Haque Azad (6 فبراير 2011). "Say Hello To Behavior Driven Development". مؤرشف من الأصل في 2020-01-22. اطلع عليه بتاريخ 2012-08-12.
↑  Lübke, Daniel؛ van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. ج. 33 ع. 5: 15–21. DOI:10.1109/MS.2016.117.
بوابة علم الحاسوب
بوابة برمجيات
جهاز مضاد الكهروستيتكي

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

↑  "What is an Antistatic Device?". www.computerhope.com (بالإنجليزية). Archived from the original on 2023-04-26. Retrieved 2023-06-10.
بوابة إلكترونيات
بوابة تقانة
في كومنز مواد ذات صلة بـ جهاز مضاد الكهروستيتكي.
برمجة زوجية

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

وجدت بعض الدراسات أن المبرمجين الذين يعملون بشكل زوجي ينتجون برامج أقصر، مع تصميمات أفضل وعدد أخطاء برمجية أقل، من المبرمجين الذين يعملون وحدهم. وقد وجدت الدراسات انخفاض معدلات الخطأ من 15 ٪ إلى 50 ٪، وتتفاوت اعتمادا على خبرة المبرمج وتعقيد المهمة. وعادة ما ينظر الأزواج في بدائل تصميمية أكثر من المبرمجين المنفردين، ويستطيعوا التوصل إلى تصاميم أكثر بساطة وأكثر ثباتا؛ كما يستطيعون اصطياد عيوب التصميم في وقت مبكر. وعادة ما يعمل الأزواج بشكل أسرع من مبرمج واحد مخصص لنفس المهمة. وغالبا ما يجد الأزواج المشاكل التي تبدو «مستحيلة» سهلة أو حتى سريعة الحل، أو على الأقل من الممكن حلها عندما يعملون معا.
ومع ذلك، وفي 2007، استنتج تحليل الميتا أن «البرمجة الزوجية ليست مفيدة بشكل موحد أو فعالة» بسبب أن العديد من العوامل الأخرى بجانب اختيار استخدام البرمجة الزوجية لها آثار كبيرة على نتائج مهمة البرمجة. ووجدت دراسة الميتا أن البرمجة الزوجية تميل إلى تقليل الوقت اللازم للتطوير، وتنتج آثارا إيجابية هامشية على نوعية الكود، ولكن هذه البرمجة الزوجية تتطلب جهد أكبر من المطور، وهذا يعني، أن تكلفتها أكثر بكثير من تكلفة البرمجة المنفردة. ويقترح المؤلفان أن دراسة البرمجة الزوجية تعاني من التحيز في النشر حيث ان الدراسات التي لا تظهر أن البرمجة الزوجية مفيدة، لا تقدم للنشر، أو لا يقبل نشرها. وبالتالي يتم الاستنتاج أنه «لا يمكنك ان تتوقع أسرع وأفضل وأرخص».
على الرغم من اكتمال الترميز بشكل أسرع مما يكون عليه عندما يعمل مبرمج واحد وحده، فإن مجموع وقت المبرمج (عدد المبرمجين × الوقت الممضى) يزداد. ويجب على المدير أن يوازن بين انتهاء العمل بشكل أسرع وتقليل الاختبار ووقت التصحيح ضد ارتفاع تكلفة الترميز. ويمكن للوزن النسبي لهذه العوامل أن تختلف من مشروع إلى آخر ومهمة لأخرى. ان الاستفادة من الاقتران هو أعظم بالنسبة للمهام التي لا يستعبها المبرمجين تماما قبل أن البدء: وهذا يعني، المهام الصعبة التي تدعو إلى الإبداع والتطور.
تمر المعرفة بين المبرمجان وهم يعملون. فهما يتبادلان المعرفة بخصوصيات النظام، ويلتقطان تقنيات البرمجة من بعضهما البعض. يلتقط بسرعة الموظفون الجدد ممارسات الفريق ومعرفة تفاصيل هذا النظام. تنتشر مع «الاقتران المختلط»—كل مبرمج يدور خلال سائر مبرمجين الفريق بدلا من الاقتران بشريك واحد فقط—معرفة النظام في الفريق بأكمله، وبالتالي الحد من مخاطر الإدارة في حالة ترك أحد المبرمجين الفريق.
عادة ما يحسن الاقتران الانضباط وإدارة الوقت. فالمبرمجين أقل عرضة لتخطي اختبارات الوحدة، وقضاء بعض الوقت في تصفح شبكة الإنترنت أو على البريد الإلكتروني الشخصي، أو الالتواء عند العمل مع شريك مقترن. فالشريك المقترن «يبقيهم صادقين». وان الناس يكونوا أكثر ترددا في مقاطعة زوجا مما هو عليه الحال بالنسبة لشخص يعمل وحده.
وبعض الفوائد الإضافية المذكورة تشمل زيادة الروح المعنوية، وزيادة الثقة في صحة الكود.
الدراسات العلمية

حسب الاقتصاديون
وقد أظهرت وليامز في دراسة 2000 تحسنا في صحة الأخطاء بنحو 15 ٪ وانخفاض 20 ٪ -40 ٪ في الوقت، ولكن بين زيادة 15 ٪ و60 ٪ في الجهد، وهو، مجموع ساعات المبرمج. ودراية وليامز2000 تستشهد بدراسة سابقة (Nosek 1998) والتي اظهرت أيضا انخفاضا بنسبة 40 ٪ في الوقت وزيادة 60 ٪ في الجهد.
وتعرض دراسة (لوي 2006) تجربة علمية صارمة والتي عند اختبار زوجين مبتدئين ضد منفردين مبتدئين يتم تحقيق مكاسب إنتاجية أكبر بكثير من اختبار أزواج ذو خبرة ضد منفردين خبرة.
وفي دراسة حديثة أكبر (Arisholm 2007) يوجد زيادة 48 ٪ في صحة الأنظمة المعقدة، ولكن لا يوجد فرق كبير في الوقت، في حين كان النقص في الوقت في النظم البسيطة 20 ٪، ولكن لم يوجد اختلاف كبير في الصحة. وبشكل عمومي لم يكن هناك انخفاض عام في الوقت أو زيادة في الصحة، ولكن زيادة عامة 84 ٪ في الجهد.
ويظهر لوي، وتشان، ونوزك (2008) أن البرمجة الزوجية تتفوق في المهام التصميمية.
وفي تحليل ميتا كامل النطاق من الدراسات التجريبية على البرمجة الزوجية، من قبل أو خلال عام 2007، يؤكد (هناي. 2009) «أنه لا يمكنك توقع أسرع وأفضل وأرخص». وتكلف الجودة الأعلى للقيام بمهام معقدة جهد مرتفع، وتخفيض المدة للمهام الأبسط يأتي مع جودة أقل بشكل ملحوظ—تحليل الميتا «تشير إلى أن البرمجة الزوجية ليست مفيدة بشكل موحد أو فعالة».
الدراسات العلمية > أشكال البرمجة الزوجية > خبير-خبير

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

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

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

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

البرمجة الزوجية عن بعد، والمعروفة أيضا باسم البرمجة الزوجية الافتراضية أو البرمجة الزوجية الموزعة، هي برمجة زوجية يكون فيها المبرمجين في مواقع مختلفة، يعملون عبر محرر الوقت الحقيقي التعاوني، أو سطح مكتب مشترك، أو برنامج مساعد في بيئة تطوير متكاملة للبرمجة الزوجية عن بعد. تُدخل البرمجة الزوجية عن بعد صعوبات لم تكن موجودة في اقتران الوجه لوجه، مثل تأخير اضافي للتنسيق، وهذا يتوقف على أدوات تتبع المهمة ذات «الوزن الثقيل» بدلا من تلك «الخفيفة» مثل فهرس البطاقات، وفقدان التواصل الغير لفظي مما أدى إلى الارتباك والصراعات على أشياء مثل من «لديه لوحة المفاتيح».
العديد من الأدوات الإضافية مثل مساعدات برنامج إيكليبس متوفرة لدعم الاقتران عن بعد. ولقد جربت بعض الفرق Virtual Network Computing وRealVNC مع كل مبرمج باستخدام الحاسوب الخاص بهم. واستخدام آخرون وضع العرض المتعدد (-x) من خلال شاشة جنو المستندة إلى نص. ولدى شركةأبل ماك أو إس عشرة تطبيق تقاسم الشاشة مدمج.
المتغيرات > برمجة بينغ بونغ الزوجية

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

wikiHow: How to Pair Program  How-to guide; contains common wisdom on how to make pair programming work.
Agile Alliance's Index of Articles about Pair Programming
PairWithUs A collection of videos showing pair programming in action.
وصلات خارجية > برامج ووصلات تدعم البرمجة الزوجية

Eclipse Communication Framework Includes Cola, an إكلبس plug-in
Saros An إكلبس plug-in
XPairtise An إكلبس plug-in
wave-vs.net Plug-in for مايكروسوفت فيجوال ستوديو
بابلو كاربالو

| بابلو كاربالو | بابلو كاربالو |
| --- | --- |
 :  
 معلومات شخصية :  معلومات شخصية 
الميلاد: 11 ديسمبر 1947   (78 سنة)   بوينس آيرس  
مواطنة:  الأرجنتين  
 الحياة العملية  :  الحياة العملية  
المهنة: ضابط، ومدرس  
الخدمة العسكرية : الخدمة العسكرية 
الولاء: الأرجنتين  
الفرع: سلاح الجو الأرجنتيني  
الرتبة: عميد بحري  
المعارك والحروب: حرب الفوكلاند  
 :  
تعديل مصدري - تعديل  : تعديل مصدري - تعديل  
بابلو كاربالو (بالإسبانية: Pablo Carballo)‏ هو طيار أرجنتيني، ولد في 11 ديسمبر 1947 في بوينس آيرس في الأرجنتين.
مراجع

↑  Some sources identify this ship as the Rio Carcaraña but other sources place the cargo vessel in Bahía Rey ( King George Bay ? ) at the moment نسخة محفوظة 2010-04-28 على موقع واي باك مشين.
↑  Board of Inquiry - Report into the Loss of HMS Ardent, page 2 نسخة محفوظة 29 سبتمبر 2012 على موقع واي باك مشين.
↑  ELMA FORMOSA نسخة محفوظة 08 مارس 2016 على موقع واي باك مشين.
بوابة الأرجنتين
بوابة أعلام
محمد عبد الرشيد النعماني

محمد عبد الرشيد بن محمد عبد الرحيم النعماني (1333- 1420 هـ)، فقيه حنفي ومحدث من شبه القارة الهندية.
ولد في سنة 1333 هـ في جيبور بالهند، وطلب العلم على عمه الأكبر الحافظ عبد الكريم، ثم رحل إلى ندوة العلماء، ولازم حيدر حسن خان التونكي، وبه تخصص في الحديث وعلومه، وعليه تخرج، ولازم شقيقه محمود حسن خان التونكي، وعين عضواً لندوة المصنفين بدهلي، وهاجر إلى باكستان سنة 1947م، ودرس في دار العلوم على بدر عالم الميرتهي، ومحمد يوسف البنوري، ثم عين مدرساً في جامعة العلوم الإسلامية في كراتشي، ودرس فيها كتب الفقه والحديث، والكتب الستة، ودرس في الجامعة الإسلامية ببهاولبور، وأشرف على طلبة التخصص في الحديث النبوي.
سيرته

اسمه الكامل محمد عبد الرشيد النعماني بن المنشئ محمد عبد الرحيم بن محمد بخش بن التاجر الصدوق بُلاقي بن چراغ محمد بن هِمَّت الراجبوت الكجواهي نسباً، والهندي الميواتي وطناً، والجيبوري الهندي مولدا ومنشأ، والباكستاني الكراتشوي مهاجرا، والنعماني نسبة إلى أبي حنيفة النعمان بن ثابت مذهباً، ولد في يوم الخميس في الساعة السادسة صباحا 18 من شهر ذي القعدة سنة 1333 هـ الموافق 29 سبتمبر 1915م ، في بلدة "جيبور" بإقليم "راجستهان"، الهند.
أصل النعماني من الهند، ولد في أسرة شريفة كريمة نبيلة مزينة بمروء ونجابة وأخلاق حسن، وينتهي نسبه إلى "كچواها" فرع قبيلة "راجپوت" التي هي قبيلة عريقة وشهيرة في الهند، وقبائل "راجپوت" تسكن غرب شمال الهند، وحكمت القسم الأكبر منها على الولايات الأميرية في الهند و"راجستهان" . وكان أمير منطقة "كشمير" وولاية "جام نگر" من فرع "كچواها". بنعمة من الله اعتنقت هذه الأسرة الإسلام ومضت عليها قرون تتمتع بنعمة الإسلام، كان التدين هو الطابع الذي يغلب على هذه الأسرة، وكانت أسرة النعماني مبدئيا تسكن في منطقة "ميوات" بجوار عاصمة الهند "دهلي"، وانتقل جده الأعلى في عهد مبكر إلى "جيبور" واستوطنها، وكان جده الأمجد همت وابنه چراغ محمد تاجران للمجوهرات، يصنعان الجواهر ويبيعانها.
تزوج النعماني يوم الجمعة بين العصر والمغرب في السادس من جمادى الأولى، سنة 1359 هـ، بـ أشرف جهان بنت شرف الدين بن عبد الجميد بن رحيم بخش بن قادر بخش بن محمد حيات الجوهري الميواتي، من قبيلة «بڈھ گوجر» وقد منح الله النعماني خمسة أولاد: ابنان وثلاث بنات.
وتوفي في الساعة العاشرة 29 من شهر ربيع الثاني سنة 1420 هـ الموافق 12 أغسطس 1999م، في مدينة كراتشي باكستان، وصلى عليه أخوه الأصغر محمد عبد الحليم الجشتي بعد صلاة العصر في حديقة مسجده الذي أنشأه في جامعة كراتشي، مع آلاف المصلين من
أساتذة المدارس والطلاب وعامة الناس وكانت جمهرة كبيرة في جنازته وازدحم الناس ابلطريق في حمل الجنازة على أكتافهم
وتشيعه، ودفن بين قبر زوجته و ابنته الصغيرة قبيل صلاة المغرب كما أوصى به.