كمهندس مبتدئ في البرمجيات ، كنت دائماً أطلع على تعليقات مراجعة الكود التي تلقيتها لمعرفة كيف أصبح مشفرًا أفضل. لكن عندما حان الوقت لمحاولة مراجعة أول كود لي ، أدركت أن تجربتي لم تعد لي على الجانب الآخر.
لقد أصبت بحالة شديدة من متلازمة الدجاسة ، تصاعدت لأسفل مع الأسئلة: هل يجب أن أعلق على هذا السطر من الكود أم أنه لا يستحق ذلك؟ هل يجب أن أجد مقالات تدعم كل تعليق؟ هل أعطل الموقع بالموافقة على هذا؟ هل يكرهونني؟ حسنا ، أنا أعترف أنني دوامة بسرعة كبيرة. لكن بعد التحدث إلى بعض زملائي في العمل ، كنت أعرف أنني لست وحدي في قلقي.
يقول جيسيكا رويدر ، مهندس خبرة في جيثب ، إن مهندسي البرمجيات المبتدئين قد يتم طرحهم في مراجعة الكود بافتراض مشابه "تعرف كيفية قراءة كتاب حتى تعرف كيفية كتابة كتاب ، وهذا غير صحيح".
هناك توقعات تأتي مصحوبة بمراجعة الكود ، ويمكن أن تكون العملية مضطربة. لذا قابلت سبعة من مهندسي البرامج الآخرين لجمع نصائح حول كيفية بناء عقلية مراجعة.
1. فكر في التأثير الكلي
بشكل عام ، يجب أن يؤثر طلب السحب الجيد (PR) فقط على جزء محصور من قاعدة الشفرة. ومع ذلك ، لا ينبغي أن يمنعك النطاق المحدود من التفكير في تغيير الرمز في سياق قاعدة الشفرة الأكبر.
يشجع Nigel Munoz ، وهو مهندس سابق مكدس في The Muse ومهندس برمجيات مستقل حالي ، المراجع على التفكير في "كيفية تأثير هذا التغيير على الصورة الأكبر والأصغر". النظر في الصورة الأكبر تتضمن العثور على أي دين تقني - ابحث عن الكود الذي يتم تكراره ، غير نمطي ، أو لا يلتزم بأحدث الاتفاقيات القياسية - وكذلك تحليل التعديلات على بنية قاعدة الشفرة.
يعتقد سام دونو ، مطور رئيسي في Hudson River Trading ، أنه "لا يوجد شيء أكبر من اللازم أو صغير جدًا لا يمكن التعليق عليه. يمكن أن تؤدي اقتراحات التحسينات الصغيرة إلى تحسينات أكبر في أجزاء متعددة من قاعدة البيانات ".
يمكنك استخدام تعليق العلاقات العامة على GitHub لتقديم تعليقات إيجابية وكذلك الإشارة إلى المكان الذي قد يختلف فيه الرمز عن الاتفاقيات القياسية للإطار React.
على سبيل المثال ، خلال أحد مراجعات الكود الخاصة بي ، تلقيت تعليقًا مفاده أن بعض الخصائص في مكون React مربكة ، مما أثار أسئلة أوسع حول كيفية استخدام المكون. في النهاية ، قمت بإزالة الخصائص من المكون الأصلي وقمت بإنشاء مكون منفصل لتوضيح سلوك كل منها والتأكد من أنه يمكن استخدام كليهما في أماكن أكثر.
2. النظر في الأمن
لا تنس أن بعض التغييرات يمكن أن تؤثر أكثر من مجرد قاعدة الشفرة. يوصي Rudder بتقييم ما إذا كان المستخدم "يمكنه استخدام هذه الوظيفة لمضايقة شخص ما أو يمكن أن يسيء استخدام النظام". على سبيل المثال ، إذا كانت الميزة الجديدة في طلب السحب تتضمن إدخال المستخدم ، ابحث عن حقن SQL ، والوصول إلى البيانات ، والبرمجة النصية عبر المواقع ، و الثغرات الأمنية الأخرى.
3. التركيز على الحشرات
زملائك المساهمين في الكود - بصرف النظر عن مدى قدرتهم الآلية - هم بشر ، وقد يكسر البشر وظائفهم أو ينسونها. لذا تأكد من "مراجعة الاختبارات بنفس أهمية بقية الكود" ، كما تنصح Abhishek Pillai ، وهي شركة رائدة في التقنية في "المعلمين يدفعون المعلمين". "سيمنعون أي أخطاء جديدة ويكونون بمثابة شكل من أشكال التوثيق لأي شخص آخر يعمل على ذلك في المستقبل."
يمكن أن تساعدك قراءة الاختبارات في فهم وظائف ميزة جديدة ومعرفة الحالات المختلفة التي ستقدمها ، بينما يمكن أن يساعدك تحليل الاختبارات في الإشارة إلى الحالات المفقودة والعثور على ميزات غير موجودة في هذا PR. إذا لم تكن هناك اختبارات مضمنة في تغيير الرمز ويبدو أنها ذات صلة ، فمن المناسب طلبها في المراجعة.
لكن الاختبارات ليست كل شيء. "لا تضع الكثير من الثقة في النظام" ، يحذر دونو. "مجرد إجراء الاختبارات لا يعني عدم وجود أخطاء."
قد ترغب أيضًا في "تشغيل التطبيق محليًا لاختباره وظيفيًا والتأكد من أنه يعمل. يقول ريان فيرنر ، مطور برامج في 8th Light: إذا لم ينجح هذا ، فلن يكون هناك أي فائدة في إجراء مزيد من المراجعة. على الرغم من أن بعض المراجعين لا يعتقدون أن الاختبار اليدوي يجب أن يكون جزءًا من عملية مراجعة الشفرة - جزئيًا بسبب الوقت الذي يستغرقه - تعتقد Verner أنها طريقة سريعة لتحديد ما إذا كان يجب استثمار مزيد من الوقت في المراجعة وكذلك استراتيجية للمساعدة في تقليصها نمو الأخطاء المتراكمة.
4. كن لاعب فريق
يأخذ كليشيه معنى جديدًا عندما يتعلق الأمر بمراجعة الكود. يقول فيرنر ، الذي ينادي بإحساس "الملكية الجماعية": "خذ وقتًا للمراجعة لأنه قاعدة رموز الجميع" ، ويجب أن تعمل ، بصفتك المراجع ، على حماية تراكم الأخطاء من النمو بشكل أكبر بهدف منحك فريق أقل العمل أسفل الخط.
يستخدم بيلاي صورة متحركة للاحتفال بالموظفين الرئيسيين المعتمدين والمستعدين للاندماج في العلاقات العامة.
في الوقت نفسه ، يشجع Charles Luxton ، وهو رائد فني في The Muse ، المراجع على فهم وتذكر أولويات الفريق. نظرًا لتزايد المواعيد النهائية والخلافات السريعة ، مما يؤدي في بعض الأحيان إلى إنشاء عنصر مهام المهام المتراكمة التي تضمن إجراء تحسينات في المستقبل ووضع تعليق على الكود المعني في غضون ذلك هو Band-Aid الذي تحتاجه من أجل حافظ على فريقك سعيد.
أخيرًا ، إن سؤال نفسك عما إذا كان الكود سيكون منطقيًا بالنسبة إلى شخص انضم للتو إلى الفريق وكان يقرأه في الأسابيع القليلة الأولى ، سيساعد في جعل الشفرة قابلة للقراءة ومفهومة.
5. استخدم عملية التعلم ومشاركة المعرفة
تتيح عملية المراجعة لكل شخص معني مكانًا للحصول على مزيد من المعلومات حول قواعد البيانات واللغات والأطر وأفضل الممارسات.
ينصح مات جيفري ، أحد رواد التقنية في The Muse ، المراجع "بفهم التغييرات بشكل معماري. إحدى الطرق هي قراءة أسماء الملفات لأنها تساعد في إعطاء السياق. على سبيل المثال ، إذا كنت تبحث عن تغيير في طبقة الوصول إلى البيانات أنت تعلم أنك لا تتعامل مع منطق العمل أو واجهة المستخدم. "
يمكنك استخدام تعليق العلاقات العامة على جيثب لتبادل الوثائق.
عندما تتعلم من تغييرات التعليمات البرمجية ، فأنت أيضًا تمتلك فرصة لمشاركة المعرفة. يقول لكستون: "من الأفضل أن تشرح رأيك وتدعمه بالوثائق". لا تساعد الروابط التي تقدمها إلى الأدلة الداعمة والمقالات الموثوق بها المراجع وكاتب الشفرات في استكشاف الطرق المختلفة لأنها تتخذ قرارًا نهائيًا ، بل تعزز أيضًا معرفتهم بالبرمجة.
بينما تضع هذه النصائح في الاعتبار ، تذكر أيضًا أن المراجعة هي وقت لممارسة مهارات الأشخاص لديك. يقول رودر: "أعط الناس فائدة الشك الذي فكروا به في مقاربتهم ، وأشاروا إلى إمكانيات مختلفة أثناء محاولة تبديد موقف الدفاع". "أترك التعليقات بالكامل وأعلق تعليقًا كاملاً - إليك ما هو رائع ، إليك ما يمكن تحسينه ، إليك ما يجب تغييره قبل الدمج."
مع هذا النوع من النهج ، لن تقوم فقط بحماية قاعدة الكود الخاصة بك من الديون التقنية والتهديدات الأمنية والأخطاء ، ولكنك ستقوم أيضًا ببناء فريقك.
