John Allspaw: مراجعة الكود لم تكن في أصلها عملية كشف أخطاء، والأدوات الآلية تأخذ الجزء السهل
إذا صارت الأدوات الآلية تكشف الأخطاء، فالسؤال لم يعد إن كانت ستغني عن المراجعة، بل من سيتولى الجزء الأصعب: الفهم المشترك والحكم وملاحظة ما هو غائب.
وسم
إذا صارت الأدوات الآلية تكشف الأخطاء، فالسؤال لم يعد إن كانت ستغني عن المراجعة، بل من سيتولى الجزء الأصعب: الفهم المشترك والحكم وملاحظة ما هو غائب.
الخسارة الحقيقية من تسليم العمل كاملًا للأدوات ليست كمية الكود المكتوب يدويًا، بل فقدان القدرة على الحكم على جودة ما كُتب، وهي المهارة التي يُدفع للمطور أجره عليها.
الـ agents صارت تكتب أسرع مما يستطيع البشر مراجعته، ومراجعة الكود تتعثر غالبًا في بناء الصورة الكاملة لا في قراءة السطور.
الكود المتراكم من الـ agents لا ينتج عن ضغط الوقت أو المال كما عند البشر، بل عن تعليمات تطلب الإضافة ولا تطلب الدمج، وهذا ما يغيّر سؤال المراجعة.
أداة تقول "لا أستطيع الحكم" بدل إظهار لون أخضر صُممت ليُعتمد عليها، ومراجعة الأمان تتحول في الفرق الصغيرة من مهمة مؤجلة إلى خطوة في الـ PR.
المال لم يُصرف على كتابة الكود بل على طابور المراجعة، لأن المشاريع المفتوحة تخسر مساهميها حين تنتظر مساهماتهم طويلًا دون رد.
حين يكتب الـ agent في ساعة ما كان يستغرق أسبوعًا ويبقى المراجع واحدًا، يتحول السؤال في الفرق من من يراجع إلى متى تحدث المراجعة.
الخلاف الحقيقي ليس حول استخدام الذكاء الاصطناعي، بل حول من يُفترض أن يفهم الكود حين يتعطل، وفرق كثيرة تعمل على المستودع نفسه دون اتفاق على ذلك.
الاعتراض على reduce مفهوم من طريقة قراءتها، لكن الملاحظة الأثقل في التدوينة أن هذا الاعتراض صار أقل، ربما لأن مراجعة الكود نفسها صارت أقل تدقيقًا.
حين يصبح كاتب الملاحظة هو من يقرر أنها عولجت، يصبح الـ PR أنظف وذاكرته أقصر، والقيمة الحقيقية تعتمد على ما إذا كان الفريق يعود إلى نقاشاته القديمة.
الكود المترهل يعمل ويجتاز الاختبارات والمراجعة، لكن تكلفته تظهر في التعديل التالي لا في الـ PR الحالي، ولذلك يصعب رصدها دون مقياس.
انتشار النكتة يعكس تجربة يومية مع أدوات البرمجة الذكية: طلب صغير يعود بتعديلات لم تُطلب، فتصبح مراجعة التغييرات أطول من المهمة نفسها.
مراجعة الكود كانت آخر نقطة يقرأ فيها إنسان ما يدخل المشروع، وأصبح الرد عليها قابلًا للأتمتة، فقد يُدمج تغيير كامل دون أن يقرأه أحد.
كتابة الكود صارت أسرع بمرات، ومراجعته بقيت بالسرعة نفسها، فانتقل عنق الزجاجة من الكتابة إلى الفهم، دون أن يعلن أي فريق هذا القرار.
حين تُملأ خانة الموافقة آليًا لا تتغير شروط الدمج، لكن يتغير معنى الخانة نفسها. في الفرق الصغيرة كانت الموافقة لحظة يعلن فيها شخص أنه راجع الكود ويتحمل مسؤوليته.
حين يفتح الـ agent الـ PR ويصلح الـ CI ويرد على التعليقات بنفسه، تنتقل عنق الزجاجة في الفريق من كتابة الكود إلى مراجعته، دون أن يزيد عدد المراجعين.
الوقت الذي توفره أدوات الذكاء الاصطناعي في الكتابة يُستهلك في المراجعة، بينما يبقى أكبر مكسب في تنظيم يوم العمل، وهو مكسب لا يُشترى.
حق فتح pull request لم يعد متاحًا للجميع بالتساوي بل صار مقننًا بحسب علاقة المساهم بالمشروع، فيصبح أول PR من مساهم جديد عيّنة تُقرأ لا محاولة من محاولات كثيرة.
حين تنخفض تكلفة تشغيل النموذج نفسه، تتحول ميزة كانت أساس منتج باشتراك شهري إلى بند صغير في فاتورة غيره، ويتغير حساب الجدوى لكل من يبني فوق النماذج.
حين يستطيع المراجع الآلي قراءة التذكرة ومعايير الفريق، يصبح أول ما يكشفه ليس أخطاء الكود بل غياب هذه المعايير أصلًا عن أي مكان مكتوب.
صعوبة تقسيم التغييرات الكبيرة لم تكن في التقسيم بل في صيانة السلسلة بعد كل دمج، وحين تتولى المنصة ذلك يصبح أصغر تغيير مفهوم هو وحدة المراجعة.
تسريع أول خطوة في التسليم لا يسرّع التسليم كله، بل يكدّس العمل أمام أضيق خطوة، وهي في أغلب الفرق اليوم مراجعة الكود.
لا تصويت ولا لجنة في تطوير Linux، والآلية الوحيدة لحسم الخلاف موجودة في الرخصة نفسها، ولذلك تحدد الرخصة إن كان لدى من يبني على مشروع مفتوح باب خروج حقيقي.
إعادة كتابة كانت مستحيلة على فريق صغير صارت ممكنة بالمال، لكنها تنتج codebase يعمل ولم يقرأه أحد في الفريق سطرًا سطرًا.
القيد الحقيقي على سرعة الفرق لم يعد كتابة الكود بل مراجعته، فالكود الذي لا يملكه أحد بالكامل يحتاج إلى من يملك مراجعته بالكامل.