كيف نواجه هذا الوضع الذي صار فيه فجأة هذا القدر الكبير من الشيفرة التي يجب مراجعتها وإجراء Review لها؟
ترجمة آلية للمنشور الأصلي، لم يراجعها مترجم بشري. قد لا تكون المعلومات التاريخية محدثة.
كيف نواجه هذا الوضع الذي صار فيه فجأة هذا القدر الكبير من الشيفرة التي يجب مراجعتها وإجراء Review لها؟
انتقل عنق الزجاجة من كتابة الشيفرة إلى مراجعتها، وجزء كبير من عمل فريق التطوير هو الحكم على ما جرى تطويره وكيف جرى تطويره.
إحدى الطرق التي وجدتها تسهّل الأمر عليّ وعلى الفريق هي إضافة تعليمات للوكيل الذي يكتب وصف الـ PR (Pull Request) (سواء كان أمرًا (command) في Cursor أو عبر GitStream من LinearB) وفق منهجية من 4 مراحل:
1. ما المشكلة التي أردنا حلها
2. ماذا تغيّر وأين (أي ملفات)
3. كيف يعمل ذلك عمليًا (التدفق / الـ flow)
4. ما المخاطر
ما إن نفصّل الـ PR بهذه الدقة منذ مرحلة الوصف (Description)، يصبح طريق فهم الشيفرة أقصر وأسهل بكثير، فأنا أعرف مسبقًا ما أتوقع أن أراه في الشيفرة نفسها، وأحيانًا ألتقط أيضًا نقاطًا معمارية أو مخاطر أثارها الوكيل نفسه قبل أن أنظر إلى سطر شيفرة واحد
نجح هذا معنا بشكل جيد جدًا، حتى إنني حين شاركته مع بقية قادة الفرق قرروا تبنّيه في كل قسم الأبحاث والتطوير (R&D) لكل PR يُفتح 😇
