كلمة «مُعتمد» بجوار تغيير برمجي قد تعني أن مختصًا راجع سلوكه، أو أنه نظر إلى جزء محدود، أو أن موافقته سبقت تعديلات جديدة. إذا كنت تتعامل مع فريق خارجي، فاسأل عما تثبته الموافقة بدل الاكتفاء بعدّها ضمن تقرير الإنجاز.
لا يحتاج صاحب المشروع إلى قراءة كل سطر كي يشتري مراجعة جيدة. يحتاج إلى مسؤول تقني قادر على شرح مقصد التغيير ونطاق ما فُحص والملاحظات المهمة وكيف حُسمت. هذه معلومات مختلفة عن عدد المهام المغلقة أو الساعات المسجلة أو موعد رفع إصدار.
خذ تغييرًا تستطيع تتبعه
نفترض بوابة افتراضية لاستقبال ملفات مطبعة. يقترح الفريق تغيير حد حجم الملف ورسالة الرفض. المثال ليس مراجعة نفذناها على برنامج عميل. قد تبدو المهمة تعديل نص، لكنها تتطلب فهم العلاقة بين ما تسمح به الشاشة وما يقبله الخادم، وما يراه المستخدم عند تجاوز الحد.
اطلب وصفًا قصيرًا للسبب والسلوك السابق والمقترح والملفات المتأثرة. افصل إعادة تنسيق واسعة عن تعديل الوظيفة قدر الإمكان حتى يسهل فهم الفرق. ولا تجعل اسم المهمة «تحسين الرفع» يسمح بإدخال تغييرات أخرى لا يعرف المراجع سببها أو علاقتها بالحاجة المعتمدة.
ورقة عينة مراجعة من ستة أسئلة
- أي فرق راجعناه؟ سجل مرجع نسخة التغيير، لا رابطًا يتحرك محتواه دون معرفة ما أضيف بعد الموافقة.
- من راجع ماذا؟ اذكر نطاق المراجع واختصاصه وأي جزء أُحيل إلى مختص آخر، دون تحويل الأسماء إلى ادعاء مراجعة شاملة.
- ما السلوك المؤثر؟ صف ما يجب أن يحدث للمستخدم وما قد يتغير في أجزاء مرتبطة، مثل رسالة الخطأ وحفظ سياق الطلب.
- ما الملاحظة الواجبة؟ ميز خللًا يحتاج إصلاحًا من اقتراح تحسين اختياري، وسجل سبب قبول الحل أو تأجيله.
- ما دليل الاختبار؟ اذكر ما نُفذ فعلًا ونسخته وحدوده، وما لم يُنفذ أو يحتاج قرارًا إضافيًا.
- هل تغير شيء لاحقًا؟ حدد ما أضيف بعد المراجعة ومن تحقق منه قبل الاعتماد النهائي، مع تحديث التوثيق عند الحاجة.
هذه الورقة مقترحة لشراء قدرة على تفسير الجودة، وليست درجة جاهزة لتقييم الأشخاص. كثرة التعليقات قد تعني تدقيقًا مفيدًا أو غموضًا أو نقاشًا شكليًا. ولا يدل انخفاض عددها وحده على جودة أعلى؛ انظر إلى أثر الملاحظة ودليل حسمها في عينة معروفة.
المراجعة تتجاوز تنسيق الكود
تعرض ممارسات Google النظر في التصميم والسلوك والتعقيد وفائدة الاختبارات والتوثيق، مع توضيح حدود الجزء المراجع. وفي مثال المطبعة، السؤال ليس فقط هل الاسم واضح، بل هل يظل السلوك مفهومًا عندما يتجاوز الملف الحد أو يختلف رد الخادم عن توقع الواجهة.
ويؤكد معيار المراجعة لديهم تحسين صحة الكود مع تقدم العمل، دون طلب كمال غير واقعي. لا يعني ذلك تمرير عيب معروف؛ يفيد في فصل تحسين اختياري عن مشكلة تؤثر في النتيجة. اطلب تفسيرًا تقنيًا مناسبًا بدل تعطيل التغيير على تفضيلات شخصية غير متفق عليها.
اسأل هل الموافقة تخص النسخة الحالية
تتيح قواعد GitHub إعدادات لمراجعة تغييرات لاحقة أو إسقاط موافقات قديمة عند تغير الفرق. هذه إمكانات تحتاج ضبطًا وتحققًا بحسب الخطة والقواعد والاستثناءات؛ وجود الأداة لا يثبت تطبيقها. اطلب من المسؤول شرح ما يعمل في مستودعك الفعلي دون افتراض حماية من اسم قاعدة.
إذا تغير حد الملف بعد المراجعة، فليظهر أثر ذلك في الدليل. لا تحمل المراجع مسؤولية سطر لم يره، ولا تستخدم موافقة سابقة كأنها تغطي إضافة جديدة تلقائيًا. سجّل قرار المرور أو إعادة المراجعة مع مرجع واضح، ثم افصل هذا عن قرار الدمج والنشر.
اجعل العينة مفيدة على مدى التعاون
اختر تغييرات متنوعة بحسب أثرها، لا أصغر تعديلات شكلية فقط. راقب هل تتكرر مشكلة معروفة وهل تحسن توثيق القرار بعد النقاش، دون تحويل المراقبة إلى مؤشر إنتاجية فردية من عدد الأسطر. إذا لم يكن لديك مختص مناسب، فحدد دوره ضمن التعاون بدل مطالبة مدير غير تقني بإقرار صحة الكود.
يوضح دليل نموذج الفريق مسؤوليات الشراء، ويشرح تسليم DevOps أدلة البناء والنشر. عند طلب فريق برمجة خارجي من نكست ويف، اتفق على عينة مراجعة قابلة للتفسير وحدود اعتمادها، دون الخلط بين مراجعة الكود وقبول المستخدم أو نشره.
مراجع المراجعة
فُتحت إرشادات Google عن عناصر مراجعة الكود ومعيارها ووثائق حماية الفروع في GitHub في 4 نوفمبر 2026. المثال والورقة أصليان بلا مراجعة مستودع فعلي أو شهادة جودة. الإعداد بمساعدة الذكاء الاصطناعي مع مراجعة المعلومات والترجمة.
