كل طبقة مراجعة إضافية تُبطئ فريقك

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

هذا النمط شائع لدرجة أنه أشبه بقانون في السلوك التنظيمي: كل حادثة تولّد طبقة مراجعة جديدة، ولا تُزال أي طبقة مراجعة أبداً. والنتيجة عملية مراجعة مُحسّنة لمنع الحادثة الأخيرة على حساب منع كل تقدم مستقبلي.

رياضيات طوابير المراجعة

كل طبقة مراجعة لا تضيف فقط، بل تضرب. إذا استغرقت مراجعة واحدة في المتوسط 4 ساعات (ليس وقت المراجعة نفسها البالغ 20 دقيقة، بل الوقت الذي يقضيه طلب الدمج في الطابور بانتظار المراجع)، فإن مراجعتين متتاليتين تستغرقان 8 ساعات، وثلاث تستغرق 12، وأربع تستغرق 16.

لكن الأمر أسوأ بسبب تبديل السياق. يرسل المطور طلب الدمج ثم يبدأ عملاً جديداً. وعندما تصل ملاحظات المراجعة بعد ساعات، عليه أن يعود إلى العمل القديم، ويستعيد السياق، ويعالج الملاحظات، ثم يرسل من جديد وينتظر مرة أخرى. كل جولة مراجعة تكلّف 30 إلى 60 دقيقة من تكلفة تبديل السياق، إضافة إلى وقت الانتظار في الطابور.

وهناك أيضاً أثر التسلسل. إذا طلب المراجع A تعديلات، يعالجها المطور ويعيد الإرسال. ثم يراجع المراجع B (الذي لم يرَ طلب الدمج بعد) ويطلب تعديلات مختلفة، فيعالجها المطور. الآن يحتاج المراجع A إلى إعادة المراجعة للتحقق من تنفيذ ملاحظاته، لكنه انتقل إلى أعمال أخرى، وعاد طلب الدمج إلى الطابور.

Timeline of a PR through a 3-reviewer process:
Day 1 9:00  — Developer submits PR
Day 1 14:00 — Reviewer A reviews, requests changes
Day 1 15:00 — Developer addresses feedback, resubmits
Day 2 10:00 — Reviewer B reviews, requests different changes
Day 2 11:00 — Developer addresses, resubmits
Day 2 16:00 — Reviewer A re-reviews, approves
Day 3 11:00 — Reviewer C reviews, approves
Day 3 11:30 — Reviewer B re-reviews, approves
Day 3 12:00 — PR merges
Elapsed time: ~3 business days
Actual review time: ~90 minutes total
Actual code change time: ~2 hours
Time waiting in queues: ~22 hours
Queue time is 80% of the total elapsed time.

مفارقة الجودة

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

مراجع واحد متأنٍ يلتقط مشكلات حقيقية: أخطاء منطقية، وحالات حدّية فائتة، ومشكلات أمنية، وملاحظات على تصميم الواجهات البرمجية (API). المراجع الثاني يلتقط أحياناً أشياء فاتت الأول، ربما في 10 إلى 20% من الحالات. أما المراجع الثالث فنادراً ما يلتقط شيئاً لم يلتقطه الأولان. القيمة الهامشية لكل مراجع إضافي تنخفض بحدة.

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

المفارقة: إضافة طبقات مراجعة لتحسين الجودة قد تقلل الجودة فعلاً، لأنها تخلق حوافز (طلبات دمج أكبر، ومراجعات متسرعة، وفروع قديمة) تُقوّض عملية المراجعة نفسها.

ما الذي تمنعه عمليات المراجعة الثقيلة فعلاً؟

غالباً ما تُبرَّر عمليات المراجعة بحوادث محددة، مثل «شحنّا خطأً لأن أحداً لم يراجع الكود». لكن السؤال عما إذا كانت المراجعة ستلتقط خطأً بعينه يختلف عن السؤال عما إذا كان شرط المراجعة يحسّن النتائج الإجمالية.

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

ما يمنع حوادث الإنتاج فعلاً هو الاختبار والمراقبة والقدرة على النشر والتراجع بسرعة. فريق يطلق التحديثات بسرعة مع اختبارات جيدة، ومفاتيح ميزات (feature flags)، وتراجع فوري، سيكون لديه حوادث إنتاج أقل من فريق لديه أربع طبقات مراجعة لكن دون اختبارات تكامل، ودورات نشر تستغرق ساعة.

القدر الصحيح من المراجعة

مراجعة الكود مفيدة. مراجع واحد لكل طلب دمج، مع توقعات واضحة عما يُراجَع، هو النقطة المثالية لمعظم الفرق. إليك كيف يبدو ذلك عملياً.

• مراجع واحد، لا اثنان أو ثلاثة. المراجع الأول يلتقط 80% مما ستلتقطه المراجعة أصلاً. المراجع الثاني يضيف قيمة هامشية بتكلفة كبيرة. احتفظ بعمليات المراجعة المتعددة للتغييرات عالية المخاطر فعلاً، مثل ترحيلات قواعد البيانات، وتغييرات المصادقة، وتعديلات الواجهات البرمجية العامة.
• حدّد وقتاً لطابور المراجعة. إذا لم تُراجَع طلبات الدمج خلال 4 ساعات، فهذا فشل في العملية، وليس مشكلة مراجع كسول. على الفريق أن يعطي الأولوية لسعة المراجعة، أو أن يقبل أن لديه مطورين أكثر مما تستطيع عملية المراجعة استيعابه.
• طلبات دمج صغيرة، لا كبيرة. طلب دمج من 50 سطراً يحصل على مراجعة دقيقة في 10 دقائق، بينما يحصل طلب من 500 سطر على مراجعة سطحية في 30 دقيقة. طلب الـ50 سطراً يحظى بمراجعة أفضل رغم قلة الوقت. حدود الحجم (200 إلى 300 سطر كحد أقصى) أكثر فعالية في تحسين جودة المراجعة من إضافة مراجعين.
• تخطَّ المراجعة للتغييرات منخفضة المخاطر. تغييرات الإعدادات، وتحديثات النصوص، وترقية الاعتماديات، وإضافة الاختبارات، لا تحتاج إلى التدقيق نفسه الذي تحتاجه تغييرات منطق الأعمال. عرّف فئة «منخفضة المخاطر» واسمح فيها بالدمج الذاتي مع مراجعة بعد الدمج.
• أتمتة ما تُتقنه الآلات أفضل. التدقيق اللغوي (linting)، والتنسيق، وفحص الأنواع، وتغطية الاختبارات، كلها مهام مراجعة تنجزها الآلات بسرعة وثبات أكبر من البشر. لا تُهدر انتباه المراجع على أشياء يتكفّل بها فحص CI.

المشكلة الثقافية

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

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

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

إزالة طبقة مراجعة

إذا تراكمت على فريقك شروط مراجعة كثيرة، فإليك طريقة تقليلها دون إثارة الذعر.

ابدأ بقياس عمليتك الحالية. كم يستغرق طلب الدمج من الإرسال حتى الدمج؟ كم من هذا الوقت هو انتظار في الطابور مقابل مراجعة فعلية؟ كم طلب دمج في طابور المراجعة في أي لحظة؟ هذه الأرقام تجعل الكلفة مرئية، فمعظم الفرق تُصدم حين تكتشف أن متوسط طلب الدمج لديها يستغرق 3 أيام.

ثم أجرِ تجربة. لمدة شهر، اطلب مراجعاً واحداً بدلاً من اثنين، وتتبّع المقاييس نفسها. هل تغيّر معدل الحوادث؟ هل تغيّرت جودة الكود، مقاسةً بمعدلات العيوب لا بالانطباعات؟ في الغالب، الجواب: لم تزد الحوادث، وبقيت الجودة كما هي، وتحسّن الإنتاج بشكل ملحوظ.

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