مراجعة diff
اقرأ بالترتيب الصحيح، وابحث أولًا عمّا لم تطلبه.
مراجعة ما تنتجه الآلة
يصعب مراجعة diff ينتجه وكيل ذكي لسبب محدد: إنه مكتوب بإتقان زائد. فشيفرة زميل مستعجل تحتوي على قرائن — اسم متسرَّع، أو مسافة بادئة مضطربة، أو تعليق «TODO fix later». وهذه المخالفات إشارات تلفت الانتباه إلى موضع الخطر. أما الوكيل فينتج نصًّا متقنًا بالدرجة نفسها في كل موضع: فالالتفاف المشبوه والتصحيح السليم لهما الشكل الطباعي نفسه، والتعليقات الحسنة الصياغة نفسها، والثقة نفسها. وهكذا لا يعمل كاشف الشذوذ المعتاد لديك، فتوافق على diff من 300 سطر في أربع دقائق وأنت تقول لنفسك إنه نظيف.
الفخ الثاني هو ترتيب القراءة. أمام أي diff، الغريزة أن تبدأ من أعلى الملف الأول وتمضي نزولًا. وعلى شيفرة بشرية يصلح ذلك إلى حد ما، لأن كاتبها فعل ما طلبتَه منه، لا أكثر ولا أقل. أما على شيفرة الوكيل، فيجعلك ذلك تقرأ طويلًا التغيير المتوقع — وهو الجزء الأقل خطرًا، لأنك أنت من حدده — ثم تصل مُرهَقًا إلى الملف السابع، الذي لم تذكره قط، وحيث توجد المشكلة الحقيقية. أما المراجعة الفعالة فتعكس المنطق: نبحث أولًا عمّا لم يُطلب، ثم نتحقق بعد ذلك فقط مما طُلب.
القراءة بترتيب الخطر
خمس مراحل، من الأعلى مردودًا إلى الأعلى كلفة. يمكن لأي منها أن يؤدي إلى رفض الـ diff ويعفيك من المراحل التالية.
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش