من وثائق الممارسات الهندسية من Googleيوفر هذا الدليل أفضل الممارسات لإجراء مراجعات الكود استنادًا إلى سنوات الخبرة. معا ، يشكلون وثيقة واحدة ، مقسمة إلى عدة أقسام. ليس من الضروري أن تقرأها جميعًا ، ولكن غالبًا ما يكون من الأفضل لك وللفريق أن يدرس الدليل بالكامل.
انظر أيضًا
دليل مؤلف CL للحصول على المشورة التفصيلية حول المطورين الذين تتم مراجعة التزاماتهم.
كود مراجعة قياسي
الغرض الرئيسي من مراجعة الكود هو ضمان التحسين المستمر لقاعدة تشفير Google. جميع الأدوات والعمليات مكرسة لتحقيق هذا الهدف.
هناك حاجة إلى عدد من الحلول الوسط هنا.
أولاً ، يجب أن يكون المطورون قادرين على
حل مشكلاتهم بنجاح. إذا لم ترسل رمزًا أبدًا ، فلن تتحسن قاعدة الشفرة أبدًا. بالإضافة إلى ذلك ، إذا كان المراجع يعقد
أي عمل بشكل كبير ، فعندئذ في المستقبل ، لا يهتم المطورون باقتراح التحسينات.
من ناحية أخرى ، تقع على عاتق المراجع مسؤولية التأكد من أن جودة CL لا تقلل من الجودة الشاملة لقاعدة الكود بمرور الوقت. قد يكون هذا الأمر صعبًا ، لأن التدهور يحدث غالبًا بسبب انخفاض طفيف في جودة الشفرة بمرور الوقت ، خاصةً إذا كان الفريق تحت ضغط شديد من المواعيد النهائية ويشعر أنه يحق له زيادة الدين التقني.
بالإضافة إلى ذلك ، يكون المراجع مسؤولاً عن الرمز الذي تتم مراجعته. إنه يريد التأكد من أن قاعدة الشفرة تظل متسقة ومدعومة ومطابقة لكل شيء آخر مذكور في قسم
"ما الذي يجب عليك التحقق منه" .
وبالتالي ، نحصل على القاعدة التالية كمعيار لمراجعة الكود:
عادةً ، يجب أن يعتمد المراجعون CL بمجرد وصولها إلى حالة حيث تعمل بالتأكيد على تحسين الجودة الشاملة لرمز النظام ، حتى لو كانت CL غير مثالية.هذا هو مراجعة الكود
الرئيسي بين جميع المبادئ.
بالطبع ، لديه قيود. على سبيل المثال ، إذا أضاف CL وظيفة لا يرغب المراجع في رؤيتها في النظام ، فيمكن للمراجع بالتأكيد رفض الالتزام ، حتى إذا كانت الكود بجودة جيدة.
النقطة الأساسية هنا هي أنه لا يوجد كود "مثالي" - لا يوجد سوى رمز
أفضل . يجب ألا يطلب المراجع من المؤلف تلميع كل جزء صغير. بدلاً من ذلك ، يجب على المراجع الموازنة بين الحاجة إلى مزيد من التقدم بشأن أهمية التغييرات المقترحة. بدلاً من السعي لتحقيق المثل الأعلى ، يجب على المراجع السعي
للتحسين المستمر . لا يمكن تأخير الالتزام ، الذي يحسن عمومًا من قابلية الصيانة وقابلية القراءة وشمول النظام ، لأيام أو أسابيع لأنه ليس "مثاليًا".
يمكن للمراجعين
دائمًا ترك أي تعليقات على تحسين الشفرة ، ولكن يجب وضع علامة على التغييرات غير المهمة ، على سبيل المثال ، مع بادئة
Nit: بحيث يعلم المؤلف أن هذه مجرد وجهة نظر يمكنه تجاهلها.
المذكرة. لا يوجد في هذا المستند ما يبرر CLs التي
تقلل بالتأكيد
من الجودة الشاملة لرمز النظام. هذا ممكن فقط في
حالات الطوارئ .
التوجيه
يمكن أن تكون مراجعة الكود مهمة أيضًا لتعليم المطورين شيئًا جديدًا عن اللغة أو الهيكل أو المبادئ العامة لتصميم البرامج. من الجيد دائمًا ترك التعليقات التي تساعد المطور على تعلم شيء جديد. تبادل المعرفة يساهم في تحسين رمز النظام مع مرور الوقت. فقط ضع في اعتبارك أنك إذا تركت تعليقًا تعليميًا خالصًا ليس ضروريًا للوفاء بالمعايير الموضحة هنا ، فأضف بادئة
Nit إليه
: أو أشير إلى أن المؤلف غير ملزم بالسماح بذلك.
مبادئ
- الحقائق الفنية والبيانات تفوق الآراء والتفضيلات الشخصية.
- في مسائل الأسلوب ، السلطة المطلقة هي دليل الأسلوب . أي تفاصيل أسلوبية بحتة (فراغ ، وما إلى ذلك) لا يتم تضمينها في دليل الأنماط هي مسألة تفضيل شخصي. يجب أن يتطابق الأسلوب مع ما هو عليه. إذا لم يكن هناك نمط سابق ، اقبل المؤلف.
- إن جوانب تصميم البرنامج لا تكاد تكون أبدًا مسألة ذات طابع خالص أو تفضيل شخصي. وهي تستند إلى مبادئ أساسية ويجب أن تحددها هذه المبادئ ، وليس فقط الرأي الشخصي. في بعض الأحيان هناك عدة خيارات صالحة. إذا كان بإمكان المؤلف إثبات (إما باستخدام بيانات أو استنادًا إلى مبادئ هندسية صلبة) أن بعض الأساليب تكون متساوية في الفعالية ، يجب على المراجع قبول تفضيل المؤلف. خلاف ذلك ، فإن الخيار تمليه مبادئ التطوير القياسية.
- إذا لم تكن هناك قاعدة أخرى قابلة للتطبيق ، فيجوز للمراجع أن يطلب من المؤلف ملاحظة التماثل مع قاعدة الشفرة الحالية ، إذا كان هذا لا يؤدي إلى تفاقم الحالة العامة للنظام.
حل النزاع
في أي تعارض ، يجب أن تكون الخطوة الأولى دائمًا رغبة المطور والمراجع في التوصل إلى توافق في الآراء بناءً على محتويات هذا المستند والمستندات الأخرى في
دليل مؤلف CL ودليل المراجع هذا.
عندما يكون الوصول إلى توافق في الآراء أمرًا صعبًا بشكل خاص ، يمكن أن يساعد الاجتماع الشخصي أو مؤتمر الفيديو بين المراجع والمؤلف (إذا كنت تفعل ذلك ، تأكد من كتابة نتائج المناقشة في تعليق على الالتزام للقراء المستقبليين).
إذا لم يحل هذا الموقف ، فإن الطريقة الأكثر شيوعًا هي التصعيد. غالبًا ما يكون ذلك في مناقشة أوسع مع الفريق ، واجتذاب قيادة الفريق ، أو الاتصال بمشرف الصيانة أو مدير التطوير. لا تدع الالتزام يظل قائماً بسبب حقيقة أن المؤلف والمراجع لا يمكن أن يتوصلا إلى اتفاق.
ما للتحقق في التعليمات البرمجية
المذكرة. عند النظر في كل عنصر من هذه العناصر ، تأكد من النظر في
مراجعة الكود القياسي .
تصميم
الشيء الأكثر أهمية هو النظر في المشروع العام (التصميم) في مراجعة الكود. هل التفاعلات بين أجزاء مختلفة من الكود منطقية؟ هل ينطبق هذا التغيير على قاعدة البيانات أو المكتبة الخاصة بك؟ هل CL تتكامل بشكل جيد مع بقية النظام؟ هل حان الوقت لإضافة هذه الوظيفة الآن؟
وظائف
هل هذا CL تفعل ما المقصود المطور؟ هل هو جيد لمستخدمي هذا الرمز؟ نعني بكلمة "المستخدمين" المستخدمين النهائيين (إذا تأثروا بالتغيير) والمطورين (الذين سيتعين عليهم "استخدام" هذا الرمز في المستقبل).
بشكل أساسي ، نتوقع أنه حتى قبل الالتزام ، سيقوم المطورون باختبار التعليمات البرمجية الخاصة بهم بشكل جيد بما يكفي لكي يعمل بشكل صحيح. ولكن كمراجع ، لا تزال بحاجة إلى التفكير في الحالات القصوى ، والبحث عن مشاكل التزامن ، ومحاولة التفكير كمستخدم ، وحتى مشاهدة أثناء قراءة التعليمات البرمجية التي لا توجد أخطاء واضحة.
إذا كنت تريد ، يمكنك التحقق من الأداء. هذا مهم للغاية إذا كان الرمز يؤثر على المستخدمين ، مثل
تغيير واجهة المستخدم . من الصعب أن نفهم كيف ستؤثر بعض التغييرات على المستخدمين عندما تقرأ الكود. لمثل هذه التغييرات ، يمكنك أن تطلب من المطور تقديم عرض توضيحي إذا كان من الصعب عليك الدخول في الشفرة وتجربتها بنفسك.
هناك نقطة أخرى عندما يكون من المهم بشكل خاص التفكير في الوظيفة أثناء مراجعة التعليمات البرمجية وهي حدوث نوع من
البرمجة المتوازية في CL ، والتي من الناحية النظرية يمكن أن تسبب الجمود أو ظروف السباق. يصعب اكتشاف مثل هذه المشكلات بمجرد تشغيل الكود ؛ عادة ما يكون من الضروري أن يفكر شخص ما (المطور والمراجع) بعناية وتأكد من عدم ظهور أي مشكلات (لاحظ أن هذا سبب وجيه أيضًا لعدم استخدام نماذج التوازي حيث تكون ظروف السباق أو الجمود ممكنة - يمكن القيام بذلك عن طريق الكود من الصعب جدا فهم أو مراجعة الرمز).
تعقيد
هل CL أكثر تعقيدًا مما ينبغي؟ التحقق من ذلك في كل مستوى: خطوط منفصلة ، وظائف ، والطبقات. "التعقيد المفرط" يعني عادة
عدم القدرة على الفهم السريع أثناء القراءة . قد يعني أيضًا أن
المطورين هم أكثر عرضة لتقديم أخطاء عند محاولة الاتصال أو تعديل هذا الرمز .
هناك نوع خاص من التعقيد هو الهندسة الزائدة ، عندما يكون المطورون قد جعلوا الكود أكثر عالمية مما ينبغي ، أو إضافة وظائف لا يحتاجها النظام حاليًا. يجب أن يكون المراجعون متيقظين بشكل خاص بشأن الهندسة الزائدة. شجع المطورين على حل مشكلة يجب بالتأكيد حلها الآن ، بدلاً من مشكلة قد تحتاج إلى حل في المستقبل. يجب حل مشكلة مستقبلية عند ظهورها ، ويمكنك أن ترى شكلها ومتطلباتها الفعلية في الكون المادي.
اختبارات
طلب وحدة أو تكامل أو اختبارات شاملة ذات صلة بالتغيير. بشكل عام ، يجب أن تضاف الاختبارات إلى نفس CL مثل رمز الإنتاج إذا كانت CL لا تعالج
حالة الطوارئ .
تأكد من أن الاختبارات صحيحة ومعقولة ومفيدة. الاختبارات لا تختبر نفسها ، ونادراً ما نكتب اختبارات لاختباراتنا - يجب على الشخص التأكد من أن الاختبارات صالحة.
هل تفشل الاختبارات حقًا في الشفرة المكسورة؟ إذا تغيرت الكود ، فهل سيكون هناك ايجابيات كاذبة؟ هل يقدم كل اختبار عبارات بسيطة ومفيدة؟ هل تنقسم الاختبارات بشكل صحيح بين طرق الاختبار المختلفة؟
تذكر أن الاختبارات هي رمز يجب دعمه أيضًا. لا تسمح بالتعقيد فيها لمجرد أنه ليس جزءًا من الملف الثنائي الرئيسي.
ترشيح
هل اختار المطور أسماء جيدة في كل مكان؟ الاسم الجيد طويل بما يكفي لنقل ما هو العنصر أو ما يفعله بشكل كامل ، دون أن يكون طويلاً بحيث يصعب قراءته.
تعليقات
هل قام المطور بكتابة تعليقات واضحة بلغة واضحة؟ هل جميع التعليقات ضرورية؟ عادةً ما تكون التعليقات مفيدة عندما تشرح سبب وجود رمز ما ، ويجب ألا تشرح ما يفعله هذا الرمز. إذا كانت الشفرة غير واضحة بما يكفي لتوضيح نفسها ، فيجب تبسيطها. هناك بعض الاستثناءات (على سبيل المثال ، التعليقات التي تشرح تصرفات الكود غالبًا ما تكون مفيدة جدًا للتعبيرات العادية والخوارزميات المعقدة) ، ولكن في الغالب تكون التعليقات مخصصة للمعلومات التي لا يمكن أن تحتوي عليها الكود نفسه ، على سبيل المثال ، إثبات القرار.
قد يكون من المفيد أيضًا النظر إلى التعليقات في الكود السابق. ربما يكون هناك TODO ، والذي يمكن حذفه الآن ، أو تعليق لا يوصي بإدخال هذا التغيير ، إلخ.
لاحظ أن التعليقات تختلف عن
الوثائق الخاصة بالفئات أو الوحدات النمطية أو الوظائف ، والتي تصف مهمة التعليمات البرمجية وكيفية استخدامها وكيفية سلوكها.
أسلوب
لدينا
أدلة أسلوب Google لجميع اللغات الرئيسية ، وحتى معظم اللغات الثانوية. تأكد من عدم تعارض CL مع أدلة الأنماط ذات الصلة.
إذا كنت ترغب في تحسين بعض العناصر غير الموجودة في دليل الأنماط ، فأضف ملاحظة إلى التعليق (
Nit :) . سيعرف المطور أن هذه ملاحظتك الشخصية ، وهي ليست ملزمة. لا تحظر إرسال التعيينات بناءً على تفضيلاتك الشخصية فقط.
يجب ألا يجمع المؤلف بين تغييرات النمط المهمة والتغييرات الأخرى. هذا يجعل من الصعب رؤية التغييرات في CL ، ويعقد عمليات الدمج ، واستعادة التعليمات البرمجية ، ويسبب مشاكل أخرى. على سبيل المثال ، إذا أراد المؤلف إعادة تنسيق الملف بالكامل ، فاطلب تغيير النمط في CL واحد ، ثم أرسل CL مع تغييرات وظيفية.
الوثائق
إذا غيّرت مخرجات CL شيئًا ما في التجميع أو الاختبار أو إجراءات التفاعل أو إصدار الكود ، فتأكد من وجود تحديثات للوثائق ذات الصلة ، بما في ذلك ملفات README وصفحات g3doc وجميع المستندات المرجعية التي تم إنشاؤها. إذا أزالت CL الشفرة أو جعلتها قديمة ، فكر في إزالة الوثائق أيضًا. إذا كانت الوثائق مفقودة ، اطلب إنشائها.
كل صف
عرض
كل سطر في الكود. على الرغم من أنه يمكن مراجعة أي ملفات بيانات أو تعليمات برمجية تم إنشاؤها أو بنيات بيانات كبيرة لفترة وجيزة ، ولكن يجب قراءة كل فئة أو وظيفة أو مقطع تعليمات برمجية يكتبه شخص بعناية ، ولا تفترض أبدًا بشكل افتراضي أن كل شيء على ما يرام. من الواضح أن بعض التعليمات البرمجية تستحق دراسة أكثر شمولية من دراسة أخرى - أنت تقرر ذلك بنفسك ، لكن يجب أن تتأكد على الأقل من أنك
تفهم طريقة تشغيل الشفرة بأكملها.
إذا كان من الصعب عليك قراءة الكود وهذا يؤدي إلى إبطاء المراجعة ، يجب عليك إبلاغ المطور والانتظار حتى يجلب الوضوح قبل المتابعة. في Google ، نقوم بتوظيف مهندسي برامج رائعين ، وأنت واحد منهم. إذا لم تتمكن من فهم الكود ، فمن المحتمل أن المطورين الآخرين لن يكونوا قادرين على ذلك. وبهذه الطريقة ، يمكنك أيضًا مساعدة مطوري المستقبل على فهم هذا الرمز عند سؤال المطور عن الوضوح.
إذا كانت الشفرة مفهومة ، لكنك لا تشعر بأنك مؤهل بدرجة كافية لتقييم جزء معين ، فتأكد من وجود مراجع في CL مؤهل ، خاصة للمشاكل المعقدة مثل الأمان والتزامن وإمكانية الوصول والتدويل وما إلى ذلك.
السياق
من المفيد غالبًا إلقاء نظرة على CL في سياق واسع. عادةً ما تظهر أداة مراجعة الكود بضعة أسطر فقط بالقرب من مكان التغيير. في بعض الأحيان تحتاج إلى إلقاء نظرة على الملف بأكمله للتأكد من أن التغيير منطقي بالفعل. على سبيل المثال ، ترى إضافة أربعة أسطر فقط ، ولكن إذا نظرت إلى الملف بأكمله ، فستكون هذه الأسطر الأربعة في طريقة مؤلفة من 50 سطرًا ، والتي يجب تقسيمها الآن إلى خطوط أصغر.
من المفيد أيضًا التفكير في CL في سياق النظام ككل. هل يحسن جودة رمز النظام أم يجعله أكثر تعقيدًا ، وأقل اختبارًا ، وما إلى ذلك؟
لا تقبل الالتزامات التي تؤدي إلى انخفاض رمز النظام. معظم الأنظمة معقدة بسبب مجموع التغييرات الصغيرة الكثيرة ، لذلك من المهم منع حتى المصاعب البسيطة هناك.
جيدة
إذا رأيت شيئًا جيدًا في الالتزام ، فأعلم المطور ، خاصةً عندما يحل المشكلة الموضحة في أحد تعليقاتك بأفضل طريقة ممكنة. غالبًا ما تركز مراجعات الكود على الأخطاء ، ولكن يجب عليها أيضًا تشجيع الممارسات الجيدة وتقييمها. من وجهة نظر التوجيه ، من المهم في بعض الأحيان إخبار المطور بما فعله بالضبط ، وليس أين ارتكب خطأ.
ملخص
عند تنفيذ مراجعة الكود ، تأكد من:
- رمز مصممة بشكل جيد.
- الأداء الوظيفي جيد لمستخدمي الكود.
- أي تغييرات على واجهة المستخدم معقولة وتبدو جيدة.
- أي البرمجة المتزامنة آمنة.
- الرمز ليس أكثر تعقيدًا مما ينبغي.
- المطور لا ينفذ ما قد يكون مطلوبًا في المستقبل باحتمالات غير معروفة.
- واصطف رمز مع اختبارات وحدة مناسبة.
- الاختبارات مصممة بشكل جيد.
- استخدم المطور أسماء واضحة في كل مكان.
- التعليقات مفهومة ومفيدة ، والإجابة بشكل أساسي على السؤال لماذا؟ لكن ليس ماذا؟
- تم توثيق الكود بشكل صحيح (عادة في g3doc).
- يتوافق الكود مع أدلة أسلوبنا.
أثناء المراجعة ، تأكد من إلقاء نظرة على
كل سطر من التعليمات البرمجية ، وإلقاء نظرة على
السياق ، وتأكد من أنك تقوم
بتحسين جودة الشفرة وتثني على المطورين
للخير الذي تمكنوا من فعله.
CL الملاحة في مراجعة التعليمات البرمجية
ملخص
الآن بعد أن عرفت
ما يجب عليك التحقق منه ، ما هي الطريقة الأكثر فاعلية لإجراء مراجعات الكود على ملفات متعددة؟
- هل هذا التغيير منطقي؟ هل لديه وصف جيد؟
- أول نظرة على الجزء الأكثر أهمية. هل هي مصممة بشكل جيد؟
- انظر إلى بقية CL في التسلسل المناسب.
الخطوة الأولى: إلقاء نظرة حول الالتزام بأكمله
انظر إلى
وصف CL وماذا يفعل بشكل عام. هل هذا التغيير منطقي على الإطلاق؟ إذا لم يكن يجب أن يكون مكتوبًا في البداية ، فيرجى الرد على الفور مع توضيح سبب عدم الحاجة إليه. عندما ترفض هذا التغيير ، من الجيد أيضًا أن تقدم للمطور ما يجب القيام به بدلاً من ذلك.
على سبيل المثال ، قد تقول: "يبدو أنك قمت بعمل جيد ، شكرًا!" ومع ذلك ، سنقوم بالفعل بإزالة نظام FooWidget ، لذلك لا نريد إجراء أي تغييرات جديدة في الوقت الحالي. ما رأيك في إعادة تنظيم صف BarWidget الجديد بدلاً من ذلك؟ "
يرجى ملاحظة أن المراجع لم يرفض CL الحالي فقط وقدم اقتراحًا بديلًا ، ولكنه فعل ذلك أيضًا
بأدب . هذه المجاملة مهمة لأننا نريد أن نظهر أننا نحترم بعضنا البعض كمطورين ، حتى عندما نختلف مع بعضنا البعض.
إذا حصلت على عدد لا بأس به من CLs غير المرغوب فيها ، يجب عليك مراجعة عملية التطوير في فريقك أو القواعد المنشورة للمساهمين الخارجيين لتحسين الاتصال عند كتابة CL. من الأفضل أن تخبر الناس "لا" قبل أن يقوموا بعمل الكثير من الأعمال التي يجب إلقاؤها أو إعادة كتابتها بشدة.
الخطوة الثانية: تعلم الأجزاء الأساسية من CL
حدد موقع الملف أو الملفات التي تمثل الجزء "الرئيسي" من CL. غالبًا ما يكون هناك ملف واحد به أكثر التغييرات منطقية ، وهذا هو الجزء الرئيسي من CL. أول اطلالة له على هذه الأجزاء الرئيسية. يساعد هذا في فهم سياق الأجزاء الأصغر من CL ، ويسرع بشكل عام تنفيذ مراجعة التعليمات البرمجية. إذا كانت CL كبيرة جدًا ، فاطلب من المطور أن يراها أولاً ، أو اطلب منه تقسيم CL إلى أجزاء .إذا رأيت مشاكل خطيرة في الجزء الرئيسي من CL ، فيجب عليك إرسال هذه التعليقات على الفور ، حتى لو لم يكن لديك الوقت الكافي لعرض بقية CL الآن. في الواقع ، قد يكون النظر إلى بقية الكود مضيعة للوقت ، لأنه إذا كانت المشكلات كبيرة بما فيه الكفاية ، فإن العديد من الأجزاء الأخرى من التعليمات البرمجية ستختفي ولن تهم.هناك سببان رئيسيان وراء أهمية إرسال هذه التعليقات الرئيسية على الفور:- غالبًا ما يقوم المطورون بإرسال CL ، ثم يبدأون فورًا وظيفة جديدة بناءً على ذلك ، أثناء انتظار نتيجة مراجعة الكود. إذا كانت CL تعاني من مشاكل خطيرة ، فسيتعين عليها إعادة صياغة CL التالية. يُنصح بتحديد الأخطاء في أقرب وقت ممكن قبل القيام بالكثير من العمل الإضافي بالإضافة إلى التصميم الإشكالي.
- تستغرق التغييرات الرئيسية وقتًا أطول من التعديلات الطفيفة. جميع المطورين تقريبا لديهم مواعيد نهائية. من أجل الحفاظ على داخلها وعدم تقليل جودة الكود ، يجب أن تبدأ عملية إعادة التوطين الرئيسية في أسرع وقت ممكن.
الخطوة الثالثة: التمرير خلال بقية CL بالتسلسل المناسب.
بعد التأكد من عدم وجود مشاكل خطيرة في تصميم CL ككل ، حاول اكتشاف التسلسل المنطقي لعرض الملفات وتأكد من عدم وجود شيء مفقود. عادةً ، عندما تنظر إلى الملفات الرئيسية ، فإن أسهل طريقة هي الانتقال ببساطة إلى الباقي بالترتيب الذي تعرض به أداة مراجعة الكود. من المفيد أيضًا في بعض الأحيان قراءة الاختبارات أولاً ، ثم الرمز الرئيسي ، لأنه عندئذ سيكون لديك فكرة عن معنى التغيير.سرعة مراجعة الكود
لماذا يجب إجراء مراجعة الكود بسرعة؟
في Google ، نقوم بتحسين سرعة التعاون ، وليس سرعة المطورين الفرديين. معدل العمل الفردي هو المهم، ليس فقط باعتبارها أولوية، مقارنة مع سرعة الأوامر.عندما تنظر ببطء إلى الكود ، تحدث عدة أشياء:- . , -, . , , , CL - -.
- -. , , . , «» . (, ), , . - .
- جودة الكود قد تعاني. يؤدي إبطاء مراجعة التعليمات البرمجية إلى زيادة خطر عدم إرسال المطورين CLs الجيدة قدر الإمكان. تعوق المراجعات البطيئة أيضًا تنظيف التعليمات البرمجية وإعادة البناء وإدخال مزيد من التحسينات على CL الموجودة.
كيفية تنفيذ بسرعة مراجعة التعليمات البرمجية؟
إذا لم تكن في منتصف مهمة مركزة ، فيجب عليك إنشاء رمز للمراجعة بعد وقت قصير من وصولها.يوم العمل هو الحد الأقصى لوقت الإجابة (وهذا هو أول شيء في صباح اليوم التالي).باتباع هذه الإرشادات يعني أن CL يجب أن تتلقى عدة جولات من المراجعة (إذا لزم الأمر) في غضون يوم واحد.السرعة والهاء
هناك لحظة واحدة عندما تتجاوز أولوية السرعة الشخصية سرعة الفريق. إذا كنت في منتصف مهمة مركزة ، مثل كتابة التعليمات البرمجية ، فلا تشتت انتباهك عن طريق مراجعة التعليمات البرمجية. أظهرت الدراسات أنه يمكن للمطور أن يستغرق وقتًا طويلاً للعودة إلى تدفق تطوير سلس بعد الهاء. وبالتالي ، فإن التشتيت عن الترميز يكلف الفريق أكثر من مطالبة مطور آخر بالانتظار قليلاً لمراجعة الكود.بدلاً من ذلك ، انتظر نقطة توقف في عملك. على سبيل المثال ، بعد الانتهاء من المهمة الحالية ، بعد الغداء ، العودة من اجتماع ، العودة من مطبخ صغير في المكتب ، إلخ.ردود سريعة
عندما نتحدث عن سرعة مراجعة الكود ، نحن مهتمون بوقت الاستجابة ، وليس كم من الوقت مطلوب للعملية بأكملها حتى النهاية. من الناحية المثالية ، يجب أن تكون العملية برمتها سريعة أيضًا ، ولكن من المهم جدًا أن تصل الإجابات الفردية بسرعة من العملية برمتها .حتى إذا كانت عملية مراجعة الشفرة بأكملها تستغرق وقتًا طويلاً ، فإن توفر استجابات سريعة من المراجع طوال العملية يبسط إلى حد كبير حياة المطورين الذين قد يتضايقون بسبب الاستجابات "البطيئة".إذا كنت مشغولاً للغاية لإجراء مراجعة كاملة فور تلقي الطلب ، فلا يزال بإمكانك الرد بسرعة برسالة عن المواعيد النهائية أو تقديم المراجعة إلى المراجعين الآخرين الذين يمكنهم الرد بشكل أسرع ، أوقدّم بعض التعليقات العامة الأولية (ملاحظة: لا يعني أي من هذا أنه يجب عليك مقاطعة الترميز حتى لإرسال مثل هذا الرد - أرسل الرد عند نقطة توقف معقولة في عملك).من المهم أن يقضي المراجعون وقتًا كافيًا في المراجعة والتأكد من أن "LGTM" الخاص بهم يعني "هذا الرمز يتوافق مع معاييرنا ". ومع ذلك ، يجب أن تكون الإجابات الفردية سريعة على أي حال .مراجعة الكود بين المناطق الزمنية
عند العمل بين مناطق زمنية مختلفة ، حاول الإجابة على المؤلف أثناء وجوده في المكتب. إذا كان قد ذهب بالفعل إلى المنزل ، فتأكد من محاولة إرسال إجابة قبل أن يعود إلى المكتب في اليوم التالي.محفوظة LGTM
لأسباب تتعلق بالسرعة ، هناك بعض المواقف التي يتعين على المراجع فيها منح LGTM / الموافقة ، حتى في حالة التعليقات غير المجاب عليها في CL. يتم ذلك إذا:- المراجع على ثقة من أن المطور سوف يأخذ في الاعتبار جميع التعليقات المتبقية بشكل صحيح.
- التغييرات الأخرى بسيطة واختيارية .
يجب أن يشير المراجع إلى أي من هذه الخيارات يعني إذا كان هذا غير واضح.تكون LGTM المحجوزة مفيدة بشكل خاص عندما يكون المطور والمراجع في مناطق زمنية مختلفة ، وإلا فإن المطور سينتظر طوال اليوم للحصول على "موافقة LGTM".CL كبير
إذا أرسل إليك شخص ما رمز مراجعة كبيرًا لدرجة أنك لست متأكدًا من الوقت الذي تستطيع فيه عرضه ، فإن الإجابة المعتادة ستكون مطالبة المطور بتقسيم CL إلى عدة CL أصغر . عادة ما يكون هذا ممكنًا ومفيدًا جدًا للمراجعين ، حتى لو كان يتطلب عملًا إضافيًا من المطور.إذا كان لا يمكن تقسيم CL إلى CL أصغر ولم يكن لديك وقت للنظر بسرعة في كل هذا ، على الأقل اكتب بعض التعليقات على تصميم CL الكلي وأرسلها مرة أخرى إلى المطور للتحسين. يجب أن يكون أحد أهدافك كمراجع دائمًا هو "إلغاء قفل" المطور أو السماح له باتخاذ أي إجراء إضافي بسرعة دون التضحية بجودة الشفرة.رمز مراجعة التحسينات مع مرور الوقت
إذا اتبعت هذه التوصيات واقتربت من مراجعة التعليمات البرمجية بصرامة ، فستجد أن العملية برمتها تتسارع وتتسارع بمرور الوقت. سوف يكتشف المطورون ما هو مطلوب للرمز عالي الجودة ويرسلون لك CLs رائعة منذ البداية ، وتتطلب وقتًا أقل وأقل للعرض. يتعلم المراجعون الاستجابة بسرعة ولا يضيفون تأخيرًا غير ضروري لعملية المراجعة. لكن لا تساوم على معايير أو معايير مراجعة الكود لتحسين سرعة وهمية - في الواقع ، لن تحقق تسارعًا كليًا على المدى الطويل.حالات الطوارئ
هناك أيضًا حالات طوارئ عندما يتعين على CLs متابعة عملية مراجعة الكود بالكامل بسرعة كبيرة ، وحيث يتعين تخفيف مبادئ الجودة. ولكن يرجى قراءة وصف الحالات التي تعتبر حالات طوارئ والتي لا تنطبق عليها.كيفية كتابة التعليقات في مراجعة الرمز
ملخص
- كن مهذبا.
- اشرح منطقك
- تجنب الطلبات الواضحة بمجرد الإشارة إلى المشكلات والسماح للمطور بالبت فيها.
- شجع المطورين على تبسيط التعليمات البرمجية أو إضافة تعليقات بدلاً من شرح بسيط للتعقيد.
مجاملة
بشكل عام ، من المهم أن تكون مهذبًا ومحترمًا ، وأن تكون واضحة ومفيدة جدًا للمطور الذي تشاهد الكود. طريقة واحدة للقيام بذلك هي التأكد من أنك دائمًا ما تقدم تعليقات حول الكود ولا تتحدث مطلقًا عن المطور . ليس عليك دائمًا اتباع هذه الممارسة ، ولكن يجب عليك استخدامها عندما تقول شيئًا غير سار أو مثير للجدل. على سبيل المثال:
السيئة: "لماذا أنت ؟ استخدام تتدفق هنا، إذا كان من الواضح أن التوازي لا تقدم أي فائدة"جيد: "يضيف نموذج التزامن هنا تعقيدًا للنظام ، ولا أرى أي فائدة فعلية في الأداء. نظرًا لعدم وجود ميزة أداء ، فمن الأفضل أن يكون هذا الرمز مترابطًا واحدًا بدلاً من استخدام مؤشرات ترابط متعددة. "اشرح الاسباب
في المثال "الجيد" أعلاه ، يمكنك أن ترى أنه يساعد المطور على فهم سبب قيامك بالتعليق. لا تحتاج دائمًا إلى تضمين هذه المعلومات في تعليقاتك ، لكن في بعض الأحيان يكون من المناسب تقديم شرح أكثر قليلاً عن منطقك ، أو أفضل الممارسات التي تتبعها ، أو كيف يحسن اقتراحك جودة الشفرة.تعليمات
بشكل عام ، إجراء التصحيحات هو مهمة المطور ، وليس المراجع. ليس مطلوبًا منك تطوير مسودة حل مفصل أو كتابة كود للمطور.ومع ذلك ، هذا لا يعني أن المراجع لا يمكن أن يساعد هنا. بشكل عام ، ينبغي إقامة توازن مناسب بين تحديد المشكلات وتقديم المساعدة المباشرة. إن الإشارة إلى المشكلات وإعطاء المطور الفرصة لاتخاذ قرار غالباً ما يساعد المطور على التعلم ويجعل مراجعة التعليمات البرمجية أسهل. يمكن أن يؤدي أيضًا إلى حل أفضل ، لأن المطور أقرب إلى الشفرة من المراجع.ومع ذلك ، فإن الإرشادات أو الاقتراحات أو التعليمات البرمجية المباشرة تكون مفيدة في بعض الأحيان. الغرض الرئيسي من مراجعة الكود هو الحصول على أفضل CL ممكن. الهدف الثانوي هو تحسين مهارات المطورين بحيث تستغرق المراجعة وقتًا أقل وأقل.اقبل التفسير
إذا طلبت من المطور توضيح قطعة غير مفهومة من التعليمات البرمجية ، فسيؤدي ذلك عادةً إلى حقيقة أنه سيعيد كتابتها بشكل أكثر وضوحًا . أحيانًا تكون إضافة تعليق هي أيضًا إجابة مناسبة ، إذا لم تكن مجرد تعليمة برمجية معقدة للغاية.التفسيرات المكتوبة فقط في أداة المراجعة لن تساعد القراء في المستقبل. تكون مقبولة فقط في بعض الحالات ، على سبيل المثال ، عندما تنظر إلى منطقة لا تعرفها جيدًا ، ويشرح المطور ما يجب أن يعرفه قارئات الشفرات العادية بالفعل.كيفية التغلب على المقاومة في عملية مراجعة الكود
في بعض الأحيان يجادل المطور في عملية مراجعة الكود. إما أنه لا يوافق على اقتراحك ، أو يشتكي من أنك صارم بشكل عام.من هو الصحيح؟
عندما لا يوافق المطور على اقتراحك ، خذ أولاً الوقت الكافي للنظر في موقفه. غالبًا ما يكون أقرب إلى شفرتك وبالتالي قد يكون لديه فكرة أفضل عن بعض الجوانب. هل يعقل في حجته؟ هل يعقل من حيث جودة الرمز؟ إذا كان الأمر كذلك ، فأعترف أنه محق ، وسيختفي السؤال.ومع ذلك ، المطورين ليسوا دائما على حق. في هذه الحالة ، يجب على المراجع توضيح سبب اعتقاده أن اقتراحه صحيح. يوضح التفسير الجيد كلاً من فهم استجابة المطور ومعلومات إضافية حول سبب التغيير المطلوب.على وجه الخصوص ، عندما يرى المراجع أن اقتراحه سيؤدي إلى تحسين جودة الشفرة ، يجب عليه الإصرار عليها إذا رأى أن تحسين الجودة الناتج يبرر العمل الإضافي. يحدث تحسين جودة الرمز ، كقاعدة عامة ، في خطوات صغيرة.في بعض الأحيان يستغرق الأمر عدة جولات من التفسير قبل قبوله بالفعل. فقط تأكد من أن تظل دائمًا مهذبًا ، واجعل المطور يعرف أنك تسمع ذلك ، لا توافق على ذلك.حول استياء المطورين
يشعر المراجعون أحيانًا أن المطور يشعر بالضيق إذا أصر المراجع على التحسين. أحيانًا ما يكون المطورون منزعجين حقًا ، ولكن عادةً ما لا يكونون لفترة طويلة ، وفي وقت لاحق سيكونون ممتنين جدًا لمساعدتكم في تحسين جودة الشفرة الخاصة بهم. عادةً ، إذا كنت مهذباً في تعليقاتك ، فإن المطورين لا يشعرون بالضيق حقًا على الإطلاق ، ويتمثل القلق فقط في رأس المراجع. عادةً ما يكون أسلوب كتابة التعليقات أكثر إحباطًا من ثبات المراجع فيما يتعلق بجودة الشفرة.في انتظار التعديلات
مصدر الجدل النموذجي هو أن المطورين (لأسباب واضحة) يرغبون في إنجاز المهمة. انهم لا يريدون الذهاب من خلال جولة أخرى من الاستعراضات لهذا CL. لذلك ، يقولون أنهم سوف يقومون بإزالة شيء ما في CL لاحقًا ، وعليك الآن إنشاء LGTM لهذا CL. يقوم بعض المطورين بهذا بشكل جيد للغاية ، وعلى الفور يكتب CL آخر من شأنه حل المشكلة. ومع ذلك ، فقد أظهرت التجربة أنه كلما مر وقت أطول بعد CL الأصلي ، قل احتمال حدوث هذا التعديل. في الواقع ، عادةً إذا لم يقم المطور بالتحرير فورًاهذا عادة لا يحدث على الإطلاق. ليس لأن المطورين غير مسؤولين ، ولكن لأن لديهم الكثير من العمل ، ويضيع التحرير أو ينسى تحت منحدر العمل الآخر. وبالتالي ، من الأفضل عادة الإصرار على حل فوري قبل أن يذهب الالتزام إلى قاعدة البيانات ويكون "مكتمل". السماح بالتحريرات المعلقة هي طريقة نموذجية لتدهور قواعد الأكواد.إذا قدمت CL تعقيدًا جديدًا ، فيجب إصلاحها قبل الإرسال ، إذا لم تكن هذه حالة طارئة. إذا أظهرت CL مشكلات أخرى لا يمكن حلها في الوقت الحالي ، يجب على المطور تسجيل خطأ في برنامج التتبع وتعيينه لنفسه حتى لا يضيع. يمكنه اختياريًا كتابة تعليق TODO في الكود فيما يتعلق بهذا الخطأ.شكاوى عامة من شدة
إذا كنت معتادًا على مراجعة الكود السطحي إلى حد ما ، والتحول إلى الوضع الصارم ، فسيبدأ بعض المطورين في تقديم شكوى بصوت عالٍ للغاية. زيادة سرعة مراجعة التعليمات البرمجية عادة ما يحل هذه الشكاوى.في بعض الأحيان قد يستغرق الأمر عدة أشهر حتى تختفي الشكاوى ، ولكن في النهاية ، يميل المطورون إلى رؤية قيمة مراجعات الكود الصارمة لأنهم يرون حجم الكود. في بعض الأحيان ، يصبح المتظاهرون الأعلى صوتًا أقوى المؤيدين عندما يحدث شيء يجعلهم يرون حقًا قيمة المراجعات الصارمة.حل النزاع
إذا كنت تفعل كل ما سبق ، ولكن لا تزال تواجه تعارضات ، فراجع قسم معايير مراجعة الكود للحصول على التوصيات والمبادئ التي يمكن أن تساعد في حل التعارض.