استعراض قانون وغالبا ما تسبب الجدل. في إعداد المحاضرة ،
"نحن نتخلص من السلوك السام في مراجعة الكود" في مؤتمر
AlterConf ، كنت مستعدًا لسماع مجموعة من الاعتراضات والانتقادات. لكنها لم تتوقع أن يدعم المجتمع الفكرة كثيراً. لقد افترضت المقاومة ، لكن المجتمع استقبلني ووافق عليه جيدًا.
لقد طُلب مني مشاركة
الشرائح ، لكن الآن اعتقدت أن الشرائح نفسها كانت ذات فائدة قليلة وتم إخراجها من السياق: فهي تفتقر إلى التفسيرات. لذلك ، قررت نشر هذا المقال. في وقت لاحق ، قام منظمو المؤتمر بتحميل
فيديو .
المدرجة أدناه هي بعض أنواع سلوكيات مراجعة التعليمات البرمجية غير المنتجة والتوصيات حول كيفية جعل العملية أكثر سهولة وإزالة السمية. تم اختبار جميع النماذج السلوكية إما عن طريقي أو في شركة معروفة لي. في الماضي ، كانت هذه الذنوب تُحضر لي أيضًا.
السلوك غير المنتج رقم 1: توصيل الرأي كحقيقة
لا تقم بالإدلاء ببيانات إذا لم تتمكن من الرجوع إلى الوثائق والتوصيات الرسمية وأمثلة التعليمات البرمجية لدعم هذه العبارات. يجب أن يعرف الناس سبب مطالبتهم بإجراء تغييرات ، والتفضيلات الشخصية لمطور آخر ليست حجة جيدة بما فيه الكفاية.
بدلا من القول:
يجب أن يكون هذا المكون بدون جنسية.
... من الأفضل توفير بعض السياق:
نظرًا لأن هذا المكون لا يحتوي على أساليب دورة حياة أو حالة ، يمكن جعله بلا جنسية. سيؤدي ذلك إلى تحسين أداء التعليمات البرمجية وسهولة القراءة. * هنا * بعض الوثائق.
غالبًا ما يتم نقل الرأي كحقيقة في مناقشات الأسلوب والبناء. هذه موضوعات مهمة حقًا ، ولكن ليس لمراجعات الكود ، لأن الأسلوب وبناء الجملة لا علاقة لهما بالمشكلة التي يحلها المطور في البداية.
من الأفضل إجراء مثل هذه المناقشات بشكل منفصل وتحديد أسلوب الفريق بأكمله. تنفيذ
إصلاحات linter و
رمز التلقائي . سوف تشير بعد ذلك إلى توصيات الأسلوب هذه ، وليس إلى رأيك الشخصي.
من المهم بشكل خاص عدم إبداء رأيك كحقيقة إذا كان لديك رتبة وسلطة أعلى في فريق أو شركة. لدى المطور انطباع بأنه ليس لديه خيار سوى تلبية متطلباتك بشكل مطيع.
السلوك غير المنتج # 2: سيل من التعليقات
عندما يرتكب شخص ما خطأ ، هناك فرصة جيدة لحدوث هذا الخطأ في عدة أماكن. لقد لاحظت أن المراجعين يشيرون في بعض الأحيان إلى كل حالة من الحالات بدلاً من ترك ملاحظة واحدة مفصلة مع روابط لمصادر مفيدة.
يتيح لك دمج التعليقات إرسال الرسالة نفسها دون كبح المؤلف. إن سلسلة من
التعليقات المكررة على قضية واحدة تبدو وكأنها نيتبيكينج.
غير منتجة و ساحقة:
تعليقات متعددة لخطأ واحد متكرر (مسافات في نهاية السطر)خيار أكثر فائدة:
ردود الفعل الموحدةأستطيع أن أفهم أنه من المفيد في بعض الأحيان الإشارة إلى كل مكان من أماكن الخطأ ، لأن التعليق يختفي عند تصحيحه في الالتزامات اللاحقة. ولكن إذا حدث الخطأ عدة مرات ، فمن الواضح أن المطور لم يكن على دراية بدليل محدد ، وعليه فقط الإشارة إلى الموارد المناسبة.
السلوك غير المنتج رقم 3: اطلب من المهندسين حل مشاكل الآخرين "أثناء وجودهم هنا"
لا تطلب من المطورين التعامل مع المشكلات التي لا تتعلق مباشرةً بمجموعة التغييرات أو المشكلة التي يحاول حلها هذا الرمز. حتى إذا قام المطور بتوسيع أو تعديل التعليمات البرمجية المتسخة مع وفرة من الممارسات السيئة ، لا تطلب منه تنظيف وإصلاح هذا الرمز الغريب.
لا أقترح حرمان المطورين من مسؤولية الكود لمجرد أنهم لم يكتبوا في البداية. في الحقيقة ، ليس من الجيد قول شيء مثل "رمز شخص آخر ليس مشكلتي". من الأنسب إنشاء تذكرة منفصلة وسحب طلب لإصلاح الكود القذر. وبالتالي ، يمكنك تجنب زيادة حادة في حجم عمل شخص ما ، وحل مشكلة الديون الفنية.
TL ؛ DR : لا تطلب من المطور إصلاح المشكلات "أثناء وجودها هنا." إذا كان الكود يقوم بما هو مطلوب في التذكرة ولم يقدم مشاكل جديدة في قاعدة الكود ، قم بالموافقة عليها ، ثم قم بإنشاء بطاقة لمسح قاعدة الكود.
السلوك غير المنتج # 4: طرح أسئلة إدانة
تجنب طرح إدانة أسئلة مثل هذا:
لماذا لم تفعل فقط ____ هنا؟
هذا يعني أن بعض الحلول البسيطة يجب أن تكون واضحة. هذا يفرض المطور للدفاع عن أنفسهم.
في كثير من الأحيان هذه الأسئلة إدانة هي مجرد مطالب محجبة. بدلاً من ذلك ، قدم توصية (مع الوثائق والروابط) ، مع حذف الكلمات القاسية.
يمكنك أن تفعل ____ ، والتي لديها ميزة ____.
السلوك غير المنتج رقم 5: السخرية
لا يوجد مكان للسخرية في الاستعراضات. وكقاعدة عامة ، لا توفر التعليقات الساخرة السياق والتعليقات الفعالة. بدلاً من ذلك ، قم بوصف المشكلة بالتفصيل وتقديم التوصيات ، لكن اترك النكات الكاوية جانباً.
نتائج عكسية:
هل قمت حتى اختبار هذا الرمز قبل تقديم؟
ومن المفيد ل:
عدم إدخال رقم سالب. هل يمكن أن تفعل هذا من فضلك؟
في ما يلي
مثال للتعليق في مراجعة الكود غير مضحك ولا مفيد:
نحن لسنا شر ، نحن بلا رحمة. كما ترون ، كتبت "صفير!" - عند استيراد كل ملف تلمسه. لقد كان في ذهني ما يلي: "استيرادك ينتهك اصطلاحنا المعتاد ، والذي يفترض مسبقًا ترتيبًا معينًا: أولاً ، الوحدات النمطية المضمّنة ، ثم الطرف الثالث ، ثم مستوى المشروع" ، لكن هذه العبارة طويلة جدًا بحيث لا يمكن كتابتها في كل حالة.
في المثال أعلاه ، "صفير!" - تماما ليست مفيدة وغير هادفة. هذا هو الفكاهة المتحيزة التي لا تساعد المؤلف.
السلوك غير المنتج # 6: تعبيري بدلاً من وصف المشكلة
عند الإشارة إلى مشاكل في الكود ، تجنب المشاعر مع الإبهام لأسفل أو الرموز التعبيرية مع رجل صغير مريض. أنها عديمة الفائدة مثل السخرية ، لنفس الأسباب. رموز تعبيرية غامضة وسهلة التفسير الخاطئ. يضيع الناس الوقت في محاولة لفهم أفكارك.
لا تستخدم الرموز التعبيرية للإشارة إلى مشاكل الترميزفي أي حال ، يجب أن لا يكون لديك رد فعل عاطفي لأخطاء البرمجة.من الطبيعي جدًا استخدام الرموز الإيجابية ، مثل "الإبهام" أو "الهتافات!" ، ولكن ليس للإشارة إلى المشكلات ، ولكن كرد فعل على رمز جيد.
المشاعر الموافقة كبيرةالسلوك غير المنتج # 7: لا تستجيب لجميع التعليقات
يساهم المؤلفون أيضًا في سمية المناقشة. إذا قمت بضم الكود دون الإجابة على جميع التعليقات ، فهذا أمر يثير الدهشة بالنسبة للشخص: لقد حاول مساعدتك ، وتوضح أن بعض المراجعات لا تهم.
إذا كان التعليق غير ذي صلة أو لن تتخذ أي إجراء ، فما عليك سوى شرح السبب بإيجاز.
لا تتجاهل الزملاء.
الجمع بين التعليمات البرمجية دون الرد على تعليقالسلوك غير المنتج # 8: تجاهل السلوك السام إذا كان يأتي من أفضل المتخصصين
لا ينبغي تجاهل السلوك السام أو التقليل من أهميته لمجرد أن المطور هو محترف ممتاز وموظف منتج للغاية. على الرغم من قيامه بعمل رائع ، إلا أنه من المهم أن يتذكر أن سلوكه السام يؤدي إلى إجهاد وتطور مطورين آخرين.
تجربة مع شخص يظهر سلوكًا سامًا:
سيجد آخرون أن العمل مع هذا الشخص يستنزف ويزيد من ثقته. سيفعلون أي شيء لتجنب التفاعل معه ، حتى لو كان يؤثر سلبًا على قدرتهم على أداء المهام. سيتم تعطيل الاتصالات في جميع أنحاء المنظمة ، وسيبدأ الموظفون في البحث عن وظائف في أماكن أخرى. بينما تواجه عواقب استنزاف المواهب والمشاريع غير الناجحة ، سيواصل هذا المطور المحدد العمل بهدوء كما لو لم يحدث شيء. - جوزيف جيفرو
إذا لم يتم اتخاذ خطوات لتصحيح الموقف ، فستكون هناك عواقب وخيمة: سيتم تحميل المطورين بشكل كبير ومهاجمتهم وتخفيض عددهم. سيبدأون في الخوف من ردود الفعل ، والتي في الواقع ستساعدهم على النمو.
شعرت شخصيًا بالقلق الشديد عندما تلقيت بريدًا إلكترونيًا يتضمن تعليقات على طلب السحب من زميل سابق (معروف بمراجعاته السامة وغير المفيدة). على الرغم من أن السلوك السام يؤثر على الجميع بشكل مختلف ، ولكن بالتأكيد لا أحد يستفيد من هذه السمية.
ملاحظة : أريد أن أوضح أنه إذا لم يتمكن المطور من مقاومة وأظهر مثل هذا السلوك ذات مرة ، فإن هذا لا يجعله "سامًا". نحن نتحدث عن الإهانات المتكررة والتعليقات الكاوية.
ممارسات مراجعة التعليمات البرمجية مفيدة
فيما يلي بعض التوصيات التي تنطبق على أي اتصال عادي ، رغم أننا نتحدث هنا في سياق البرمجة ومراجعات التعليمات البرمجية.
السلوك المفيد # 1: استخدم الأسئلة أو التوصيات لبناء الحوار
لا تطلب أبدًا من الأشخاص إجراء تصحيحات أو طرح أسئلة مرفوضة ، لأن هذا يتعارض مع الحوار بينك وبين الشخص الآخر.
لماذا لم تجمع بين هذه التحويلات في ملف وثوابت؟
من الناحية الرسمية ، هذا سؤال ، لكنه لا يخلق حوارًا بينك وبين المحاور. هو فقط يجعله يدافع عن نفسه. بدلاً من ذلك ، اسأل عن رأي الشخص الآخر في قرارك ، على سبيل المثال:
ما رأيك في سحب هذه التحويلات إلى ملف ثابت؟ يوجد الكثير منهم ، لذلك قد يكون الملف المنفصل منطقيًا في الوقت الحالي.
... أو قدم توصية:
في هذا الملف ، لديك العديد من مكالمات الترجمة لـ "الدالة x". قد يكون من المنطقي إنشاء ملف منفصل مع ثوابته.
السلوك المفيد # 2: تعاون ، لا تخفيه
عندما تقوم بالبرنامج معًا ، يجب أن تكون موجودًا وطرح الأسئلة ومناقشة الموارد والإشارة إليها.
"... عندما تريد المساعدة أو العمل معًا ، يجب أن تكون مشاركًا بالكامل ، وليس فقط التدخل في بعض الأحيان" - Recurse Center Guide
سلوك مفيد # 3: الرد على كل تعليق
إذا كنت لا تخطط كمؤلف لتطبيق نصيحة المراجع ، فما عليك سوى تقديم ملاحظة عن طريق الإبلاغ عنها. لا تتجاهل أولئك الذين يأخذون الوقت الكافي لمساعدتك.
على سبيل المثال:
الشخص أ: - ما رأيك في إنشاء وظيفة مساعدة لنداء API هذا؟ خلاف ذلك ، كل شيء على ما يرام.
الشخص ب: - هذا الخط لم يكن جزءًا من مجموعة التغييرات الخاصة بي. سوف أقوم بدمج الكود ، وأنشئ تذكرة منفصلة على جيثب وأكتبها في خطة العمل لمجموعتنا.
السلوك المفيد رقم 4: معرفة متى يتم ترتيب اجتماع وجهاً لوجه
بعد عشرات التعليقات والحلول المقترحة ، يجب أن يكون واضحًا أن الاتصال عبر الإنترنت أصبح غير مثمر للمشكلة المطروحة. إرسال دعوة اجتماع لجميع زملائك المعنيين.
وبالتالي ، ستكون المجموعة قادرة على اتخاذ قرار بسرعة وتطبيقه.
عادة ما يمكن حل المشكلات التي تستغرق ساعات وأطنان من التعليقات في بضع دقائق من المحادثة المثمرة. - "جافا أنيق"
سلوك مفيد # 5: استخدام فرص التعلم وعدم إظهار
قبل المشاركة في مراجعة الكود ، اسأل نفسك:
هل تعليقك يساعدك حقًا على التعلم أم أنك تجد خطأ؟
فكر في تعليقك. تذكر أن الهدف من مراجعة الكود هو تعليم ومساعدة المطورين الآخرين على النمو. هذه ليست منصة للأداء.
سلوك مفيد # 6: لا تظهر مفاجأة
يجب الحرص على عدم إظهار مفاجأة إذا كان الشخص لا يعرف شيئا. لا تزعج الأشخاص الذين ينبغي عليهم معرفة هذه المعلومات بالفعل. على العكس ، لا تتردد في الاعتراف بأنك تفتقر إلى الخبرة في هذا الموضوع - فهذه طريقة رائعة لطلب المساعدة.
راجع قاعدة
"لا تتظاهر بالدهشة" في البرنامج التعليمي لمركز Recurse للحصول على مزيد من المعلومات.
السلوك المفيد # 7: أتمتة كل ما تستطيع
من غير المنطقي مناقشة الأخطاء التي يمكن أن يكتشفها الأشباح أو السنانير Git أو الاختبارات الآلية. هذا هو طن من التعليقات الإضافية التي تبدو وكأنها نيتبيكينج. الناس ليسوا جيدين في تحديد مثل هذه الأخطاء ، وبالتالي تم إنشاء أدوات التشغيل الآلي.
هناك أيضًا أدوات لتشغيل الاختبارات تلقائيًا عند إضافة رمز جديد. يعرضون تحذيرات إذا كانت مجموعة من التغييرات تنتهك أحد الاختبارات. على سبيل المثال ، TeamCity و Jenkins CI.
أيضا ، استخدم السنانير Git لتشغيل الاختبارات ولاعة على التعليمات البرمجية الجديدة. سوف يعترضون الالتزام إذا وجدوا أخطاء.
دع الأداة تشير إلى المشكلات ، حتى لا يضطر الأشخاص إلى ذلك.السلوك المفيد # 8: لا تتخطى السلوك السام
ليست هناك حاجة إلى تبني سلوك سام في مراجعة الشفرة الخاصة بك ، لأنه يبدو وكأنه الانتقام أو بعض الطقوس الضارة للمطورين الجدد.
ابحث عن زملائك الذين سيدعمونك.
إذا لاحظت وجود ملاحظات غير مثمرة على الكود ، فحاول أن تخبر زميلًا ، وتحدث مباشرةً وبصراحة (إذا كنت تشعر بالأمان في وضعك / شركتك).
السلوك المفيد رقم 9: المدراء ، والنظر بعناية في المرشحين ، والاستماع إلى الفريق واستخدام سلطتك
يتمتع المديرون بفرص رائعة لخلق جو إيجابي ومناسب في الفريق.
نعيد صياغة النصائح من المقال
"ضار بالمطورين السامين" :
- منع المطورين السامة من الظهور في الفريق. عند التوظيف ، انتبه ليس فقط للتدريب التقني. تعرف على كيفية تعاون المرشح والتواصل معه. تحليل نقدي عمله ونرى كيف يتفاعل. تأكد من أن كل مرشح يعمل على تحسين ثقافة الشركة ، ولا يناسبها فقط.
- عندما لا يزال مطور سامة يدخل الدولة أو يرث ، اطلب من كل موظف إبداء الرأي حول ذلك في محادثة شخصية. إذا كان المطور سامًا ، فسيظهر في مراجعات عنه.
- التحدث مع مطور سامة. أعط أمثلة محددة للتعليقات الفعالة في مراجعة الكود. العمل باستمرار معه ، والاستمرار في جمع المعلومات في محادثات شخصية مع زملائه ومديره.
- لا تعزل المطور السام. (*)
- كرر الموظفين حول الحاجة إلى بيئة ودية.
(*) على الرغم من أن المقالة تقترح عزل المطورين السامين ، إلا أنني أعتبر أنه من المهم تشجيع المطور السام على العمل مع الفريق ، ولكن بطرق أكثر صحة. العزل لن يحل المشكلة. إذا منحتها وظيفة منفصلة ، فستقل السمية على المدى القصير ، لكن المطور لن يتخلى عن سلوكه غير المنتج. سوف يفقد المنصة فقط لإثبات ذلك.
السلوك المفيد # 10: اضبط المعيار بينما الفريق صغير ومتزايد
الفرق الصغيرة قادرة على قبول الأفكار الجديدة وتنفيذها. حتى لو كنت لا ترى أنه من الضروري وضع معايير ، لأنه لا توجد مشاكل الآن ، ولكن من المهم الحفاظ على ممارسات التعاون الجيدة عند وصول التجديد.
السلوك المفيد # 11: افهم أنه يمكنك أن تكون جزءًا من المشكلة
لخلق بيئة أكثر ملاءمة ، من المهم أن تكون صادقًا مع نفسك وأن تفكر في أي سلوك غير فعال.
بصفتي مبتدئًا ، لاحظت وجود خطأ في رمز شخص ما عدة مرات وكنت سعيدًا ، لأنني أستطيع ترك تعليق! الآن أفهم أنني استخدمت هذه الفرصة للتفاخر ، وليس مساعدة. تحتاج إلى تقييم بعناية أفعالك.
أعتقد أنه من المفيد للجميع قضاء بعض الوقت في هذا التأمل الصعب.
وآخر ...
نحن لا نتحدث عن محتوى المراجعات ، ولكن فقط عن النغمة
أعلم أن المراجعات مهمة ، ونحن لا نقاتل ضدهم. أنا لا أطلب منك المساومة على جودة الكود. لا ينبغي أن تكون الثقافة المحسنة لمراجعة الكود والجودة العالية للكود حصريًا بشكل متبادل.
آمل فقط أن يتخذ الأشخاص خطوات لتقديم تعليقات بناءة وفعالة وخلق ظروف أكثر ملاءمة يشعر فيها المطورون بالراحة والتعلم والنمو وعدم الخوف من ارتكاب الأخطاء. يمكننا جميعا تحسين معا.