استلام الكود المصدري من المطور السابق: ما الذي يثبت أنك استلمت كل شيء
سلّمك المطور ملفًا يقول إنه المشروع كاملًا، والتطبيق يعمل في المتجر. قبل أن توقع أو تدفع الدفعة الأخيرة، هذه قائمة تحقق لصاحب المشروع ومدير التقنية تثبت أن الكود كامل ويُبنى وحده ويطابق ما يعمل الآن.
الملف المضغوط لا يثبت أنك استلمت الكود الكامل. ما يثبته دليلان: أن مطورًا لم يعمل في المشروع يبني التطبيق والخادم من هذا الكود وحده على جهاز نظيف، وأن ما بناه يطابق ما يعمل الآن في المتجر وعلى خادم الإنتاج. لذلك لا يقتصر استلام الكود المصدري من المطور على الكود نفسه، بل يشمل المستودع بتاريخه ووسوم إصداراته، وما يُستثنى من المستودع عمدًا (ملفات الإعدادات والمفاتيح)، وقاعدة البيانات وتعديلاتها، وسكربتات البناء والنشر. كل سؤال تضطر إلى طرحه على المطور السابق أثناء البناء بند ناقص في التسليم.
وصلك من المطور رابط تنزيل لملف اسمه «المشروع النهائي»، وفيه مجلدات بأسماء مألوفة. التطبيق يعمل في المتجر، والمطور يقول إن كل شيء في الملف. قد يكون صادقًا، وقد يكون الملف نسخة من جهازه قبل آخر ثلاثة تحديثات، أو كود التطبيق دون الخادم، أو كل شيء ما عدا الملفات التي تجعله يعمل. هذه المقالة قائمة تحقق لإثبات الاكتمال: ما الذي يجب أن يكون معك، وكيف تختبره، وكيف تطابقه مع الإصدار المنشور.
ملف مضغوط أم مستودع كامل: ما الذي يضيع في الطريق
الفرق بين الاثنين ليس شكليًا. المستودع (Repository) يحمل تاريخ المشروع كله، والملف المضغوط لقطة واحدة منه في لحظة لا تعرف متى كانت. هذا ما يفقده الملف عادة:
| العنصر | في المستودع الكامل | في الملف المضغوط | لماذا يهمك |
|---|---|---|---|
| تاريخ التعديلات (Commits) | ✓ كل تعديل ومن كتبه ومتى | ✗ | يشرح لماذا كُتب الكود هكذا، ويكشف متى توقف العمل فعلًا |
| الفروع (Branches) | ✓ | ✗ فرع واحد غالبًا | ميزات أو إصلاحات لم تُدمج قد تكون هي ما يعمل في الإنتاج |
| وسوم الإصدارات (Tags) | إن كان الفريق يستخدمها | ✗ | الطريقة الوحيدة لمعرفة أي نسخة من الكود هي المنشورة |
| ملفات مستثناة عمدًا | ✗ لا تُرفع للمستودع أصلًا | قد توجد إن ضُغطت من جهاز المطور | ملفات البيئة والمفاتيح وإعدادات الخدمات؛ بدونها لا يعمل شيء |
| المستودعات الأخرى | إن سُلمت كلها | غالبًا جزء منها | الخادم ولوحة التحكم والخدمات المساعدة قد تكون في أماكن منفصلة |
السطر الرابع هو ما يفاجئ أغلب أصحاب المشاريع: حتى المستودع الكامل لا يحتوي، إن بُني بطريقة صحيحة، على كلمات المرور ومفاتيح الخدمات وملفات الإعداد الخاصة بالإنتاج، لأنها تُستثنى منه لأسباب أمنية. لذلك التسليم الصحيح له شقان: المستودع، وملحق الأسرار والإعدادات الذي يُسلم بقناة آمنة منفصلة.
إن أصر المطور على إرسال ملف لا على نقل المستودع إلى حساب منشأتك، فاطلب ملف حزمة Git لا ملفًا مضغوطًا. أداة git bundle تحزم المستودع بكل فروعه ووسومه وتاريخه في ملف واحد ينقل دون اتصال، ويُستعاد منه مستودع كامل. الأفضل مع ذلك أن يكون المستودع داخل حساب مؤسسي تملكه المنشأة من البداية، كما نفعل نحن: الكود ملك العميل ويُسلم في مستودع باسم منشأته، بحسب الأسئلة الشائعة.
قائمة التحقق: ما يجب أن يرافق الكود حتى يكون كاملًا
انسخ هذه القائمة وأرسلها إلى المطور قبل موعد التسليم. كل بند يجب أن يقابله ملف أو وثيقة أو صلاحية، لا وعد شفهي.
الكود نفسه
- مستودع لكل مكون يعمل في الإنتاج: تطبيق الجوال، والخادم (Backend)، ولوحة التحكم، وأي خدمة مساعدة أو دالة سحابية أو سكربت مجدول.
- كل الفروع، مع توضيح أي فرع يمثل الإنتاج وأيها عمل غير مكتمل.
- وسم في المستودع لكل إصدار منشور، أو على الأقل معرّف التعديل الذي بُني منه آخر إصدار في كل متجر وآخر نشر على الخادم.
- ملفات قفل الاعتماديات (مثل pubspec.lock أو package-lock.json أو composer.lock) وإصدارات الأدوات المستخدمة (Flutter وNode وPHP وغيرها).
الإعدادات والأسرار
- نموذج لملف البيئة بكل المتغيرات المطلوبة وأسمائها، دون القيم، داخل المستودع.
- القيم الفعلية للإنتاج والاختبار مسلّمة بقناة آمنة منفصلة، أو الأفضل داخل خزنة أسرار تملكها المنشأة.
- ملفات إعداد الخدمات الخارجية في تطبيق الجوال (مثل ملفات مشروع Firebase لكل منصة) مع توضيح أي مشروع خارجي تشير إليه.
- مفتاح رفع تطبيق Android (Keystore) وكلمات مروره، وتأكيد هل التطبيق مسجل في توقيع تطبيقات Google Play.
- قائمة بكل الأسرار والمفاتيح المستخدمة وأين تُستخدم، لأنها ستدخل في التدوير بعد الاستلام.
البيانات والتشغيل
- ملفات تعديل قاعدة البيانات (Migrations) التي تنشئ المخطط كاملًا من الصفر، وبيانات أولية لازمة للتشغيل (الأدوار، والإعدادات، والقوائم).
- وصول إلى نسخة احتياطية حديثة من قاعدة بيانات الإنتاج، أو إلى الخادم نفسه بحساب تملكه المنشأة.
- إعدادات الخادم: خادم الويب، والمهام المجدولة، ومعالجات الطوابير، وأي حاويات أو ملفات بنية تحتية.
- سكربتات البناء والنشر، وإعدادات خط البناء الآلي إن وجد.
- ملف تعليمات (README) يشرح خطوات التشغيل المحلي والبناء والنشر بالترتيب.
هذه القائمة تخص الكود وما يلزم لتشغيله. أما الاستلام الشامل للمشروع، بما فيه حسابات المتاجر والنطاق والاستضافة ولوحات الإدارة، فتفصله مقالة قائمة استلام تطبيق من شركة البرمجة.
اختبار «ابنِ من الصفر»: البروتوكول الذي يثبت الاكتمال
القائمة السابقة تقول لك ما يجب أن يكون موجودًا. الاختبار يقول لك هل يكفي فعلًا. يُنفذه مطور لم يعمل في المشروع، على جهاز أو بيئة نظيفة، باتباع ما سُلم وحده. قاعدته بسيطة: كل مرة يتوقف فيها ليسأل المطور السابق، يُسجل بند ناقص.
- الاستنساخ والأدواتاستنساخ كل المستودعات وتثبيت إصدارات الأدوات المكتوبة فقطمطور مستقل
- الخادم وقاعدة البياناتإنشاء قاعدة بيانات فارغة، وتشغيل ملفات التعديل والبيانات الأولية، ثم تشغيل الخادم بإعدادات بيئة اختبارمطور مستقل
- تطبيق الجوالبناء نسخة إصدار لـ Android موقعة بمفتاح الرفع، وأرشيف iOS، وربطهما بالخادم التجريبيمطور مستقل
- لوحة التحكم والخدمات المساعدةتشغيلها والدخول بحساب مدير وتنفيذ عملية من كل وحدةمطور مستقل
- المسار الكاملتسجيل مستخدم وتنفيذ العملية الأساسية من التطبيق حتى تظهر في اللوحة، وتشغيل الاختبارات الآلية إن وجدتالمطور والمنشأة
- سجل النواقصكل سؤال طُرح وكل ملف طُلب، وهل سُلّم أم ما زال ناقصًاالمنشأة
لا تسمح بأن يُنفذ الاختبار على جهاز المطور السابق أو بمساعدته المباشرة على الشاشة. جهازه يحتوي على كل ما تبحث عن غيابه: ملفات بيئة محلية، ومفاتيح محفوظة، وإصدارات أدوات قديمة مثبتة، وخطوات يفعلها من الذاكرة. نجاح البناء عنده لا يعني شيئًا عنك. وهذا الاختبار أوسع من مجرد الاكتمال: يكشف أيضًا إن كانت أدوات المشروع قديمة إلى حد يمنع رفع تحديث، وهو ما تتناوله مقالة صيانة تطبيق طوّرته شركة أخرى من زاوية قرار الصيانة.
مطابقة الإصدار المنشور: هل هذا هو الكود الذي يعمل الآن؟
قد ينجح البناء من الصفر، ويبقى السؤال الأخطر: هل الكود الذي بنيته هو نفسه الذي يعمل في المتجر وعلى الخادم، أم نسخة أقدم منه؟ لا توجد أداة واحدة تجيب، لكن ستة أدلة مجتمعة تعطيك إجابة يُعتمد عليها:
| الدليل | كيف تجمعه | ما يعنيه الاختلاف |
|---|---|---|
| رقم الإصدار ورقم البناء | قارن رقم الإصدار في الكود (في Flutter يأتي من ملف pubspec ويتحول إلى versionName وversionCode في Android بحسب وثائق Flutter) بآخر إصدار في Google Play Console وApp Store Connect | رقم أقل في الكود يعني أن إصدارًا أو أكثر بُني من كود لم يُسلم |
| معرّف التطبيق | قارن معرّف الحزمة في Android ومعرّف التطبيق في iOS داخل الكود بما في المتجرين | اختلافه يعني أن ما بُني لا يمكن رفعه تحديثًا للتطبيق المنشور |
| مقارنة الشاشات | ثبّت النسخة المنشورة والنسخة المبنية على جهازين، وادخل بحساب اختبار واحد، وامشِ الشاشات والمسارات جنبًا إلى جنب | شاشة أو زر أو نص في المنشور لا يوجد في المبني: كود ناقص أو فرع لم يُسلم |
| كود الخادم المنشور | قارن الملفات على خادم الإنتاج بوسم الإصدار في المستودع، مع استثناء المكتبات المثبتة وملفات الرفع والإعدادات | ملفات عُدلت على الخادم مباشرة ولم تُرفع للمستودع، وهي حالة أكثر شيوعًا مما يُتوقع |
| مخطط قاعدة البيانات | قارن مخطط قاعدة الإنتاج بالمخطط الذي أنشأته ملفات التعديل في اختبار البناء | جداول أو أعمدة أو فهارس أُنشئت يدويًا؛ أي بيئة جديدة ستفتقدها |
| واجهات الربط المستدعاة | اجمع المسارات التي يستدعيها التطبيق المنشور وتحقق من وجودها في كود الخادم المستلم | التطبيق يعتمد على خادم أو خدمة لم تُسلم، أو على نسخة أحدث من الخادم |
وفي Android نقطة تستحق الانتباه قبل أي شيء: التحديث لا يُقبل إلا إذا وُقّع بمفتاح الرفع المسجل. إن كان التطبيق مسجلًا في توقيع تطبيقات Google Play وضاع مفتاح الرفع أو انكشف، فإن Google يمكنها إعادة تعيينه بحسب صفحة توقيع التطبيقات في Play Console. أما إن لم يكن مسجلًا فالحلول محدودة، فتحقق من هذه النقطة يوم الاستلام لا يوم أول تحديث عاجل.
كيف تقرأ النتيجة: ثلاث حالات وقرار كل منها
خذ مشروعًا افتراضيًا: تطبيق حجز لمركز خدمات، مبني بـ Flutter مع خادم Laravel ولوحة تحكم. بعد الاختبار والمطابقة، تنتهي عادة إلى واحدة من ثلاث حالات:
- مكتمل ومطابق: بُني كل شيء من الصفر، ورقم الإصدار يطابق المتجر، وملفات الخادم تطابق الوسم، والمخطط يطابق الإنتاج. وقّع الاستلام، وابدأ فورًا تدوير المفاتيح التي يعرفها المطور السابق، كما في مقالة تدوير مفاتيح API بعد تغيير المطور.
- ناقص يمكن استكماله: البناء نجح بعد طلب ملف بيئة وملف إعداد Firebase، وظهر جدولان في الإنتاج ليسا في ملفات التعديل، وملفات قليلة على الخادم أحدث من المستودع. اكتب النواقص في سجل، واطلب استكمالها كتابيًا قبل الدفعة الأخيرة أو توقيع المحضر، ثم أعد الاختبار على ما استُكمل.
- غير قابل للإثبات: الكود أقدم من المنشور بإصدارات، أو الخادم غير موجود، أو التطبيق لا يُبنى أصلًا. هنا لا تتفاوض على ملف آخر فحسب؛ قيّم ما يمكن استعادته من الخادم وملفات البناء، وما الذي يلزم إعادة بنائه. مقالة تطبيق بلا كود مصدري تشرح الخيارات الواقعية في هذه الحالة.
إثبات الاكتمال لا يقول شيئًا عن الجودة. قد تستلم كودًا كاملًا ومطابقًا لكنه صعب الصيانة أو فيه ثغرات. إن كنت ستبني عليه، فالخطوة التالية مراجعة الكود المصدري وتدقيق المعمارية: تقرير مستقل مرتب حسب الخطورة، بملخص لصاحب القرار وأدلة للفريق التقني، ونتائج فحص آلي للجودة والمكتبات والأسرار.
أخطاء شائعة عند استلام الكود المصدري من المطور
- توقيع محضر الاستلام عند وصول الملف: قبل أي اختبار بناء. بعد التوقيع والدفعة الأخيرة تضعف قدرتك على المطالبة بالنواقص.
- الاكتفاء بفتح المجلدات: وجود مجلد باسم الخادم لا يعني أن محتواه يعمل أو أنه آخر نسخة.
- قبول «الملفات الحساسة سأرسلها لاحقًا»: ملفات البيئة والمفاتيح جزء من التسليم لا ملحق اختياري. بدونها لا يُبنى شيء.
- نسيان ما عُدل على الخادم مباشرة: إصلاحات عاجلة كُتبت على خادم الإنتاج ولم تُرفع للمستودع تضيع مع أول نشر جديد.
- الاعتماد على الإنتاج بدل ملفات التعديل: نسخة من قاعدة الإنتاج تشغّل التطبيق اليوم، لكنها لا تثبت أنك تستطيع إنشاء بيئة اختبار نظيفة غدًا.
- ترك المطور السابق بصلاحياته: تستلم الكود وتنسى أن حساباته ما زالت تصل إلى المستودع والخادم والخدمات.
ما تطلبه من المطور مع الكود: صياغة طلب التسليم
أرسل الطلب كتابيًا قبل موعد التسليم، واربطه بالدفعة الأخيرة إن أمكن. صياغة تصلح أساسًا لرسالتك:
نطلب تسليم الكود المصدري لكل مكونات التطبيق بنقل المستودعات إلى حساب المنشأة أو بحزمة Git كاملة بكل الفروع والوسوم، مع وسم يحدد الكود الذي بُني منه آخر إصدار في كل متجر وآخر نشر على الخادم، وملفات تعديل قاعدة البيانات، وسكربتات البناء والنشر، وملف تعليمات للتشغيل والبناء. وتُسلم ملفات البيئة والمفاتيح وكلمات مرور التوقيع بقناة آمنة منفصلة. ويُعد التسليم مكتملًا بعد نجاح بناء التطبيق والخادم من الصفر لدى جهة تحددها المنشأة، ومطابقة الإصدار المبني للإصدار المنشور، واستكمال أي نقص يظهر في ذلك.
واطلب معه ثلاثة أشياء قد لا يتطوع بها: قائمة بأي تعديلات أُجريت مباشرة على خادم الإنتاج، وقائمة بالخدمات الخارجية التي يعتمد عليها الكود وباسم من حساباتها، وساعات محددة للرد على أسئلة الاختبار خلال فترة متفق عليها. هذه الصياغة توعية تجارية لا استشارة قانونية؛ راجعها مع مستشارك إن كانت جزءًا من عقد أو تسوية.
ما تجهزه قبل التواصل مع جهة تتحقق من الكود
إن لم يكن لديك مطور مستقل، فجهة خارجية تستطيع تنفيذ الاختبار والمطابقة. هذه المواد تختصر العمل:
- ما استلمته كما هو: الملف أو رابط المستودع، دون تعديل أو إعادة ترتيب.
- روابط التطبيق في المتجرين، وصلاحية اطلاع على Google Play Console وApp Store Connect لرؤية أرقام الإصدارات.
- وصول للقراءة إلى خادم الإنتاج وقاعدة بياناته، أو نسخة احتياطية حديثة.
- العقد أو نطاق العمل الأصلي، لمعرفة ما كان يجب أن يُسلم.
- أي مراسلات مع المطور عن التسليم، وما وعد بإرساله لاحقًا.
- حساب اختبار في التطبيق المنشور لمقارنة الشاشات.
عند استلام مشروع برمجي متعثر نبدأ بجرد كل ما يخص المشروع من مستودعات وخوادم ونطاقات وحسابات، ونأخذ نسخة احتياطية لكل ما هو قائم قبل أي تغيير، ثم نقيّم ما يُبنى عليه وما يُعالج وما يُعاد. وإن كان الكود في جهاز المطور فقط، نستعيد ما يمكن من الخادم أو ملفات البناء ونقيّم هل يكفي للاستمرار. ولفحص ما يمكنك التحقق منه بنفسك قبل التوقيع دون خلفية برمجية، راجع مقالة فحص الكود المصدري قبل الاستلام.
الخلاصة: الاستلام يثبت بالبناء والمطابقة لا بالملف
لا تسأل «هل استلمت الكود؟» بل «هل يستطيع غير المطور السابق أن يبني من هذا الكود النسخة التي يستخدمها عملائي الآن، وأن يرفع تحديثًا لها؟». إن كانت الإجابة نعم بدليل مكتوب، فقد استلمت. وإن ظهرت نواقص، فسجلها وطالب بها قبل التوقيع والدفعة الأخيرة، لا بعدهما.
إن كان بين يديك كود مستلم ولا تعرف هل هو كامل، أو تستعد لاستلامه من مطور يغادر المشروع، اطلب مراجعة المشروع، ونحدد نطاق الفحص ومدته قبل البدء، ونسلّمك تقريرًا بما هو مكتمل وما ينقص وما يلزم لاستكماله.
أسئلة شائعة
لا يكفي وحده. الملف لقطة واحدة بلا تاريخ ولا فروع ولا وسوم تحدد النسخة المنشورة، وغالبًا بلا ملفات البيئة والمفاتيح. اطلب نقل المستودع إلى حساب منشأتك أو حزمة Git كاملة، ثم أثبت الاكتمال باختبار بناء من الصفر ومطابقة مع الإصدار المنشور.
لأنها تُستثنى منه عمدًا لأسباب أمنية في المشاريع المبنية بطريقة صحيحة. غيابها من المستودع ليس نقصًا، لكن غيابها من التسليم نقص. اطلبها بقناة آمنة منفصلة أو داخل خزنة أسرار تملكها المنشأة، مع قائمة بكل سر وأين يُستخدم.
قارن رقم الإصدار والبناء في الكود بآخر إصدار في Google Play Console وApp Store Connect، وقارن ملفات الخادم بوسم الإصدار في المستودع، ومخطط قاعدة الإنتاج بما تنشئه ملفات التعديل، وامشِ شاشات النسخة المنشورة والمبنية جنبًا إلى جنب.
نعم لاختبار البناء والمطابقة، على أن يكون مطورًا لم يعمل في المشروع ويعمل على بيئة نظيفة. أما التحقق من وجود البنود وصلاحيات الحسابات وأرقام الإصدارات في المتاجر فيستطيع صاحب المشروع القيام به بنفسه.
إن كان التطبيق مسجلًا في توقيع تطبيقات Google Play، فيمكن أن تعيد Google تعيين مفتاح الرفع بعد طلب من صاحب الحساب. وإن لم يكن مسجلًا فالحلول محدودة، لذلك تحقق من هذه النقطة يوم الاستلام قبل أن تحتاج إلى تحديث عاجل.
خدمات وصفحات مرتبطة
اقرأ أيضًا
لا تعرف هل الكود الذي استلمته كامل؟
نحدد نطاق الفحص قبل البدء، ونختبر بناء الكود ومطابقته للإصدار المنشور، ونسلّمك تقريرًا بما هو مكتمل وما ينقص.