إتقان مراجعة الكود
إتقان مراجعة الكود
في شركات مثل Google وMeta وStripe، مراجعة الكود ليست إجراءً شكلياً — بل هي بوابة الجودة الأساسية قبل أن يصل أي تغيير إلى الإنتاج. يقول المهندسون في تلك الشركات إن ثقافة المراجعة الجيدة تكتشف أخطاء أكثر من أي مجموعة اختبارات آلية، وتنشر المعرفة المعمارية أسرع من أي ويكي، وهي الآلية الرئيسية التي يتعلم من خلالها المهندسون الجدد التفكير كالمخضرمين. يعلّمك هذا الدرس كيفية إدارة هذه العملية: هيكلة طلبات السحب لمراجعة سريعة وعالية الجودة، وبناء ثقافة تغذية راجعة لا تولّد دفاعية، واستخدام أدوات مثل CODEOWNERS وأتمتة المراجعة للتخلص من الاختناقات البشرية.
طلبات السحب: تشريح تغيير قابل للمراجعة
المؤشر الأقوى على جودة المراجعة هو حجم الفرق. طلب السحب الذي يحتوي على 50–200 سطر مُعدَّل يُراجَع بعناية؛ أما الذي يحتوي على 2000 سطر فيُصادَق عليه دون تمحيص لأنه لا يستطيع أي مراجع الإمساك بالسياق الكامل في ذاكرة العمل. في Google، يعرض نظام المراجعة الداخلي (Critique) درجة صحة تتدهور بشكل حاد بعد 400 سطر. السبب إدراكي: يبدأ المراجعون بالتصفح السطحي، ويفوتهم أخطاء المنطق، ويوافقون فقط لرفع الحصار عن المؤلف.
- قضية واحدة لكل طلب سحب. إعادة الهيكلة وإضافة الميزة وإصلاح الخطأ ثلاثة طلبات سحب منفصلة — لا ثلاثة أقسام في طلب سحب واحد ضخم.
- راجع عملك أولاً. افتح الفرق الخاص بك في واجهة GitHub قبل طلب المراجعين. ستكتشف 30–40 % من التعليقات قبل أن يراها أي شخص آخر.
- اكتب وصفاً ذا معنى. اشرح لماذا التغيير موجود، واربط التذكرة، وصف نهج الاختبار، وأشر إلى أي مقايضات مقصودة. لا ينبغي أن يضطر المراجعون إلى التبديل إلى Jira لفهم ما يقرؤونه.
- طلبات السحب المسودة للحصول على تغذية راجعة مبكرة. افتح طلب سحب في وضع المسودة بمجرد أن يكون لديك هيكل أولي. هذا يدعو إلى نقاش معماري قبل أن تستثمر أياماً في الاتجاه الخاطئ.
main. يدعم GitHub وأدوات مثل Graphite هذا بشكل أصلي. يقرأ المراجعون كل طبقة باستقلالية؛ والدمج النهائي يكون دمجاً نظيفاً على main.
قالب طلب السحب: سياق متسق على النطاق الواسع
يفرض قالب طلب السحب الحد الأدنى من السياق الذي يحتاجه كل مراجع. ضع ملف PULL_REQUEST_TEMPLATE.md في مجلد .github/ وسيملأ GitHub تلقائياً نص كل طلب سحب جديد بهذا المحتوى.
ثقافة المراجعة: تغذية راجعة تحسّن الكود دون كسر الأشخاص
يميّز دليل مراجعة الكود الداخلي لـ Google بين الملاحظات البسيطة (تفضيلات أسلوبية طفيفة لا ينبغي أن تمنع الدمج)، والاقتراحات (تحسينات اختيارية)، والتعليقات الإلزامية (يجب حلها)، والأسئلة (المراجع يحتاج توضيحاً، ليس بالضرورة تغييراً). استخدام هذه التصنيفات في كل تعليق يزيل الغموض ويمنع المؤلفين من قضاء ساعات على تغذية راجعة لم يكن المراجع يعتبرها إلزامية أصلاً.
- علّق على الكود، لا على الشخص. "هذه الدالة لها ثلاث مسؤوليات" بدلاً من "من الواضح أنك لم تفكر في هذا."
- اشرح السبب وراء كل تعليق إلزامي. التعليق الذي يقول فقط "أعد هيكلة هذا" لا يعلّم شيئاً ويُحبط المؤلف.
- وافق مع التعليقات. إذا كانت البنود المتبقية ملاحظات بسيطة، فوافق ودع المؤلف يقرر — لا توقف نشراً بسبب اسم متغير.
- استجب خلال يوم عمل واحد. قوائم الانتظار الطويلة للمراجعة هي السبب الرئيسي لتخلي الفرق عن العملية والدمج دون مراجعة. إذا لم تستطع المراجعة بنهاية اليوم، قل ذلك واقترح شخصاً آخر.
CODEOWNERS: تعيين المراجعين تلقائياً
يقوم ملف CODEOWNERS (الموضوع في .github/ أو جذر المستودع أو docs/) بتعيين أنماط مسارات الملفات للمستخدمين أو الفرق على GitHub الذين يمتلكون ذلك الكود. يطلب GitHub تلقائياً مراجعة من المالك المطابق عندما يلمس طلب السحب تلك المسارات. يزيل هذا الخطوة اليدوية لوضع علامة على المراجعين ويضمن أن الشخص الأكثر سياقاً يرى دائماً التغييرات ذات الصلة.
عند دمجه مع قواعد حماية الفروع التي تتطلب موافقة CODEOWNERS، تحصل على ضمان صارم: لا يمكن دمج هجرة دون موافقة مهندس قاعدة البيانات، ولا يمكن لأحد تجاوزها عن طريق الخطأ. قم بتكوين هذا في GitHub ضمن Settings → Branches → Branch protection rules → Require review from Code Owners.
أتمتة المراجعة: دع الروبوتات تتعامل مع العمل الميكانيكي
كل تعليق يكتبه مراجع بشري حول التنسيق أو ترتيب الاستيراد أو تغطية الاختبار هو عبء إدراكي ينبغي أتمتته. الهدف هو جعل البشر يركزون على المنطق والمعمارية والسلامة — وكل شيء آخر يعمل في CI قبل أن يفتح المراجعون الفرق حتى.
إضافة أداة تصنيف حجم طلب السحب تجعل حجم الفرق مرئياً للمراجعين. تصنيف XL هو إشارة اجتماعية بأن طلب السحب يحتاج إلى تقسيم — لا سياسة مطلوبة، مجرد رؤية.
git rebase --autosquash قبل الدمج.
إغلاق الحلقة: مقاييس المراجعة المهمة
الفرق عالية الأداء تتتبع صحة المراجعة كمياً. المقاييس الأربعة للقياس (عبر API GitHub أو أداة مثل LinearB أو DX) هي: الوقت حتى أول مراجعة (الهدف أقل من 4 ساعات)، ومدة دورة المراجعة (الوقت من آخر push حتى الموافقة، الهدف أقل من 24 ساعة)، ووقت دورة طلب السحب (من الفتح حتى الدمج، الهدف أقل من يومين لمعظم التغييرات)، وعدد تكرارات المراجعة (كم جولة ذهاباً وإياباً قبل الموافقة — أكثر من 3 يشير إلى أن الوصف كان غير واضح أو طلب السحب كان كبيراً جداً). يجعل تتبع هذه المقاييس الاختناقات مرئية ويمنح الفرق هدفاً ملموساً للتحسين.