لقد كنت مهتمًا بمراجعة أسئلة التعليمات البرمجية لفترة طويلة جدًا. في كثير من الأحيان نشأت مشكلة واحدة أو أخرى ، إما مع جودة الكود ، أو مع المناخ في الفريق. في الواقع ، تعد مراجعة الكود هي الوحيدة ، ثم واحدة من أهم الأماكن للنزاعات في فريق التطوير.
ومؤخراً ، استعدادًا للإصدار التالي لبودكاست Zinc Prod ، اكتشفت أن Google قد نشرت مدونة ممارسات Code Code مليئة بالأفكار القيمة. جميع المواد ضخمة جدًا ولن تنسجم مع مقال واحد ، لذلك سأحاول تسليط الضوء على الأفكار الأكثر إثارة للاهتمام (بالنسبة لي).
لذلك دعونا نذهب
المصطلحات المستخدمة في المقال الأصلي:
CL - سجل التغيير. ولكن عادة ما يطلق عليه دمج طلب أو طلب سحب ، لذلك في المقالة سأستخدم اختصار MR
LGTM - تبدو جيدة بالنسبة لي. باختصار ، عندما يضغطون على زر "موافقة". سأستخدم مصطلح "aprov" ، ليكون أكثر قابلية للفهم لدى السكان.
السيد المثالي
في الممارسة العملية ، يمكن للمرء أن يصادف مختلف الأطراف عند النظر في MR. شخص ما ككل تعليقات فريق zadalivaet ، حتى يتم تعثر كل شيء إلى هذه النقطة ، يتم تصحيح ، يبحث شخص ما عن المنطق ويضغط على "upruv".
فكر مثير للاهتمام هو مكتوب في وثيقة جوجل. لا ينبغي أن يكون MR مثاليًا ، لكن يجب أن يحسن قاعدة الشفرة. أي أنه مع كل تغيير تم إدخاله ، يجب أن تتحسن الشفرة. وإذا أضاف MR الكثير من الخير ، فلن تضطر إلى العثور على خطأ في الأشياء الصغيرة ؛ من الأفضل تحقيق هذا التحسين بشكل أسرع.
لا ينبغي أن تجعل MR رمز أسوأ. الاستثناء الوحيد هو إذا كان MR هو حل عاجل لشيء ما.
حرية التعليق
على الرغم من حقيقة أنه لا يمكنك التخلص من تفاهات ، ومع ذلك يمكنك كتابة هذه تفاهات بحرية إلى كل سطر على الأقل. يتم حل التناقض مع الفقرة السابقة ببساطة: المراجع البادئات تافه والانتقاء مع البادئة "nit:" من اللغة الإنجليزية. نيتبيك (نيتبيكينج). ليس من الضروري إصلاح مثل هذه التعليقات ، ومع ذلك ، قد يرغب مؤلف MR في تصحيح شيء ما ، أو حتى إذا لم يكن الأمر كذلك ، يأخذ في الاعتبار بعض النقاط في المستقبل.
حقائق على التفضيلات الشخصية
دائمًا ما تكون مبادئ تصميم البرامج القياسية ، المستندة إلى أفضل الممارسات ، أفضل من الدراجات الصعبة. لذلك ، ينبغي إعطاء الأفضلية لهم.
إذا كان يمكنك تطبيق العديد من الأساليب القياسية ، فسيكون ذلك وفقًا لتقدير المؤلف.
اقتباس مباشر لفهم أفضل:
إن جوانب تصميم البرنامج لا تكاد تكون أبدًا مشكلة في الأناقة أو مجرد تفضيل شخصي. وهي تستند إلى مبادئ أساسية ويجب موازنة هذه المبادئ ، وليس فقط عن طريق الرأي الشخصي. في بعض الأحيان هناك بعض الخيارات الصحيحة. إذا كان بإمكان المؤلف إثبات (إما من خلال البيانات أو استنادًا إلى مبادئ الهندسة الصلبة) أن العديد من النهج صالحة على قدم المساواة ، فيجب على المراجع قبول تفضيل المؤلف. خلاف ذلك ، تملي الاختيار على المبادئ القياسية لتصميم البرامج.
إذا كان المراجع ومؤلف MR لا يتفقان مع بعضهما البعض
أولاً تأتي محاولة للتوصل إلى توافق في الآراء بشأن التعليقات على السيد. إذا كان هذا لا يعمل ، ثم مناقشة شخصية. إذا كنت لا تزال غير متفق عليه ، فعليك جذب أعضاء الفريق. ولكن الأهم من ذلك ، لا ينبغي أن يكون السيد عالقًا لفترة طويلة بسبب الخلاف بين شخصين.
تمت مناقشته في التعليقات -> تمت مناقشته شخصيًا -> تمت مناقشته في فريق -> الانتقال
فحص سرعة السيد
السرعة مهمة للغاية. إذا أعطيت تعليقًا واحدًا كل بضعة أيام ، فسيشكو مؤلف كتاب الخطأ من العثور على خطأ معه ومنعه من العمل.
إذا تم فحص MR بسرعة كبيرة ، فلن تكون أي تعليقات مشكلة كبيرة - بعد كل شيء ، سيتم فحص إصلاحاتها هنا ، وستستمر المهمة.
تنصح Google بعدم صرف انتباهك عن التركيز على مهمتك ، ولكن إذا كنت مشتتًا ، فراجع ما إذا كان هناك شيء يجب مراجعته. على سبيل المثال ، عاد من الغداء - نقح. جاء للعمل - المنقحة. إلخ
MR عرض النظام
تحتاج أولاً إلى إلقاء نظرة على MR ككل. هل من الضروري على الإطلاق ، هو الكود في المكان المناسب (أو ينبغي أن يكون في مكتبة منفصلة) ، هل هناك أي مشاكل عالمية.
أي ليس من المنطقي أن ننظر إلى بعض تفاصيل التنفيذ إذا لم يكن الرمز موجودًا على الإطلاق وليس على الإطلاق.
بشكل عام ، يعتبر ترتيب العرض مهمًا لتقديم تعليقات إلى المؤلف في أقرب وقت ممكن (انظر الفقرة السابقة).
عندما نظرت إلى MR ككل ، فأنت بحاجة إلى استعراض الملفات الرئيسية ، أي تحقق من أهم شيء (إذا لم يكن من الواضح ما هو الأكثر أهمية ، يمكنك أن تسأل المطور).
مرة أخرى ، يجب الإبلاغ عن أي مشاكل على الفور ، حتى إذا لم تكن قد فتشت MR بعد وقررت فحصها بشكل عام لاحقًا.
بعد ذلك ، تحتاج إلى تحديد تسلسل منطقي لعرض الملفات المتبقية. يجب عدم تخطي أي ملف.
ما الذي تبحث عنه عند المشاهدة
- رمز مصممة بشكل جيد
- تم عمل الوظيفة بشكل جيد من وجهة نظر مستخدمي هذا الرمز ، بغض النظر عن من هم.
- يجب أن يكون المظهر (إن وجد) جيدًا
- جميع الفروق الدقيقة في البرمجة المتوازية (إن وجدت) تؤخذ بعين الاعتبار.
- رمز غير إعادة تصميم
- المطور لا يتعدى العمل: لا تحتاج إلى كتابة التعليمات البرمجية التي قد تكون مطلوبة ، أو قد لا تكون هناك حاجة إليها
- الرمز له اختبارات
- الاختبارات مصممة بشكل جيد
- يتم تحديد الأسماء (لكل شيء) بشكل جيد
- التعليقات على الكود مفهومة وضرورية. يجب أن يشرحوا لماذا يتم ذلك ، وليس كيف يتم ذلك.
- الوثائق المضافة.
- رمز يتوافق مع أدلة النمط.
السيد كبير جدا
يجب طلب MRs كبيرة جدًا لتفتيت. هو دائما ممكن تقريبا.
كيفية كتابة التعليقات على مراجعة الرمز
- عليك أن تكون مهذبا ، وليس للحصول على الشخصية. مناقشة التعليمات البرمجية ، وليس التشفير.
- ليس فقط إصدار توجيهات للتصحيحات ، ولكن اشرح سبب احتياجك لإصلاحها.
- الحفاظ على التوازن: تحديد المشكلة ودفع المطور حتى يفهم هو نفسه أفضل السبل لحلها ؛ أو إصدار حل جاهز على الفور. الأول يطور المطور (المنفعة الإستراتيجية) ، والثاني يحسن ويسرع MR (المنفعة التكتيكية).
- إذا لم يفهم المراجع في مرحلة ما من الكود ، وطلب من المؤلف شرح ما هو ، فإن أفضل إجابة ستكون تغيير الكود. بحيث كان كل شيء واضح من التعليمات البرمجية دون سؤال.
إذا كنت لا توافق على رأيك
من الضروري أن نفهم بالتفصيل. ربما لا تفهم شيئًا ما ، فاطلب المزيد من المعلومات. ربما العكس. على أي حال ، غالبًا ما يأتي الفهم فقط بعد جولتين من التفسيرات من كلا الجانبين.
الخوف من غضب المؤلف MR
يحدث انزعاج المطور إذا أصر المراجع على بعض التغييرات. ومع ذلك ، غالبًا ما يزعج المطورين بسبب شكل التعليق ، وليس بسبب المحتوى. كن مهذبا ، وشرح مع الحجج ، وعلى الأرجح كل شيء سيكون على ما يرام.
"سأصلحه لاحقًا."
إذا وافق المطور على وجود مشكلة في التعليمات البرمجية ، ولكنه يسأل عن MR ، متعهداً بإصلاحه في وقت آخر ، في رأي الرجال من Google ، فإن هذا "لاحقًا" لا يحدث أبدًا. لذلك ، إذا لم يكن MR بعض الأخطاء العاجلة العاجلة ، فأنت بحاجة إلى الإصرار على الإصلاح.
النتائج
لقد أحببت هذا المستند من Google حقًا. لا سيما الحياة اختراق كلمة "nit" ، والتأكيد على سرعة مراجعة التعليمات البرمجية ، وأيضا أن MR لا ينبغي أن يكون مثاليا. يبدو الأمر بسيطًا ، لكن طالما لم يتم النظر في ذلك بشكل واضح ، فإنه لا يصل إلى هذه النقطة.
إذا كانت هذه المقالة مثيرة للاهتمام للقراء وتلتقط عددًا من المزايا ، فسوف أكتب الجزء التالي: عملية مراجعة الكود بواسطة المؤلف MR.
تحديث: الجزء الثاني من المقال هنا
أيضًا ، في العدد القادم من Zinc Sale ، سنناقش بالتفصيل رمز المراجعة من زوايا مختلفة. لذلك تأكد من الاشتراك في بودكاست التنمية لدينا !