مراجعات الأقران أم البرمجة الزوجية أم كليهما؟[مغلق]

Question

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

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

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

الآن أصبحت الرؤية أقل عندما يتم إدخال الأخطاء في دورة الحياة.وقد أدى عدم إجراء مراجعات النظراء إلى زيادة التخصص في الفريق... حيث لا أحد يعرف حقًا متطلبات/منطق المكونات خارج المجال المخصص له في النظام.

سيكون من المفيد معرفة تجاربك مع مراجعات الأقران أو البرمجة الثنائية، وخاصة قصص النجاح.

Answer 1

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

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

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

Answer 2

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

بعض الأشياء التي يجب الانتباه إليها:

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

Answer 3

ينبغي أن تكون مراجعة الأقران إلزامي.

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

أنا شخصياً أعتقد أن مراجعة النظراء يجب أن تكون ممتعة.يتم توفير الطعام والحفاظ على الجو مرحا.يجب حقًا التعامل معه على أنه الوقت الذي يمكن فيه للمطورين/المبرمجين التعلم من بعضهم البعض وليس فرصة للحكم (ونعلم جميعًا كيف يبدو أن كل مبرمج يولد بجين حكم فطري).لقد مالت إلى تقدير أو المساعدة في تنظيم المراجعات لتكون 1/3 أو 1/4 من الوقت مفتوحًا.أعني بذلك أنه عندما تجتمع المجموعة معًا ويقدم شخص واحد مشروعًا يعملون عليه أو حتى يراجعونه وهو لا يتعلق حتى بالمشروع الحالي (أعلم أن هذا صعب مع المواعيد النهائية ولكن حاول القيام بذلك).

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

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

إذا حافظت على الأمور إيجابية ومنظمة، فعادةً ما تكون هذه تجربة رائعة.

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

Answer 4

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

Answer 5

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

لكن منذ ذلك الحين شاركت في الكثير من مراجعات التعليمات البرمجية خارج الإنترنت.

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

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

يستخدم المشروع الرابع مخططًا مفروضًا للمراجعة "في وقت عشوائي" ولم يقم القادة الفنيون بإدخاله بعد (فريق معطل؟)

---

الممارستان اللتان تصفهما هما نهجان رسميان.أنها لا تعمل بشكل جيد لجميع الشخصيات والمجموعات.

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

بمجرد أن تضع عينًا إضافية على الكود الخاص بك، فلن ترغب في الرجوع إلى الوراء

Answer 6

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

• هناك فوائد محددة لمراجعة الكود كما أثبتت العديد من الدراسات.بالنسبة لشركتنا، كان من الواضح أن جودة التعليمات البرمجية زادت مع انخفاض عدد مكالمات الدعم وانخفاض عدد الأخطاء المبلغ عنها أيضًا.ملحوظة:بعض الفوائد هنا كانت نتيجة تنفيذ Scrum والتخلي عن Waterfall.المزيد عن سكروم أدناه.

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

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

سكرومإحدى فوائد استخدام منهجية Scrum هي أن دورة التطوير ("Sprint") قصيرة.يتم تحديد الإطار الزمني لـ "Sprint" حسب ما يناسب مؤسستك وسيحتاج إلى بعض التجربة والخطأ، ولكن في الواقع لا ينبغي أن يكون أطول من أربعة أسابيع من التكرار.وتتمثل الفائدة في أنه يتطلب من المطورين التواصل يوميًا وإبلاغ المشكلات في وقت مبكر من المشروع.تم اعتماد هذا في البداية من قبل قسم التطوير لدينا وانتشر إلى جميع مجالات شركتنا نظرًا لأن فوائد سكروم بعيدة المدى.لمزيد من المعلومات، راجع: http://en.wikipedia.org/wiki/SCRUM أو http://www.scrumalliance.org/ .نظرًا لأن تكرارات التطوير أصغر، فإن عملية مراجعة التعليمات البرمجية تقوم بمراجعة أجزاء أصغر من التعليمات البرمجية، مما يجعل المراجعة أكثر عرضة للعثور على مشكلات مقارنة بساعات أو أيام من المراجعات الرسمية.

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

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

Answer 7

تحليل مقارن بعد الانتقال إلى مراجعات العلاقات العامة على جيثب من البرمجة الزوجية.

ينصب التركيز على سرد ما تتبعه فرقنا الآن خطوة بخطوة في عملية مراجعة العلاقات العامة.

"مراجعات الكود مقابل البرمجة الزوجية" https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926