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