تكتب مساعدات الذكاء الاصطناعي دالة كاملة في ثوانٍ، لكن الحكم على صحة هذا الكود وأمانه وقابليته للصيانة لا يزال مسؤولية الإنسان. هذه المقالة قائمة عملية لمراجعة الكود (code review) يمكنك تطبيقها قبل دمج أي كود كتبه الذكاء الاصطناعي. الهدف ليس رفض الكود، بل جعله شيئاً يفهمه الفريق ويستطيع تحمّل مسؤوليته.
شرحنا المشكلة التي تقف خلف هذه القائمة في مقالة دين المعرفة: الكود موجود، لكن لا أحد يعرف لماذا يعمل بهذه الطريقة. وهذه المقالة تكمّل تلك. فبدل التشخيص، تقدّم فحوصاً محددة يمكن تنفيذها في كل pull request.
قسّم الـ PR وأثبت أنك تستطيع شرح الكود
يستطيع الذكاء الاصطناعي تعديل عشرات الملفات بطلب واحد. وأي pull request أكبر من أن يُراجَع هو عملياً pull request لم يُراجَع. ابدأ بفحص حجم التغيير.
- PR واحد لهدف واحد. لا تجمع ميزة جديدة وإعادة هيكلة وتحديث تبعيات في PR واحد.
- افصل تغييرات إعادة التسمية والتنسيق عن تغييرات المنطق. يجب أن يرى المراجع الفرق الحقيقي في السلوك.
- احذف الكود الذي لم تطلبه. كثيراً ما يضيف الذكاء الاصطناعي دوال مساعدة غير مستخدمة وطبقات تجريد زائدة وكتلاً مكررة.
اختبار الشرح: يجب أن يستطيع من فتح الـ PR شرح الكود لزميل دون الرجوع إلى الذكاء الاصطناعي. وإن لم يستطع الإجابة عن هذه الأسئلة فلا يُدمج الكود: كيف يتصرف هذا الكود عند مدخل معيّن؟ لماذا اختير هذا الأسلوب وما البديل؟ ماذا ينكسر إذا حُذف هذا السطر؟ من لا يستطيع شرح الكود لن يستطيع إصلاحه عندما يفشل في الإنتاج.
اشتق الاختبارات من المتطلب لا من الكود
غالباً ما يكتب الذكاء الاصطناعي الكود واختباراته معاً. وتميل هذه الاختبارات إلى تأكيد ما يفعله الكود لا ما يطلبه المتطلب، فتكتب الخطأ نفسه مرتين. اشتق الاختبارات من المتطلب بدلاً من ذلك.
- حوّل المتطلب إلى معايير قبول: «عند هذا المدخل تُرجَع هذه النتيجة».
- اكتب سيناريوهات الاختبار من معايير القبول دون قراءة التنفيذ.
- أضف الحالات الحدّية: مدخل فارغ، null، قيم ضخمة جداً، طلبان في اللحظة نفسها، مستخدم غير مخوّل.
- أثبت أن الاختبار قادر فعلاً على الفشل. اكسر الكود عمداً وتأكد أن الاختبار يفشل.
الاختبارات الخضراء وحدها لا تكفي. فالتأكيدات التي لا تتحقق من شيء والاختبارات المبالغ في استخدام mocks فيها تبدو خضراء لكنها لا تمنح ثقة. اسأل عمّا يقيسه كل اختبار فعلاً.
فحص التبعيات والأسرار والأمان
عندما يقترح الذكاء الاصطناعي كوداً فإنه يضيف حزماً أيضاً. وكل تبعية جديدة هي خطر جديد يتحمله الفريق.
- هل الحزمة موجودة فعلاً وهل هي الحزمة الصحيحة؟ قد يقترح الذكاء الاصطناعي حزماً غير موجودة أو بأسماء مشابهة. تحقق من الاسم في المصدر الرسمي ولا تتجاهل خطر تثبيت حزمة خبيثة بسبب خطأ إملائي.
- افحص الترخيص وحالة الصيانة وتاريخ آخر إصدار. هل أُضيفت تبعية ثقيلة لمهمة صغيرة؟
- هل يظهر تغيير ملف القفل (lock file) في الـ PR وهل يطابق المتوقع؟ شغّل ماسح التبعيات للكشف عن الثغرات المعروفة.
- هل يوجد مفتاح API أو token أو كلمة مرور في الكود أو ملفات الاختبار أو أمثلة الإعدادات؟ قد تكون قيم حقيقية لصقتها في الـ prompt قد انتقلت إلى الكود.
- شغّل فحص الأسرار (secret scanning) في pre-commit وفي CI. وإذا شككت في تسرّب مفتاح فلا يكفي حذفه، بل جدّده (rotate). فهو يبقى في تاريخ git.
- هل يُتحقق من كل مدخل يأتي من المستخدم؟ وهل تُنفَّذ فحوص الصلاحيات على الخادم؟ وهل يوجد استعلام مُدمَج بالنصوص معرّض لحقن SQL أو حقن الأوامر؟
للاطلاع على قائمة أوسع، راجع قائمة التحقق الأمنية من vibe code إلى الإنتاج.
معالجة الأخطاء والتسجيل والأداء وسلامة البيانات
يعمل الكود الذي يولّده الذكاء الاصطناعي عادةً جيداً في المسار السعيد. أما المشكلات فتظهر في مسار الفشل وتحت الضغط وعند التزامن. افحص هذه المجالات الأربعة كلاً على حدة.
- معالجة الأخطاء: لا تُقبل كتل catch الفارغة التي تبتلع الأخطاء بصمت، ولا الرسائل العامة التي تجيب عن كل شيء بالطريقة نفسها. يجب إما معالجة الخطأ أو تمريره إلى الأعلى. وتحتاج استدعاءات الخدمات الخارجية إلى مهلة زمنية (timeout) وإعادة محاولة محدودة ومسار فشل واضح.
- التسجيل (logging): هل يوجد سياق كافٍ لتتبع الفشل (معرّف الطلب، اسم العملية)؟ يجب ألا تُكتب كلمات المرور والـ tokens والبيانات الشخصية في السجلات.
- الأداء: ابحث عن استعلامات قاعدة البيانات داخل الحلقات (N+1)، والقوائم بلا ترقيم صفحات، والمرشحات بلا فهرس، والحسابات المتكررة بلا داعٍ. الكود الذي يعمل على 10 سجلات محلياً سيعمل في الإنتاج على ملايين السجلات.
- سلامة البيانات: هل عمليات الكتابة المتعددة داخل transaction واحدة؟ وإذا وصل الطلب نفسه مرتين فهل تظهر نسخ مكررة (idempotency)؟ وهل يمكن التراجع عن الـ migration؟ وهل يدمّر الحذف البيانات نهائياً؟
سجل القرارات المعمارية ومعايير القرار قبل الدمج
يتخذ الذكاء الاصطناعي قرارات معمارية بصمت: طبقة جديدة، أو أسلوب مختلف لإدارة الحالة، أو مكتبة أخرى. ولجعلها مرئية احتفظ بسجل قرار معماري (ADR) قصير: السياق والقرار المتخذ والبدائل المرفوضة والنتائج. تكفي بضع جمل، ويبقى السجل دائماً داخل المستودع. وبعد ستة أشهر ستجد هناك إجابة سؤال «لماذا فعلنا ذلك بهذه الطريقة».
استخدم هذه المعايير لقرار الدمج:
- للـ PR هدف واحد وحجم قابل للمراجعة.
- الكاتب يشرح الكود دون الرجوع إلى الذكاء الاصطناعي.
- الاختبارات مشتقة من المتطلب وتغطي الحالات الحدّية.
- التبعيات الجديدة موثّقة، ولا أسرار في الكود أو في التاريخ.
- أسئلة معالجة الأخطاء والتسجيل والأداء وسلامة البيانات لها إجابات.
- أي قرار يؤثر في البنية المعمارية مسجَّل.
إذا لم يتحقق بند واحد فهناك ثلاثة خيارات: أصلح أو قسّم أو ارفض. الدمج بحجة «سننظر لاحقاً» ينقل الدين إلى الإنتاج. وفي المجالات عالية الخطورة مثل المدفوعات والمصادقة والبيانات الشخصية، اشترط مراجعاً بشرياً ثانياً.
الأسئلة الشائعة
هل يحتاج الكود الذي يكتبه الذكاء الاصطناعي إلى عملية مراجعة منفصلة؟ لا حاجة إلى عملية منفصلة، لكن ينبغي تطبيق العملية نفسها بصرامة أكبر. فلأن الكاتب لم يبنِ المنطق بنفسه، تزداد أهمية اختبار الشرح واشتقاق الاختبارات من المتطلبات.
هل أدمج الكود إذا نجحت الاختبارات؟ لا. إذا كُتبت الاختبارات أيضاً بالذكاء الاصطناعي فقد تؤكد فقط ما يفعله الكود. تأكد أن الاختبارات مشتقة من المتطلب وأنها تفشل فعلاً عندما تكسر الكود.
هل أستخدم الذكاء الاصطناعي لإجراء مراجعة الكود؟ نعم كمرحلة أولى، فهو يساعد في التقاط الأخطاء الواضحة والفحوص الناقصة. لكن قرار الدمج يعود إلى إنسان يتحمل مسؤوليته.
ماذا أفعل إذا أودعت سراً في commit عن طريق الخطأ؟ ألغِ المفتاح فوراً وأصدر مفتاحاً جديداً (rotate). لا يكفي حذفه من الملف لأنه يبقى في تاريخ git وفي أي نسخ مستنسخة. ثم افحص كيف حدث التسرّب وأضف secret scanning.
إذا أردت تجهيز قاعدة كود أنتجها الذكاء الاصطناعي للإنتاج، أو بناء انضباط المراجعة هذا في فريقك، فاطلع على خدمة vibe-code-to-production وأرسل وضعك عبر نموذج طلب عرض السعر السريع.
خدمات ذات صلة
