ربما تقرأ الجزء الأول من المقالة حول رمز المراجعة من قبل المراجع (بالمناسبة ، تمكنا بالفعل من مناقشته في العدد الأخير من بودكاست Zinc Prod ).
منذ أن اكتسبت المقالة الكثير من الإعجابات ، أكتب الاستمرارية الموعودة حول مراجعة الكود من ناحية أخرى - من مؤلف تغييرات الكود
كالعادة ، سنقول MR (طلب دمج) بدلاً من CL ، لأن قلة من الناس يفهمون المصطلح CL.
يمكن العثور هنا على التعليمات الأصلية لمؤلفي MR وفقًا لـ Google ، وسأقدم لك نبذة مختصرة.
لذلك دعونا نذهب
وصف MR
في Google ، يتم تخزين وصف التغييرات في محفوظات نظام التحكم في الإصدار ، مع وجود احتمالية عالية سيتم قراءتها من قبل الكثير من الأشخاص في المستقبل. لذلك ، وصف MR مهم جدا.
يجب أن يحتوي السطر الأول (في العنوان) على عبارة واحدة تصف ما تم في MR. علاوة على ذلك ، ووفقًا للتقاليد ، يتم استخدام أسلوب (ضروري) ضروري ، أي حذف blablabla ، وليس حذف blablabla
يجب أن يكون الوصف نفسه غني بالمعلومات ، ويحتوي على وصف موجز للمشكلة التي يجري حلها ، وارتباطات بالوثائق الضرورية (إذا لزم الأمر) ، ومهام تعقب المهام وسياق آخر. حتى في MR الصغير ، يجب أن يكون شيء من هذا القبيل.
يعتبر وصف نوع "إصلاح الخلل" ، بالطبع ، غير مناسب.
يجب أن يكون السيد صغيرًا قدر الإمكان
- يمكن التحقق من السيد قليلا بسرعة
- التحقق سيكون أكثر وضوحا
- أقل احتمالا أن تفوت خطأ.
- ليس هجوميًا إذا تم رفض MR بالكامل. إنه لأمر سيء للغاية عندما يتم القيام بالكثير من العمل ، ثم اتضح أن كل هذا لم يكن ضروريًا على الإطلاق
- أسهل لدفع التغييرات ، وأقل الصراع
- من الأسهل الحصول على كود جودة جيد.
- كلما زادت التغييرات في المرة ، زاد صعوبة استعادة الشفرة إذا لزم الأمر
نادرًا ما يكون هناك موقف عندما يكون من المستحيل تقليل حجم MR ، وتقسيمه إلى أجزاء. للمراجع الحق في رفض MR إذا كانت كبيرة جدًا
بالطبع ، لا يمكن أن يكون هناك قاعدة صارمة وسريعة ، والتي سوف تعتبر MR كبيرة ، أي صغيرة. 100 سطر من التعليمات البرمجية كبيرة أم لا؟ من يعرف
- السيد يجب أن تفعل شيئا واحدا. عادة ليست هذه هي الميزة بأكملها ، ولكن جزء منها
- اعادة بيع منفصلة في MR منفصلة
يجب أن يكون MR صغيرًا لكنه مكتفٍ ذاتيًا
- كل ما يحتاجه المراجع لفهم MR يجب أن يكون في ذلك MR
- بعد حقن الرمز ، يجب أن يعمل النظام بشكل طبيعي.
- إذا تمت إضافة طريقة API ، فيجب إظهار طرق استخدامها في نفس MR. بمعنى آخر ، لا ينبغي أن يكون حجم MR منخفضًا بحيث يصعب فهم كيفية استخدامه ، وما هي العواقب التي سيؤدي إليه.
- قم بتغطية الرمز مع الاختبارات ، ويجب أن تكون الاختبارات في نفس MR
لا تأخذ بعين الاعتبار
في بعض الأحيان ، لا يكون المراجعون مهذبين جدًا ، فيمكنهم كتابة شيء سيء عن الشفرة. هذا ليس احترافيًا للغاية من جانبهم ، ولكن غالبًا ما لا يزال هناك قدر كبير من الحقيقة في مثل هذه التعليقات ، ويجب أخذ ذلك في الاعتبار. لا تستجيب بقسوة للغاية. هذا لن يؤدي إلا إلى تفاقم الوضع.
إذا كنت لا تحب لهجة المحادثة في التعليقات ، فمن الأفضل العثور على هذا الشخص والتحدث معه شخصيًا ، لشرح ما لا يناسبك.
إذا لم يساعد ذلك ، تنصح Google بالاتصال بالمدير.
من تجربتي ، أود أن أضيف أنه في كثير من الأحيان لا يكتب الشخص الذي يكتب تعليقًا غير مهذب في كثير من الأحيان حسابًا يمكن أن يبدو عدوانيًا بطريقة ما. يخفي النص نصف العواطف. على سبيل المثال ، قد يبدو ما قيل في لهجة ودية مازحا في شكل نص وكأنه دهس قاسية. لذلك ، أنا أتفق تمامًا مع Google - في حالة سوء الفهم ، تواصل فقط شخصيًا!
اشرح الكود
إذا طُلب منك توضيح نقطة في الكود ، فكر في إمكانية تصحيح الكود بحيث يكون مفهومًا دون تفسير. لأنه إذا لم يفهم أحد ، فقد لا يفهم الآخرون.
الرد على تعليقات المعلقين
في كثير من الأحيان ، عند الانتهاء من العمل وإرساله إلى رمز المراجعة ، يكون من الصعب من الناحية النفسية قبول حقيقة أنه يجب أيضًا إصلاح شيء ما. لذلك ، حاول ألا تتصور تعليقات المراجع بحماسة ، فكر ، ربما يكون على صواب ، وستصبح الشفرة أفضل نتيجة لذلك.
ومع ذلك ، إذا كان المراجع لا يزال مخطئًا ، فلا تتردد في الكتابة عنه ، مع توفير الإجابة بالحجج والحقائق.
النتائج
بشكل عام ، كما فهمت من مستند من Google ، يجب على مؤلف MR بذل كل ما في وسعه لجعل المراجع أسهل ؛ لكي يفهم المراجع سبب إنشاء الكود ، وكيف تم إنشاء الكود ، يجب أن يكون هناك كل السياق الضروري للفهم ، إلخ.
لا مفر من حل الخلافات عن طريق التوصل إلى توافق في الآراء في شكل مهني مهذب.
في الإصدار التالي من بيع الزنك ، سنناقش بالتأكيد هذه المقالة (وأكثر من ذلك بكثير) ، لذا تأكد من الاشتراك في البودكاست الخاص بنا ، أو تخطي الجزء الممتع!