فحص الكود المصدري قبل الاستلام: 20 نقطة يتحقق منها غير المبرمج
المطور يقول إن التطبيق جاهز وينتظر الدفعة الأخيرة، وأنت لا تقرأ الكود. هذه قائمة لصاحب المشروع ومدير المنتج: عشرون دليلًا تطلبه وتقرأ نتيجته، ثم قرار واضح بين التوقيع والشروط والمراجعة المتخصصة.
لا تحتاج إلى قراءة الكود لتعرف إن كان سليمًا بما يكفي للتوقيع. الكود يترك أدلة يراها غير المبرمج: تاريخ المستودع، ونتيجة تشغيل الاختبارات أمامك، وتقارير أدوات تكشف المكتبات القديمة والثغرات والأسرار المكتوبة في الكود، وتجارب بسيطة على الصلاحيات. فحص الكود المصدري قبل الاستلام بالنقاط العشرين في هذه المقالة يأخذ جلسة أو جلستين مع المطور، ويفرز النتيجة إلى ثلاث حالات: توقيع، أو توقيع بشروط مكتوبة، أو إيقاف التوقيع وطلب مراجعة متخصصة. وأي فشل في البناء من الصفر، أو سر مكشوف، أو صلاحية مكسورة، يعني ألا توقع قبل المعالجة.
يقول المطور إن التطبيق جاهز، ويرسل رابط المستودع ومحضر الاستلام، وينتظر الدفعة الأخيرة. التطبيق يعمل على جوالك، لكنك لا تعرف ما خلف الشاشات: هل يستطيع مطور آخر أن يكمل عليه؟ هل فيه مفتاح بوابة دفع مكتوب في الكود؟ هل ستتوقف مكتبة أساسية فيه بعد أشهر؟ هذه المقالة لا تعلمك البرمجة. تعطيك عشرين نقطة تطلب فيها دليلًا ملموسًا، وتقرأ نتيجته بنفسك، وتعرف متى تكفي ومتى تحتاج إلى مهندس مستقل.
أين يقع هذا الفحص من الاستلام؟
في الاستلام سؤالان مختلفان. الأول: هل استلمت كل شيء؟ المستودع، والحسابات، والنطاق، والمفاتيح، والنسخ الاحتياطية. هذا ما تغطيه قائمة استلام التطبيق من شركة البرمجة بأربعين بندًا. والثاني: هل ما استلمته سليم؟ هل يُبنى، ويُختبر، ويُطوّر، ولا يحمل مخاطر أمنية واضحة؟ هذا موضوع هذه المقالة.
الفحص الذاتي لا يغني عن مراجعة الكود المصدري وتدقيق المعمارية على يد مهندس، لكنه يحدد متى تحتاج إليها. في كثير من المشاريع الصغيرة يكفي الفحص الذاتي إذا كانت نتائجه نظيفة. وفي المشاريع الكبيرة أو الحساسة، يجعل المراجعة المتخصصة أسرع لأنك تدخلها بأسئلة محددة.
- إعلان الجاهزيةالمطور يرسل المستودع ومسودة المحضرالمطور
- الفحص الذاتيالنقاط العشرون في جلسة أو جلستينالمنشأة مع المطور
- الفرزتوقيع، أو شروط مكتوبة، أو إيقافصاحب القرار
- مراجعة متخصصةفقط حين يستدعيها الفرزجهة مستقلة
- المحضر والدفعةبعد معالجة الحرجالطرفان
ما يكشفه المستودع دون فتح ملف واحد: النقاط 1–5
افتح صفحة المستودع (GitHub أو GitLab أو غيرهما) مع المطور على شاشة واحدة. لا تقرأ الكود؛ اقرأ ما حوله.
- 1. تاريخ التعديلات منتظم على مدة المشروع
- اطلب عرض سجل التعديلات (Commits). المطلوب تعديلات متتابعة على أسابيع العمل برسائل تصف ما تغير. إشارة خطر: رفعة واحدة ضخمة بتاريخ التسليم، أو رسائل مثل «تعديل» و«إصلاح» مكررة مئات المرات. الأولى تعني أن التاريخ الحقيقي ليس عندك، والثانية أن من سيكمل لن يفهم لماذا تغير شيء.
- 2. من كتب أغلب الكود؟
- صفحة المساهمين تبين توزيع العمل. إشارة خطر: شخص واحد كتب كل شيء وغادر الشركة المطورة، أو أسماء لا يعرفها أحد في الفريق. المعرفة التي في رأسه لن تصلك مع الكود.
- 3. أي فرع هو الإنتاج، وماذا بقي في الفروع الأخرى؟
- اسأل: أي فرع يُبنى منه الإصدار المنشور؟ ثم انظر إلى الفروع وطلبات الدمج المفتوحة. إشارة خطر: عمل مهم في فروع لم تُدمج، أو إجابة غير حاسمة عن فرع الإنتاج. هذا عمل دفعت مقابله ولم يصل إلى التطبيق.
- 4. ملف README محدّث ويشرح التشغيل
- افتحه وانظر إلى تاريخ آخر تعديل عليه وإلى محتواه: المتطلبات، وخطوات التشغيل، والبيئات. إشارة خطر: الملف الافتراضي الذي تولده أداة إنشاء المشروع دون تعديل، أو آخر تحديث له قبل أشهر من التسليم.
- 5. شجرة الملفات نظيفة
- تصفح المجلدات الرئيسية. إشارة خطر: مجلدات أو ملفات بأسماء مثل old وbackup وcopy وnew2 وfinal، أو ملفات ضخمة مرفوعة داخل المستودع، أو مجلدات لمشاريع أخرى. كلها علامات على عمل بلا انضباط، وغالبًا تتكرر خلف الشاشات.
ما تطلب تشغيله أمامك: النقاط 6–10
هنا لا تكتفي بالإجابة الشفوية. اطلب أن يحدث الشيء أمامك، ويفضل أن ينفذه شخص غير المطور الذي كتب الكود: موظف تقني لديك، أو مطور مستقل لساعات.
- 6. البناء من الصفر بالتعليمات المكتوبة وحدها
- على جهاز لم يُبن عليه المشروع من قبل. عُدّ كل خطوة يدوية لم تُكتب، وكل سؤال اضطر المنفذ إلى طرحه. إشارة حرجة: فشل البناء، أو نجاحه فقط بتدخل المطور. هذه النقطة تحديدًا تُوقف التوقيع.
- 7. الاختبارات موجودة وتعمل
- اطلب تشغيل الاختبارات الآلية أمامك (في مشاريع Flutter مثلًا عبر أوامر الاختبار التي تشرحها وثائق اختبار Flutter). اسأل عن عددها، وكم نجح وكم فشل. إشارة خطر: لا اختبارات إطلاقًا، أو اختبارات فاشلة «معروفة ولا تهم».
- 8. ماذا تغطي الاختبارات؟
- العدد وحده لا يكفي. اسأل: هل يوجد اختبار للدخول؟ للدفع؟ لحساب السعر أو الرصيد؟ لإلغاء الطلب؟ إشارة خطر: اختبارات لشاشات بسيطة فقط، بينما المسارات التي تمس المال والبيانات بلا اختبار.
- 9. خط البناء الآلي وسجل تشغيله
- إن كان للمشروع خط بناء (CI)، فافتح سجل تشغيلاته. إشارة خطر: خط معطل منذ مدة، أو فشل متكرر تجاهله الفريق، أو عدم وجود خط أصلًا في مشروع متوسط أو كبير.
- 10. تحذيرات أداة التحليل
- كل لغة لها أداة تحليل تعد التحذيرات والأخطاء المحتملة دون تشغيل التطبيق. اطلب تشغيلها وتصوير الناتج. إشارة خطر: مئات التحذيرات، أو قواعد التحليل معطلة عمدًا في ملف الإعدادات.
ما تكشفه تقارير المكتبات: النقاط 11–14
التطبيق الحديث مبني على عشرات المكتبات الخارجية. حالتها يوم الاستلام تحدد كم ستدفع في أول تحديث كبير. هذه تقارير تولدها أدوات جاهزة في دقائق، واطلبها ملفات مرفقة بالمحضر.
- 11. المكتبات القديمة
- في Flutter وDart يعرض الأمر الموضح في وثائق dart pub outdated كل مكتبة وإصدارها الحالي وأحدث إصدار متاح، ولكل منظومة أمر مشابه. إشارة خطر: مكتبات أساسية متأخرة بإصدارات رئيسية عدة، لأن ترقيتها لاحقًا عمل مستقل قد يمس أجزاء كثيرة.
- 12. الثغرات المعروفة في المكتبات
- منصات المستودعات تنبه إلى المكتبات ذات الثغرات المعروفة، مثل تنبيهات Dependabot في GitHub. اطلب لقطة من صفحة التنبيهات أو تقرير أداة تدقيق. إشارة حرجة: تنبيه بخطورة عالية أو حرجة في مكتبة تتعامل مع الدخول أو الدفع أو رفع الملفات.
- 13. مكتبات متوقفة أو شخصية
- اسأل عن كل مكتبة لم تُحدَّث منذ مدة طويلة، أو مكتبة مأخوذة من مستودع شخصي للمطور لا من المستودع الرسمي. إشارة خطر: جزء أساسي من التطبيق معتمد على مكتبة لا يصونها أحد، أو على نسخة معدلة لا توجد إلا عند المطور.
- 14. تراخيص المكتبات مفتوحة المصدر
- اطلب قائمة بالمكتبات وتراخيصها. لا تحتاج إلى فهم كل ترخيص؛ ابحث عن التراخيص التي تفرض شروطًا على نشر الكود أو تعديله، واسأل عنها. إشارة خطر: المطور لا يعرف تراخيص ما استخدمه. هذا سؤال قانوني يُعرض على مستشارك إن ظهر، والمقالة هنا توعية لا استشارة قانونية.
ما تعرفه عن البنية بأسئلة بسيطة: النقاط 15–17
هذه النقاط تقيس سهولة التعديل لاحقًا، وتُفحص بأسئلة «كيف أغير كذا؟» ثم مراقبة الإجابة.
- 15. الملفات العملاقة والتكرار
- اطلب ترتيب الملفات حسب الحجم، أو تقرير أداة جودة يقيس التكرار. إشارة خطر: ملف واحد بآلاف الأسطر يحمل منطق شاشات كثيرة، أو منطق السعر نفسه مكتوب في أكثر من موضع. هذا ما يجعل كل تعديل صغير يكسر شيئًا آخر.
- 16. الإعدادات مفصولة عن الكود
- اسأل: لو غيرنا عنوان الخادم أو مفتاح بوابة الدفع أو بريد الإشعارات، ماذا نعدل؟ الإجابة الجيدة: متغيرات بيئة أو ملف إعدادات لكل بيئة. إشارة خطر: «نعدل في الكود ونعيد البناء والنشر».
- 17. النصوص قابلة للتعديل والترجمة
- اسأل: كيف أغير نص زر أو رسالة خطأ بالعربية، أو أضيف الإنجليزية لاحقًا؟ الإجابة الجيدة: ملفات ترجمة موحدة. إشارة خطر: نصوص مكتوبة مباشرة داخل الشاشات، فيصبح تعديل صياغة مهمة برمجية.
ما تجربه بنفسك في الأمن: النقاط 18–20
ثلاث نقاط أمنية لا تحتاج إلى خبرة، لكن نتيجتها حاسمة. أي فشل فيها يوقف التوقيع حتى يُعالج.
- 18. لا أسرار داخل الكود ولا في تاريخه
- أدوات فحص الأسرار تبحث في المستودع وتاريخه كله عن كلمات مرور ومفاتيح. اطلب تقرير الفحص على التاريخ كاملًا. إشارة حرجة: أي مفتاح حقيقي لبوابة دفع أو قاعدة بيانات أو خدمة رسائل. المفتاح الذي ظهر ولو في تعديل قديم يُعامل كمكشوف ويُغيّر.
- 19. الصلاحيات تصمد أمام تجربة بسيطة
- ادخل بحساب موظف محدود الصلاحية وحاول فتح شاشة المدير. وفي لوحة الويب، افتح طلبًا وغيّر رقمه في شريط العنوان. إشارة حرجة: ظهور بيانات لا تخص هذا الحساب. هذه من أكثر الثغرات شيوعًا في واجهات الربط كما تشرح صفحة أمن التطبيقات.
- 20. كلمات المرور والبيانات الشخصية غير مقروءة
- اطلب أن يُعرض أمامك جدول المستخدمين في قاعدة بيانات الاختبار، وعينة من سجلات الخادم. إشارة حرجة: كلمة مرور مقروءة، أو رقم هوية أو بيانات بطاقة في السجلات. ويمكنك مقارنة ممارسات الحماية بمعايير عامة مثل معيار OWASP MASVS لتطبيقات الجوال حين تطلب مراجعة أعمق.
كيف تقرأ النتيجة وتقرر: التوقيع أم الشروط أم المراجعة المتخصصة؟
لا تجمع النقاط كدرجة واحدة. بعضها حرج بذاته، وبعضها لا يعني شيئًا منفردًا لكنه يعني الكثير حين يتكرر.
| ما وجدته | القرار | ما تكتبه في المحضر |
|---|---|---|
| كل النقاط سليمة أو ملاحظتان بسيطتان | توقيع | الملاحظات البسيطة مع موعد معالجتها ضمن فترة الضمان |
| فشل في النقطة 6 أو 12 أو 18 أو 19 أو 20 | إيقاف التوقيع | البند الحرج، والمعالجة المطلوبة، وإعادة الفحص بعدها |
| إشارات خطر في أربع نقاط أو أكثر من مجموعات مختلفة | مراجعة متخصصة قبل القرار | تعليق الدفعة الأخيرة حتى يصدر تقرير المراجعة |
| إشارات متركزة في مجموعة واحدة (مثل المكتبات) | توقيع بشروط | خطة معالجة محددة، وربط جزء من الدفعة بإنجازها |
مثال افتراضي للتوضيح منصة حجز قاعات تدريب بتطبيق للعملاء ولوحة تحكم. في جلسة الفحص نجح البناء من الصفر بعد سؤالين للمطور أُضيفت إجاباتهما إلى README، ووُجدت 11 اختبارًا كلها لشاشات العرض ولا شيء للدفع، وأظهر تقرير المكتبات ثلاث مكتبات متأخرة بإصدارين رئيسيين، ولم تظهر أسرار في التاريخ، وصمدت تجربة تغيير رقم الحجز. النتيجة: لا نقطة حرجة، وإشارات متركزة في مجموعتي الاختبارات والمكتبات. القرار كان توقيعًا بشروط: اختبارات لمسار الدفع والإلغاء، وترقية المكتبات الثلاث، وربط جزء من الدفعة الأخيرة بالتسليم الثاني. لو ظهر مفتاح بوابة الدفع في التاريخ، لتغير القرار إلى إيقاف التوقيع حتى يُدوّر المفتاح.
متى لا يكفي الفحص الذاتي؟
الفحص الذاتي يكشف الأعراض الظاهرة. هناك أسئلة لا يجيب عنها إلا مهندس يقرأ الكود فعلًا: هل المعمارية تتحمل النمو المتوقع؟ هل تصميم قاعدة البيانات يحفظ سلامة السجلات؟ هل منطق الأعمال صحيح في الحالات الاستثنائية؟ اطلب مراجعة متخصصة حتى لو كانت نتائجك نظيفة في هذه الحالات:
- التطبيق يتعامل مع مدفوعات أو بيانات صحية أو مالية أو بيانات أطفال.
- ستبني عليه مرحلة ثانية كبيرة، أو ستسلمه لفريق جديد.
- هناك استثمار أو استحواذ يعتمد على حالة المنتج.
- الجهة المالكة أو عميلها يشترط تقرير جودة أو أمن.
- المطور رفض تنفيذ بعض نقاط الفحص أو أعطى إجابات عامة.
في هذه الحالة يدخل المشروع في مراجعة الكود وتدقيق المعمارية: رأي مستقل بملاحظات مرتبة حسب الخطورة، لكل منها موقعها في الكود ودليلها، وملخص تنفيذي لصاحب القرار، وتقدير تقريبي لمعالجة كل مجموعة، وتوصية بالمسار. والمراجعة تبدأ باتفاقية سرية وصلاحيات قراءة فقط. وإن كانت الشكوك في السلوك لا في الكود، فالأنسب اختبار مستقل لتطبيق طوّره فريق آخر بحالات مكتوبة. وإن أردت معرفة إن كان الكود يصلح للبناء عليه على المدى الطويل، فالمؤشرات التفصيلية في تقييم قابلية الكود للتطوير.
أخطاء شائعة في فحص الكود قبل الاستلام
- الاكتفاء بتجربة التطبيق على الجوال: التطبيق الذي يعمل اليوم قد يكون مستحيل التعديل غدًا. الشاشات لا تقول شيئًا عن الكود.
- قبول «نعم يوجد» بدل «أرني»: كل نقطة في القائمة تُثبت بشاشة أو تقرير أو تشغيل أمامك.
- ترك المطور نفسه ينفذ البناء من الصفر: جهازه يحمل إعدادات لا يتذكرها، فينجح البناء عنده ويفشل عند غيره.
- الفحص بعد الدفعة الأخيرة: بعدها تتحول كل ملاحظة إلى تفاوض بلا أداة ضغط.
- معاملة كل إشارة كفشل: تحذيرات قليلة أو مكتبة متأخرة إصدارًا واحدًا أمر طبيعي. الحكم على النمط لا على نقطة منفردة غير حرجة.
- تجاهل النقاط الأمنية لأنها تبدو تقنية: هي أسهل النقاط تجربة، وأعلاها أثرًا.
ما تجهزه قبل التواصل وما تطلبه من شركة التطوير
ما تجهزه قبل الجلسة
- صلاحية مالك أو قراءة على المستودع باسم منشأتك.
- شخص غير المطور لتنفيذ البناء من الصفر، ولو مطورًا مستقلًا لساعات.
- حسابان تجريبيان بصلاحيتين مختلفتين، وبيئة اختبار ببيانات غير حقيقية.
- نسخة من هذه النقاط العشرين مرسلة إلى المطور قبل الجلسة بوقت كافٍ.
- العقد وملحقه الفني، لتعرف ما التزم به المطور فعلًا في الاختبارات والتوثيق.
ما تطلبه من شركة التطوير مرفقًا بالمحضر
- ناتج تشغيل الاختبارات وأداة التحليل.
- تقرير المكتبات القديمة وتنبيهات الثغرات.
- تقرير فحص الأسرار على كامل التاريخ.
- قائمة المكتبات وتراخيصها.
- تحديد فرع الإنتاج ووسم الإصدار المنشور.
- التزام مكتوب بمعالجة ما يظهر من ملاحظات ضمن فترة الضمان.
وإن كان العقد لم يُوقع بعد، فاجعل هذه المخرجات شرطًا للاستلام من البداية. صياغة مقترحة للنقاش مع مستشارك:
لا يُعد التسليم مكتملًا إلا بعد بناء التطبيق من المستودع المسلَّم على جهاز مستقل باتباع التوثيق وحده، وتسليم نواتج الاختبارات الآلية وتقارير المكتبات والثغرات وفحص الأسرار، ومعالجة أي ملاحظة مصنفة حرجة قبل توقيع محضر الاستلام.
الخلاصة: اطلب الدليل قبل التوقيع، والمراجعة حين يتكرر الخطر
غير المبرمج لا يستطيع أن يحكم على جودة الكود سطرًا سطرًا، لكنه يستطيع أن يطلب عشرين دليلًا ويقرأ نتيجتها. البناء من الصفر، والأسرار، والصلاحيات، والثغرات، والبيانات المقروءة نقاط توقف التوقيع وحدها. وتكرار الإشارات في مجموعات مختلفة يعني أنك تحتاج إلى رأي مهندس مستقل قبل القرار. إن ظهرت هذه الإشارات، أو كان التطبيق حساسًا، اطلب مراجعة المشروع قبل الاستلام وادخلها بنتائج فحصك، لتكون المراجعة أقصر وقرارك مبنيًا على أدلة.
أسئلة شائعة
تستطيع فحص الأدلة التي يتركها الكود لا الكود نفسه: تاريخ المستودع، ونتيجة البناء من الصفر، وتشغيل الاختبارات، وتقارير المكتبات والثغرات والأسرار، وتجارب الصلاحيات. هذا يكفي لتعرف متى توقع ومتى تحتاج إلى مهندس مستقل.
أي مطور لم يعمل في المشروع، ولو مستقلًا لساعات محدودة، على جهاز لم يُبن عليه المشروع. المهم ألا يكون المطور الأصلي، لأن جهازه يحمل إعدادات قد لا تكون مكتوبة في التوثيق فينجح البناء عنده ويفشل عند غيره.
ليس بالضرورة. مكتبة متأخرة إصدارًا واحدًا أمر طبيعي. الخطر في مكتبات أساسية متأخرة بإصدارات رئيسية عدة، أو فيها ثغرات معروفة، أو متوقفة لا يصونها أحد. اطلب التقرير واسأل عن هذه الحالات تحديدًا.
الرفض نفسه نتيجة. إن كان العقد يلزمه بالتوثيق والاختبارات فاطلب الالتزام به قبل التوقيع، وإن لم يكن يلزمه فعلق الدفعة الأخيرة واطلب مراجعة مستقلة للكود. الكود حقك إن كان المشروع ملكك.
يغني عنها في المشاريع الصغيرة إذا جاءت نتائجه نظيفة. أما التطبيقات التي تتعامل مع مدفوعات أو بيانات حساسة، أو التي ستُبنى عليها مرحلة كبيرة، فتحتاج إلى مهندس يقرأ المعمارية وقاعدة البيانات ومنطق الأعمال، وهي أمور لا تظهر في الفحص الذاتي.
خدمات وصفحات مرتبطة
اقرأ أيضًا
نتائج فحصك تثير الشك؟ ابدأ بمراجعة مستقلة
أرسل نتائج فحصك ووصف المشروع، ونراجع الكود والمعمارية والأمن بتقرير مرتب حسب الخطورة وملخص لصاحب القرار قبل أن توقع.