مراجعة التعليمات البرمجية - الدليل النهائي

الدليل النهائي لبناء عملية مراجعة الكود لفريقك

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

تفترض هذه المقالة أنك تعرف ما هي مراجعة التعليمات البرمجية. لذلك إذا لم تقم بذلك ، فانقر هنا للحصول على مقدمة رائعة.

دعنا نذكر بسرعة بعض الأسباب المباشرة لسبب وجوب إجراء مراجعات الكود:

  1. يمكن أن تساعد في تقليل الأخطاء في التعليمات البرمجية.
  2. تحقق من استيفاء جميع متطلبات الترميز.
  3. طريقة فعالة للتعلم من الأقران والتعرف على قاعدة الكود.
  4. يساعد في الحفاظ على نمط الكود عبر الفريق.
  5. تماسك الفريق - شجع المطورين على التحدث مع بعضهم البعض بشأن أفضل الممارسات ومعايير الترميز.
  6. يحسن جودة الكود بشكل عام بسبب ضغط الأقران.

ومع ذلك ، يمكن أن تكون مراجعات الكود أحد أكثر الأجزاء صعوبة واستهلاكًا للوقت في عملية تطوير البرامج.

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

إذا لم يتم التخطيط لعملية مراجعة الكود بشكل صحيح ، فقد يكون لها تكلفة أكبر من القيمة.

هذا هو السبب في أنه من المهم للغاية هيكلة وبناء عملية محددة جيدًا لمراجعات الكود داخل فريقك الهندسي.

بشكل عام ، ستحتاج إلى وضع إرشادات محددة جيدًا لكل من المراجع والمراجع ، قبل إنشاء طلب سحب وأثناء مراجعته. اكثر تحديدا:

تحديد الامتيازات لإنشاء طلبات السحب.

لقد وجدت أن ما يلي يقلل بدرجة كبيرة من الاحتكاك:

  1. تأكد من ترجمة الكود بنجاح.
  2. اقرأ التعليمات البرمجية وعلق عليها.
  3. قم بإنشاء وتشغيل الاختبارات التي تتحقق من صحة نطاق التعليمات البرمجية الخاصة بك.
  4. يجب اختبار كل التعليمات البرمجية في قاعدة البيانات.
  5. اربط التذاكر / العناصر ذات الصلة في أداة إدارة المهام (JIRA على سبيل المثال) بطلب السحب.
  6. لا تقم بتعيين مراجع حتى تنتهي مما ورد أعلاه.

تحديد مسؤوليات المراجع

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

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

تحديد مسؤوليات المراجع

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

  1. كن على دراية بوصف المهمة والمتطلبات.
  2. تأكد من فهم الرمز تمامًا.
  3. تقييم جميع المقايضات المعمارية.
  4. قسّم تعليقاتك إلى 3 فئات: نقدية واختيارية وإيجابية. الأولى هي التعليقات التي يجب على المطور قبولها لتغييرها ، والثانية هي التعليقات التي تتيح للمطور معرفة تقديرك لأجزاء لطيفة من التعليمات البرمجية.

أيضًا ، تجنب العديد من التعليقات واستخدم مراجعة Github بدلاً من ذلك (انظر المثال أدناه).

عندما يكون لديك عدة تعليقات ، يجب عليك استخدام خيار المراجعة في Github ، بدلاً من التعليق على كل منها على حدة ، وإخطار المطور (مالك العلاقات العامة) عند الانتهاء.

أخيرًا ، وجدت أن طرح الأسئلة التالية هو أداة رائعة لعملية مراجعة أفضل وأسهل بشكل عام:

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

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

إذا كان لديك أي أسئلة أو تعليقات لتحسين هذه الإرشادات ، فلا تتردد في إضافة تعليق أدناه!