ما هي أدوات وطرق مراجعة الأكواد التي يجب استخدامها لفحص كود مستلم من وكالة برمجية؟

عند تشغيل الأدوات الساكنة، لا تركزوا فقط على معايير تنسيق الكود، بل دققوا أيضاً في قواعد الـ SAST الأمنية؛ فثغرات مثل حقن SQL، والمراجع المباشرة غير الآمنة للكائنات (IDOR)، وضعف التحقق من المدخلات تكتشفها القواعد الآلية بسهولة. تأكدوا أيضاً من نسبة الـ test coverage، فإذا لم تكتب الوكالة اختبارات وحدة (unit tests) ستكون إعادة هيكلة الكود كابوساً.

تسلمنا العام الماضي خلفية برمجية لتطبيق جوال بنفس الطريقة مقابل 40.000 دولار. الأدوات الآلية أعطت الضوء الأخضر لأن بنية الكود كانت ممتازة وظاهرياً نظيفة، لكن بعد الإطلاق بأسبوعين توقفت قاعدة البيانات تماماً؛ اتضح أن الوكالة لم تضع أي مفاتيح أجنبية (foreign keys) أو فهارس (indexes) في الجداول. مستحيل لأي أداة أن تكتشف هذا بمفردها.

دفعنا أثناء مرحلة التسليم 2.500 دولار لمهندس معماري مستقل خبير لعمل فحص عميق لمدة 15 ساعة؛ استخرج لنا 4 أخطاء معمارية رئيسية كانت ستعيق التوسع مستقبلاً و8 ثغرات صلاحيات مكشوفة في الكود المسلم. كانت خطوة تستحق كل ما أنفقناه عليها.

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

أول شيء يمكنكم فعله غدًا مباشرة: افحصوا سجل الإصدارات في مستودع الكود (git log). هل دفعت الوكالة الشغل في آخر 3 أيام بدافع الهلع، أم تقدمت على مدى 4 أشهر بـ commit منتظمة ورسائل توضيحية؟ انضباط الإصدارات هو أكبر مؤشر على البنية الداخلية للكود.

قائمة تحقق عند تسليمات الوكالة: 1) هل نُسيت كلمات مرور API للخدمات الخارجية داخل الكود؟ 2) هل تراخيص المكتبات مفتوحة المصدر متوافقة مع استخدامكم التجاري؟ 3) هل خطوات النشر (deployment) والتنصيب المحلي تعمل كاملة في وثيقة واحدة؟

هل كُتبت اختبارات، لا بد أن تنظروا إلى ذلك برأيي ثم طيب الوكالات عادة تقول لم نلحق ونكتب اختبارات وحدة، وبعدها تغيّر سطر كود واحد فتنهار البنية كلها.

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

أخذت ملاحظة، شكرًا لك.

أنا أيضًا متحمس لمعرفة ذلك.

أتابع الموضوع.

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

دعني أتركها كملاحظة، قد تكون مفيدة.

الطريق الذي يبدو رخيصاً غالباً ما يكلف غالياً لاحقاً ثم عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط.

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

بعد تجربة ذلك، تغيرت نظرتي للأمور. الكود بدون وثائق تثبيت لا يُعتبر ملكك حتى لو كان بين يديك.

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

أوافق.

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

لو كنت مكانك، لسلك هذا المسار.

مررت بهذا الطريق، دعني أشرح. تقرير التقدم الأسبوعي المكتوب أكثر فائدة من السؤال المستمر عن المواعيد.

عندنا نفس المشكلة. كل من يستعجل في أدوات مراجعة الأكواد يتعثر في نفس النقطة.

ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة. لو كنت مكانك، لسلك هذا المسار.