مراجعة الكود لما هو أهم من التنسيق

راجع أثر التغيير على العمل

تستطيع أدوات التنسيق ضبط المسافات، لكنها لا تقرر هل يجوز للمدير اعتماد مصروفه الشخصي، أو هل يؤدي مسار الخطأ إلى فقد تحديث عميل. مراجعة الكود فحص مستقل للسلوك الجديد والافتراضات التي يعتمد عليها، وليست مسابقة في أسلوب الكتابة.

ابدأ بالغرض: ما المشكلة المحددة، وما الذي سيحدث بصورة مختلفة؟ التغيير المتماسك مع مثال واضح أسهل فهمًا من جمع ميزة وتحديث اعتماديات وتنظيف واسع. افصل العمل عندما يساعد ذلك على المراجعة، مع الاحتفاظ بتغيير مكتمل يمكن اختباره.

تتبع رحلة الطلب كاملة

لنفترض تطبيق مصروفات يضيف اعتماد مجموعة طلبات. ترشح الواجهة السجلات وترسل معرفاتها وتعرض النتيجة. المراجعة المفيدة لا تتوقف عند الحلقة البرمجية والزر؛ بل تتبع الطلب إلى الخادم، وتتحقق من سلطة المدير على كل سجل، وما يحدث إذا تغير أحد الطلبات أثناء المعالجة.

اقرأ السياق المحيط بالتعديل. فقد تخزن دالة مساعدة صلاحيات قديمة، أو تتجاهل خطأ دون تنبيه. تتبع مصدر البيانات وحدود التحقق وموضع تثبيت النتيجة. وتأكد أن الاستدعاءات السابقة لا تعتمد على سلوك تغير دون قصد.

تشمل إرشادات Google للمراجعة التصميم والوظيفة والتعقيد والاختبارات. ويركز مشروع OWASP لمراجعة الكود على اكتشاف مواطن الضعف الأمنية من المصدر. الاستفادة من المرجعين لا تغني عن تشغيل السلوك المتأثر وفحصه.

اسأل عند حدود الثقة

• هل يتحقق الخادم من صلاحية العملية ومن صلاحية الوصول إلى السجلات نفسها؟
• هل تُفحص المدخلات قبل تأثيرها في استعلام أو مسار أو طلب خارجي؟
• هل تُستخدم معاملات آمنة للاستعلام وترميز مناسب للمخرجات؟
• هل تكشف الأخطاء أو السجلات أسرارًا أو بيانات شخصية؟
• هل للاعتماد أو التكامل الجديد غرض ضروري وواضح؟

إخفاء صف غير مؤهل لا يمنع إرسال معرفه يدويًا. يجب أن يرفض الخادم طلبًا يخص مديرًا آخر. حدد كذلك هل تنجح المجموعة كاملة أو تفشل كاملة، أم تظهر نتيجة مستقلة لكل سجل. هذه سياسة أعمال ينبغي أن تعكسها الواجهة بوضوح.

راجع الزمن والتزامن

قد يكون الطلب صالحًا عند القراءة ثم يُسحب قبل التحديث. افحص هل يتحقق أمر قاعدة البيانات من الحالة المتوقعة، وهل يصف سجل التدقيق النتيجة المحفوظة فعلًا.

تتبع انتهاء المهلة وإعادة الإرسال. إذا تم الاعتماد وضاعت الاستجابة، فماذا يحدث عند المحاولة التالية؟ يجب أن تحسمه قاعدة حالة أو آلية منع تكرار، لا افتراض أن المستخدم لن يضغط مرتين. وافحص تحرير الأقفال وإنهاء المعاملات والعمل المعلق بعد الفشل الجزئي.

اسأل عما تثبته الاختبارات

الاختبار الذي يكرر شروط التنفيذ قد ينجح دون كشف عيب مهم. اسأل: ما الخطأ الواقعي الذي سيجعله يفشل؟ في مثال المصروفات، يلزم دليل على الاعتماد المسموح ورفض سجل خارج الصلاحية ومعالجة الحالة القديمة وسلوك الفشل المتفق عليه.

قد يفحص اختبار صغير منطق الأهلية، واختبار تكامل تحديث القاعدة المشروط، واختبار متصفح اختيار السجلات وإظهار النتائج. لا تطلب اختبارًا جديدًا لكل تعديل نصي بسيط، لكن لا تقبل صورة شاشة دليلًا على فرض الصلاحيات في الخادم.

اجعل التعليق قابلًا للتنفيذ

اشرح السيناريو والنتيجة بدل كتابة حكم عام. ميّز العيب المانع للإطلاق عن الاقتراح والتفضيل الشخصي. وإذا ظهرت سياسة ناقصة، أعدها لصاحب القرار بدل اختراعها داخل نقاش تقني.

راجع وضوح المسؤوليات والأسماء ومكان القاعدة المرجعية. إطار عام ضخم قد لا يلزم لميزة واحدة، ونسخ منطق العمل في أماكن متعددة يصعب الصيانة أيضًا.

يُقبل التغيير عندما يستطيع المراجع شرح الصلاحية والتزامن والفشل والأدلة، وتنجح الفحوص المناسبة للنطاق النهائي. تقلل المراجعة الخطر دون ضمان غياب العيوب. اجعل توقعاتها جزءًا من تسليم المشروع البرمجي مع المراقبة وخطة التعافي.