مراجعة الشيفرة باستخدام الذكاء الاصطناعي
في الدرس السابق تعلّمنا كتابة وصف PR يلخّص عدة commits. الآن، بعد أن أصبح الـ PR مفتوحًا وبعد أن عمل الـ CI، تأتي الخطوة الأسهل تجاوزًا: قراءة الـ diff نفسه، تمامًا كما تقرأ PR كتبه مطوّر بشري. الـ CI الأخضر يعني أن الشيفرة لم تكسر اختبارًا قائمًا — لكنه لا يعني أن الـ diff يفعل بالضبط ما طُلب ولا ش
فحص diff كتبه وكيل يشبه تفقّد طرد وصل إلى بابك قبل أن توقّع على استلامه — لا يكفي أن يكون الصندوق مغلقًا ويبدو سليمًا من الخارج، بل عليك فتحه والتأكد من أن ما بداخله هو فعلًا ما طلبته، وليس شيئًا إضافيًا.
- diff الخاص بالـ Pull Request
- العرض الكامل لكل سطر مُضاف ومحذوف في الـ PR، بصيغة unified diff؛ وهو ما تقرؤه سطرًا سطرًا للتحقق من أن التغيير يفعل بالضبط ما طُلب.
- طلب تغييرات (Request changes)
- حكم مراجعة يمنع الدمج حتى يصحّح المؤلف نقاطًا محددة؛ يختلف عن التعليق الحر — فهو يمنع الدمج فعليًا حتى تُعالَج النقطة.
- CI أخضر (وما لا يعنيه)
- تأكيد أن الشيفرة اجتازت lint وفحص الأنواع والاختبارات القائمة؛ لكنه لا يؤكد أن الـ diff محصور فيما طلبته التذكرة، ولا يفحص القيم الحدّية التي لا يغطّيها أي اختبار.
- تغيير غير ذي صلة داخل الـ diff
- تعديل يظهر في نفس الـ PR لكنه غير مرتبط بالإصلاح المطلوب؛ حتى لو مرّ عبر الـ CI بهدوء، يجب إخراجه أو مراجعته على حدة.