مراجعة الكود بمساعدة الذكاء الاصطناعي
درس 9 من 12
9مراجعة الكود بمساعدة الذكاء الاصطناعي
الصورة الكبيرةالمراجعة الجيدة تكشف الخطأ قبل أن يصل للمستخدم. المساعد يضيف عينًا ثانية لا تتعب، لكنه أحيانًا يخترع مشكلة أو يفوّت الأهم. أنت القاضي، وهو الشاهد.
ماذا تشاهد في الرسم: دورة المراجعة بالمساعد: لا تُقبل ملاحظة لم تتحقق منها بنفسك.
خارطة هذا الجزء
المفاهيم بالترتيب، اضغط أيًّا منها للقفز إليه:
طريقان إلى نفس الفكرة
مثل أن تطلب من صديق ذكي قراءة رسالتك قبل إرسالها. لو قلت «شوفها» سيقول «جميلة». لو قلت «هذه رسالة لمديري، تأكّد من الأرقام والنبرة وأن الطلب واضح» سيعطيك ملاحظات حقيقية. ومع ذلك، أنت من يقرّر أيها صحيح.
المراجعة الفعالة تعطي النموذج: الفرق فقط لا المستودع كله، والغرض من التغيير، والقيود (الإصدار، الأداء، الأمان)، وقائمة فحص صريحة (صحة، حالات حدّية، أخطاء غير معالجة، حقن، أسرار، أداء N+1، تسمية)، وصيغة مخرجات (ملف:سطر، الخطورة، السبب، سيناريو الفشل). اطلب «سيناريو فشل ملموس» لكل ملاحظة لتقليل الهلوسة. ثم اجمعه مع أدوات ثابتة حتمية (ruff، mypy، eslint، semgrep) لأنها لا تهلوس، ومع الاختبارات.
قبل أن تبدأ
🤖المساعد في المحرّر
دروس هذا المسار الأولى: الإكمال والمحادثة.
🔀Git
تعرف git diff وطلبات الدمج.
الفكرة الجوهرية
1طلب مراجعة يعطي نتيجة
قارن الطلبين. الأول يعطي مديحًا عامًا، والثاني يعطي ملاحظات تُختبر:
Bad: "Review this code." Good: Context: Flask API, Python 3.12, PostgreSQL. This diff adds an endpoint that lets a user download their own invoices. Check, in order: 1. Can a user reach another user's invoice? 2. Unhandled errors and missing input validation. 3. SQL built from strings. 4. Edge cases: empty list, very large list, missing id. For each finding give: file:line, severity (high/medium/low), a concrete request that triggers it, and the smallest fix. If you find nothing for an item, say so. Do not comment on style. <diff here>
2فرز الملاحظات
كل ملاحظة تقع في واحدة من ثلاث: صحيحة (أعد إنتاجها باختبار ثم أصلحها)، مبالغ فيها (صحيحة نظريًا لكن لا تحدث في سياقك، فاكتب السبب)، خاطئة (المساعد أساء الفهم، فتجاهلها). القاعدة: لا إصلاح دون اختبار يفشل قبله وينجح بعده.
3مراجع آلي صغير
الأدوات الثابتة حتمية: نفس المدخل يعطي نفس النتيجة دائمًا. هذا مراجع مصغّر بمكتبة ast يكشف نمطين خطرين: except: العارية والقيمة الافتراضية القابلة للتغيير:
import ast
source = """
def add_item(item, basket=[]):
basket.append(item)
return basket
def load(path):
try:
return open(path).read()
except:
return None
"""
for node in ast.walk(ast.parse(source)):
if isinstance(node, ast.ExceptHandler) and node.type is None:
print(f"line {node.lineno}: bare except hides every error")
if isinstance(node, ast.FunctionDef):
for default in node.args.defaults:
if isinstance(default, (ast.List, ast.Dict, ast.Set)):
print(f"line {node.lineno}: mutable default in {node.name}()")مثال محلول
المسألة: المساعد قال «السطر 14 عرضة لحقن SQL». التحقّق: السطر يستخدم cursor.execute("... WHERE id = %s", (user_id,))، أي استعلام بمعاملات. التصنيف: خاطئة، فالمعاملات تمنع الحقن. وفي نفس الرد قال «لا يتحقق أن الفاتورة تخص المستخدم». التحقّق: طلب /invoices/7 من مستخدم آخر أعاد 200. التصنيف: صحيحة وخطيرة، فاكتب الاختبار وأضف AND owner_id = %s.
خرافة مقابل حقيقة
| الخرافة | الحقيقة |
|---|---|
| المراجعة بالذكاء الاصطناعي تغني عن المراجع البشري. | تسرّع المراجع البشري وتلتقط الواضح، لكن فهم الغرض والسياق يبقى عند الإنسان. |
| لو لم يجد المساعد شيئًا فالكود سليم. | قد يفوّت أخطاء المنطق الخاصة بمجالك. الاختبارات هي الدليل. |
اختبر فهمك
ما أهم شيء تطلبه مع كل ملاحظة لتقليل الهلوسة؟
سيناريو الفشل يمكن تجربته، فيتضح فورًا إن كانت الملاحظة حقيقية.
ملاحظة صحيحة نظريًا لكنها مستحيلة في سياقك. ماذا تفعل؟
توثيق السبب يحمي من إعادة النقاش لاحقًا.
لماذا نجمع المساعد مع أدوات ثابتة؟
الأداة الثابتة تعطي نفس النتيجة دائمًا لنفس الكود.
بطاقات مراجعة سريعة
تحقق من فهمك
لماذا لا ترسل المستودع كله للمراجعة؟
السياق الضخم يشتّت النموذج ويضعف تركيزه على التغيير، وقد يكشف أسرارًا.
متى تقبل ملاحظة؟
حين تعيد إنتاجها باختبار يفشل.
ما الذي لا تطلب من المساعد مراجعته؟
ما تقرره الأدوات تلقائيًا مثل التنسيق، فهو ضجيج في الرد.