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

لا يوجد تصميم رمز قياسي
لا تستخدم الشيكات الآلية
لا يقوم المبرمجون بتحليل شفرتهم بشكل مستقل.
طلبات تجمع ضخمة
طلبات تجمع غامضة
المواعيد النهائية مفقودة لمراجعة التعليمات البرمجية

لا يوجد تصميم رمز قياسي

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

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

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

لا تستخدم الشيكات الآلية

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

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

لا يقوم المبرمجون بتحليل شفرتهم بشكل مستقل.

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

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

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

طلبات تجمع ضخمة

يتناسب عدد التعليقات على طلب التجمع بشكل عكسي مع عدد التغييرات الواردة فيه. أي ، PR كبيرة → عدد قليل من التعليقات ، PR صغير → العديد من التعليقات.

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

قسّم طلب البركة إلى قطع أصغر لها معنى منفصل عن بعضها البعض. لذلك سوف تساعد على النظر فيها بشكل صحيح وسريع.

طلبات تجمع غامضة

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

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

ستوفر هذه المعلومات سياقًا أفضل للمراجع وبالتالي تسريع مراجعة الشفرة.

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

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

يجب إكمال رمز المراجعة في غضون 48 ساعة من لحظة إرسال طلب التجمع.
للإصلاحات ، الفترة 30 دقيقة.

شكرا للقراءة! :)

كيفية تسريع مراجعة الكود