مراجعة الكود: تجربة ناجحة

هناك الكثير من المعلومات على الإنترنت حول مراجعات الكود:

• كيف تؤثر مراجعة رمز شخص آخر على ثقافة الشركة
• الشيكات الأمنية التنظيمية
• كتيبات مختصرة
• قوائم طويلة من التوصيات
• مراجعة التعليمات البرمجية من منظور شخصي
• لماذا أحتاج إلى مراجعة التعليمات البرمجية
• طرق مجربة
• المزيد عن الأساليب المجربة
• الإحصائيات: مقدار مراجعة الشفرة التي تساعد في التقاط الأخطاء
• أمثلة على الأخطاء التي حدثت أثناء مراجعة التعليمات البرمجية

نعم بالطبع هناك كتب حول هذا الموضوع. باختصار ، توضح هذه المقالة كيفية تنظيم مراجعة الكود بواسطة Palantir. في تلك المنظمات التي لا تقبل ثقافتها مثل هذه المراجعة من الأقران ، قد يكون من المفيد أولاً قراءة مقالة Karl E. Wiegers الرائعة ، The Code Revision with an Human Face ، ثم محاولة اتباع هذا الدليل.

هذا النص مأخوذ من توصيات تحسين الجودة استنادًا إلى العمل مع Baseline ، أداتنا للتحكم في جودة كود Java. يغطي الموضوعات التالية:

• لماذا وماذا ومتى نحاول تحقيق مراجعة الكود
  
• جارٍ تحضير الرمز للمراجعة
  
• تنفيذ مراجعة التعليمات البرمجية
  
• أمثلة لمراجعة التعليمات البرمجية
  

ترجم إلى Alconost


XKCD Comic 'جودة الرمز' ، تم نسخه بموجب CC BY-NC 2.5 رخصة

الدافع

نحن منخرطون في مراجعة الكود (RC) لتحسين جودة الكود وبالتالي نريد التأثير بشكل إيجابي على ثقافة الفريق والشركات. على سبيل المثال:

• يتحمس مؤلفو الشفرة لأنهم يعرفون أن فريق المراجعين سيأخذ في الاعتبار طلبهم للتغييرات: يحاول المؤلف تنظيف الخشونة واتباع خطة العمل وتحسين الالتزام بشكل عام. عندما يعترف الزملاء باحترافيتك في كتابة التعليمات البرمجية - بالنسبة للعديد من المبرمجين ، فهذه مناسبة للفخر بأنفسهم.
  
• تساعد مشاركة المعرفة فريق التطوير بعدة طرق:
  

- تحت RK ، يتم الإبلاغ بوضوح عن أي جزء من الوظيفة تمت إضافته / تغييره / حذفه بحيث يمكن لأعضاء الفريق في المستقبل الاعتماد على العمل المنجز بالفعل.

- يمكن لمؤلف الشفرة استخدام تقنية أو خوارزمية يتعلم المراجعون من خلالها شيئًا ما. بشكل عام ، تساعد مراجعة الكود على رفع مستوى الجودة في جميع أنحاء المؤسسة .

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

- الاتصال والتواصل الإيجابي يعزز العلاقات الاجتماعية بين أعضاء الفريق.

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

ما الذي تبحث عنه

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

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

متى للتحقق

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

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

جارٍ تحضير الرمز للمراجعة

يلتزم مؤلف الشفرة بتوفير رمز المراجعة في شكل قابل للهضم حتى لا يستغرق وقتًا إضافيًا من المراجعين ولا يحبطهم:

• النطاق والحجم . يجب أن تتعلق التغييرات بنطاق ضيق ومحدّد جيدًا ومكتفي ذاتيًا ومغطى بالكامل بالمراجعة. على سبيل المثال ، قد تكون التغييرات مرتبطة بتنفيذ بعض الميزات أو إصلاح الأخطاء. التغييرات الموجزة هي الأفضل للتغيرات الطويلة. إذا كانت المراجعة تحتوي على مادة تتضمن تغييرات في أكثر من 5 ملفات تقريبًا ، أو تتطلب أكثر من يوم أو يومين للتسجيل ، أو قد تستغرق المراجعة نفسها أكثر من 20 دقيقة ، فحاول تقسيم المادة إلى عدة أجزاء مستقلة بذاتها والتحقق من كل منها على حدة. على سبيل المثال ، يمكن للمطور إرسال تغيير يحدد واجهة برمجة التطبيقات لميزة جديدة من حيث الواجهات والوثائق ، ثم إضافة تغيير ثان يصف عمليات التنفيذ لهذه الواجهات.
  
• تحتاج فقط إلى إرسال مواد كاملة ، تم اختبارها بشكل مستقل (استخدام فرق) واختبار المواد بشكل مستقل . لتوفير وقت المراجع ، اختبر التغييرات المرسلة (على سبيل المثال ، قم بتشغيل مجموعة الاختبار) وتأكد من أن الرمز يجتاز جميع التجميعات ، وكذلك جميع الاختبارات وجميع مراحل مراقبة الجودة ، محليًا وعلى خوادم التكامل المستمر ، ثم حدد فقط المراجعين .
  
• لا يجب أن تؤثر التغييرات في إعادة الهيكلة على السلوك والعكس صحيح ؛ يجب ألا تتضمن التغييرات التي تؤثر على السلوك إعادة هيكلة أو إعادة تنسيق التعليمات البرمجية. هناك عدد من الأسباب الجيدة لذلك:
  

- تؤثر التغييرات المتعلقة بإعادة البناء عادة على العديد من أسطر التعليمات البرمجية في العديد من الملفات - وبالتالي ، لن يتم التحقق من هذا الرمز بعناية . يمكن أن تتسرب التغييرات غير المخطط لها في السلوك إلى قاعدة التعليمات البرمجية ، ولن يلاحظها أحد حتى.

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

- يجب أن يستغرق وقت العمل الباهظ الذي يقضيه الشخص في مراجعة التعليمات البرمجية للتحقق من منطق البرنامج ، وليس للمناقشة حول نمط التعليمات البرمجية أو بناءها أو تنسيقها. نحن نفضل حل هذه المشكلات باستخدام الأدوات الآلية ، على وجه الخصوص ، Checkstyle ، TSLint ، Baseline ، Prettier ، إلخ.

تنفيذ الرسائل

فيما يلي مثال على رسالة الالتزام المختصة ، والتي تم تصميمها وفقًا للمعيار المستخدم على نطاق واسع:

 ( 80 )    ,  ,   .   72 .          ,    —   .   ,       (   );     ,  rebase,    .  -   : « »,   « »   « ».      -,  , ,  git merge  git revert.      .    . 

حاول وصف التغييرات التي تم إجراؤها أثناء الالتزام ، وكيفية إجراء هذه التغييرات بالضبط:

 > .   .    . > .  jcsv-     IntelliJ 

ابحث عن المراجعين

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

تنفيذ مراجعة التعليمات البرمجية

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

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

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

الغرض

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

التنفيذ

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

سهولة القراءة والأناقة

• فكر في كيفية قراءة هذا الرمز. هل يمكنك فهم مفاهيمه بسرعة كافية؟ هل تم وضعها بشكل معقول ، هل من السهل تتبع أسماء المتغيرات والأساليب؟ هل يمكنني تتبع الرمز عبر ملفات أو وظائف متعددة؟ هل سبق أن أزعجتك التسمية غير المتسقة في مكان ما؟
  
• هل يتوافق الرمز مع إرشادات البرمجة والأنماط المعروفة؟ هل ينفصل الكود عن المشروع بأكمله حسب الأسلوب ، اصطلاحات تسمية API ، وما إلى ذلك؟ كما ذكرنا أعلاه ، نحاول حل النزاعات الأسلوبية باستخدام الأدوات التلقائية.
  
• هل يحتوي الرمز على قوائم المهام (المهام)؟ تتراكم قوائم المهام ببساطة في الكود وتتحول في النهاية إلى صابورة. قم بتعيين المؤلف لإرسال تذكرة إلى GitHub Issues أو JIRA وإرفاق رقم مهمة لـ TODO. يجب ألا يكون هناك رمز معلق في التغيير المقترح.
  

دعم قابلية الاستخدام

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

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

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

الأمان

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

التعليقات: موجزة ومهذبة وحافزة

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

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

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

رد المراجعة

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

يجب تصحيح التصحيحات في نفس الفرع ، ولكن في التزام منفصل. إذا قمت بتجميع عمليات التنفيذ معًا في مرحلة المراجعة ، فسيكون من الصعب على المراجع تتبع التغييرات.

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

مراجعة كود Tête-à-tête

كقاعدة ، تعتبر الأدوات غير المتزامنة الشبيهة بالفروق ، مثل Reviewable أو Gerrit أو GitHub ، رائعة لمراجعات الشفرة. إذا كنا نتحدث عن مراجعة معقدة أو مراجعة ، يختلف المشاركون فيها اختلافًا كبيرًا من حيث الخبرة أو الاحتراف ، فقد يكون من الأفضل إجراء مراجعة شخصية - إما الجلوس معًا أمام شاشة واحدة أو جهاز عرض ، أو عن بُعد ، عبر مؤتمرات الفيديو أو أدوات مشاركة الشاشة.

أمثلة

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

 //R: ... 

تسمية غير متناسقة

 class MyClass { private int countTotalPageVisits; //R:    private int uniqueUsersCount; } 

توقيعات طريقة غير متناسقة

 interface MyInterface { /**  {@link Optional#empty},  s   . */ public Optional<String> extractString(String s); /**  null,  {@code s}   . */ //R:    :    // Optional<> public String rewriteString(String s); } 

استخدام المكتبة

 //R:     MapJoiner   Guava String joinAndConcatenate(Map<String, String> map, String keyValueSeparator, String keySeparator); 

التفضيلات الشخصية

 int dayCount; //R: :   numFoo   fooCount;   ,          

البق

 //R:    numIterations+1 –    ? //    –     numIterations? for (int i = 0; i <= numIterations; ++i) { ... } 

اعتبارات معمارية

 otherService.call(); //R: ,      OtherService.    ? 

عن المترجم

تمت ترجمة المقال بواسطة Alconost.

تقوم Alconost بتوطين الألعاب والتطبيقات والمواقع بـ 70 لغة. مترجمون لغتهم الأم ، اختبار لغوي ، منصة سحابية بواجهة برمجة تطبيقات ، تعريب مستمر ، مدراء مشاريع 24/7 ، أي تنسيق لموارد السلسلة.

ننشئ أيضًا مقاطع فيديو إعلانية وتدريبية - للمواقع التي تبيع ، والصور ، والإعلانات ، والتدريب ، والتشويش ، والشرح ، والمقطورات لـ Google Play و App Store.

مزيد من التفاصيل