حين يؤول إليك تطبيق بناه غيرك
تنتقل التطبيقات من يد إلى يد أكثر مما يتوقع أصحابها. فقد تُستبدل الشركة المطوّرة، أو ينتقل المطوّر المستقل إلى عمل آخر، أو تُشترى شركة ومعها تطبيقها، أو يستقيل مطوّر داخلي. وفي كل حالة يصبح شخص ما مسؤولاً عن منتج لم يبنه، وفي الغالب بمعلومات أقل مما يحتاج إليه.
والخطر هنا محدد. فالشيفرة جزء واحد من التطبيق، أما البقية فصفحة في متجرين، ومجموعة من مفاتيح التشفير، وخادم، وقاعدة بيانات للمستخدمين، وسلسلة من الخدمات الخارجية. وإن ضاعت حلقة واحدة، فقد تعجز عن تحديث التطبيق أصلاً. لذلك رتّبنا الأسئلة أدناه بحسب هذه الحلقات.
الحسابات ومفاتيح التوقيع
ابدأ من هنا، فهذا هو الموضع الذي يفشل فيه التسليم فشلاً لا يمكن إصلاحه.
- 01
باسم من حسابات المطوّر التي يُنشر منها التطبيق في كل متجر؟
لماذا يهمّ السؤالإن كانت صفحة التطبيق في حساب الشركة السابقة، فلا بد من نقلها. ولكلا المتجرين إجراء موثّق للنقل، بشروط يسهل استيفاؤها ما دامت تلك الشركة متعاونة.
- 02
من أصحاب الحسابات ومديروها؟
لماذا يهمّ السؤالتحتاج إلى مدير من داخل مؤسستك، ببريد إلكتروني تابع للشركة، قبل أن تُسحب صلاحيات أي طرف آخر.
- 03
أين مفاتيح التوقيع والشهادات؟
لماذا يهمّ السؤاليجب أن تُوقَّع التحديثات بالمفتاح الصحيح. ومن دونه، أو من دون إعادة تعيين يرتّبها المتجر، لا يمكنك نشر إصدار جديد على صفحة التطبيق الحالية.
- 04
ما المفاتيح التي يستخدمها التطبيق للإشعارات الفورية وتسجيل الدخول؟
لماذا يهمّ السؤالهذه المفاتيح تنتهي صلاحيتها أو ترتبط بحسابات بعينها. وإن انتهت، تتوقف الإشعارات أو تسجيل الدخول عبر حسابات التواصل الاجتماعي دون سابق إنذار.
- 05
هل هناك شيء في حساب شخصي؟
لماذا يهمّ السؤالمفاتيح على حاسوب محمول، أو خدمة تُدفع ببطاقة شخصية، أو نطاق مسجّل باسم فرد: هذه هي المفاجآت المعتادة.
الشيفرة المصدرية والقدرة على بنائها
استلام مجلد من الشيفرة لا يثبت الكثير. المهم أن يستطيع مطوّر لم يعمل على المشروع قط أن ينتج التطبيق نفسه الموجود في المتاجر.
- 01
اطلب المستودع كاملاً بسجل تعديلاته
الملف المضغوط الخالي من السجل يخفي من غيّر ماذا ولماذا. وسجل التعديلات توثيق لا يمكنك إعادة إنشائه.
- 02
تأكد أنه يطابق الإصدار المنشور
يجب أن يطابق الإصدار الموجود في المتاجر نقطة معلَّمة في المستودع. وإن لم يستطع أحد أن يحددها، فتوقّع وجود اختلافات.
- 03
اطلب من جهة مستقلة أن تبنيه
البناء النظيف على جهاز جديد، باتباع التعليمات المكتوبة، هو الاختبار الحقيقي. فهنا يظهر كل مفتاح أو إعداد سري مفقود، وكل خطوة غير موثقة.
- 04
اكتب قائمة بالمكتبات التي يعتمد عليها وأعمارها
أطر العمل القديمة والمكتبات المهجورة هي المصدر الرئيسي لتكلفة الترقية. واسأل متى حُدّثت آخر مرة.
- 05
اسأل عمّا ليس في المستودع
الإعدادات وأسرار البيئات ونصوص البناء وشيفرة الخادم كثيراً ما تُحفظ في مكان آخر.
ويقدّم لك التدقيق التقني للشيفرة هذا التقييم مكتوباً قبل أن تلتزم بأي خطة.
الخادم والبيانات والخدمات الخارجية
| المجال | ما تطلبه | السبب |
|---|---|---|
| الاستضافة | صلاحية الوصول إلى الحساب، وملخص للبنية التقنية، والتكلفة الشهرية | يجب أن تستطيع تشغيلها ودفع تكلفتها |
| قاعدة البيانات | مكانها، وصلاحيات الوصول إليها، وروتين النسخ الاحتياطي، واستعادة مختبرة | بيانات المستخدمين هي الأصل الذي لا يمكن إعادة بنائه |
| الخدمات الخارجية | قائمة بها مع الحساب الذي يقف وراء كل منها: المدفوعات، والخرائط، والرسائل، والتحليلات، وتقارير الأعطال | كل منها اعتماد على طرف آخر، وفاتورة |
| التكاملات | أنظمة الأعمال التي يتبادل التطبيق البيانات معها، وطريقة ذلك | التغييرات فيها قد تعطّل التطبيق |
| البيئات | هل توجد بيئة اختبار منفصلة عن بيئة التشغيل الفعلي | من دونها، يُختبر كل تغيير على المستخدمين الحقيقيين |
| المراقبة | التنبيهات الموجودة، ومن يتلقاها | وإلا فسيبلغك المستخدمون بالأعطال قبل أن تراها |
المستخدمون والحقوق والالتزامات
- الاستخدام وحالة التطبيق. اطلب عدد المستخدمين النشطين، ومعدلات التوقف المفاجئ، وتقييمات المتجر، والمراجعات الأخيرة. فهي تبيّن حالة التطبيق وما ينتظره المستخدمون.
- الحقوق في الشيفرة. تحدد اتفاقية المشروع مع من بنى التطبيق شروط الملكية والترخيص، لذلك اطلب تلك الاتفاقية، واقرأ ما تقوله عن الشيفرة المخصصة، والمكونات المعاد استخدامها، وتراخيص المصادر المفتوحة.
- التزامات الخصوصية. سياسة الخصوصية، وإفصاحات الخصوصية في المتاجر، وأي نصوص للموافقة، كلها وعود للمستخدمين أصبحت الآن على عاتقك. فتأكد أن التطبيق يفعل ما تقوله.
- العقود والاشتراكات. قد تحتاج الباقات المدفوعة واتفاقيات الخدمة وعقود الدعم إلى نقلها باسمك.
- المشكلات المعروفة. اسأل بصراحة: ما المعطّل، وما الذي أُجّل، وما الذي كان الفريق السابق سيصلحه أولاً؟ فمعظم الناس يجيبون بصدق حين يُسألون مباشرة.
مثال تطبيقي
شركة تجزئة تغيّر الشركة المطوّرة لتطبيقها
هذا مثال افتراضي يبيّن ترتيب الأحداث. شركة تجزئة تنهي عقدها مع الشركة التي بنت تطبيق التسوق الخاص بها، وتعيّن شركة جديدة.
- الحساباتتطبيق iOS في حساب شركة التجزئة نفسها، لكن تطبيق Android منشور باسم الشركة القديمة. فيُطلب النقل والعقد القديم ما زال أمامه شهر.
- المفاتيحيُعثر على مفتاح توقيع تطبيق Android في جهاز موظف سابق لدى الشركة القديمة، فيُسلَّم مع بيانات اعتماد الإشعارات الفورية.
- البناءفي البداية تعجز الشركة الجديدة عن بناء التطبيق من المستودع، لأن ملفَّي إعدادات ومكتبة خاصة لم تكن فيه. فتسلّمها الشركة القديمة خلال فترة الإشعار.
- الخادمتكتشف شركة التجزئة أن الخادم يعمل على الحساب السحابي للشركة القديمة. فيُنقل إلى حسابها الخاص خلال عطلة نهاية أسبوع، بعد أخذ نسخة احتياطية مختبرة.
- الإصدار الأولتنشر الشركة الجديدة تحديثاً صغيراً في المتجرين، لا يغيّر سوى رقم الإصدار وخطأ إملائي، لتثبت أن السلسلة كلها تعمل.
صارت شركة التجزئة تتحكم في كل حلقة. ولو طُرحت الأسئلة بعد شهر، أي بعد انتهاء العقد القديم، لتوقف نقل تطبيق Android وتسليم الملفات الناقصة على حسن النية وحده.
ماذا تفعل في الأسابيع الأولى
حين يصبح التطبيق بين يديك، قاوم الرغبة في إضافة ميزات جديدة. أثبت سيطرتك عليه أولاً، ثم ثبّت استقراره، ثم حسّنه.
بداية سليمة
- انشر تحديثاً بسيطاً في المتجرين
- غيّر كلمات المرور واسحب صلاحيات من غادروا
- استعد نسخة احتياطية لتتأكد أنها تعمل
- دوّن ما تعلمته ما دام حاضراً في ذهنك
- عالج حالات التوقف المفاجئ قبل إضافة الميزات
بداية محفوفة بالمخاطر
- البدء بإعادة كتابة التطبيق قبل فهم القديم
- إبقاء صلاحيات الفريق السابق كما هي
- افتراض وجود نسخ احتياطية لأن أحداً قال ذلك
- الوعد بموعد لميزة جديدة قبل أول بناء نظيف
- ترك الشهادات أو الاشتراكات تنتهي أثناء الانتقال
وإن تبيّن أن التطبيق في حالة سيئة، فمقارنتنا بين تحديث البرمجيات القديمة واستبدالها تشرح كيف تختار بين الإصلاح وإعادة البناء.
قائمة التحقق عند تسلّم تطبيق
قائمة التحقق عند تسلّم تطبيق
0 من 11 منجزةماذا تفعل الآن
أرسل القائمة اليوم إلى الفريق المغادر، واطلب كل بند منها في موعد يقع ضمن فترة الإشعار. وتابع الحسابات والمفاتيح قبل أي شيء آخر.
وإن أردت مساعدة في تقييم ما تسلّمته، فصفحة تحديث تطبيقات الجوال تشرح كيف نتسلم التطبيقات القائمة. أخبرنا بما سُلّم إليك، وسنقول لك ما الذي نتحقق منه أولاً.
أسئلة شائعة
ماذا لو رفض المطوّر السابق تسليم مفاتيح التوقيع؟
أثِر المسألة رسمياً ومبكراً، مستنداً إلى الاتفاقية بينكما. وإن تعذّر الحصول على المفاتيح، فلدى المتاجر طرق موثقة قد تساعد، مثل إعادة تعيين المفتاح حين يتولى المتجر إدارة توقيع التطبيق، أو نشر التطبيق في صفحة جديدة كحل أخير. لكن الصفحة الجديدة تخسر التثبيتات الحالية والتقييمات والمراجعات، لذلك يستحق تجنّبها جهداً كبيراً.
هل يمكن نقل تطبيق من حساب مطوّر إلى آخر؟
يوثّق كلا المتجرين الرئيسيين إجراءً للنقل يحافظ على مستخدمي التطبيق وتقييماته ومراجعاته. لكن للنقل شروطاً، وقد تعقّده بعض الميزات أو حالات الحساب، فاقرأ وثائق المتجر الحالية قبل أن تبني خطتك عليه. ويتطلب النقل إجراءً من الحساب الذي يملك التطبيق حالياً، ولهذا يهمّ التوقيت.
هل نعيد كتابة التطبيق الذي آل إلينا؟
ليس كخطوة أولى. فإعادة الكتابة تُهدر سلوكاً يعمل ولم يوثقه أحد، وتستغرق وقتاً أطول من المتوقع. ثبّت استقرار التطبيق الحالي، وتعرّف على طريقة استخدامه، واطلب تقييماً لشيفرته. وتصبح إعادة الكتابة مبررة حين تفقد التقنية دعمها، أو حين يكلف كل تغيير أكثر مما ينبغي، ويجب أن تُبنى هذه الحجة على أدلة.
كيف نعرف إن كانت الشيفرة جيدة؟
اطلب من مطوّر مستقل أن يبنيها ويقرأها ويكتب تقريراً. ومن المؤشرات المفيدة: هل تُبنى دون مشكلات، وما عمر المكتبات التي تعتمد عليها، وهل توجد اختبارات، ومدى اتساق هيكلها، وكم مرة يتوقف التطبيق فجأة لدى المستخدمين. وتقرير تدقيق مكتوب بالأولويات تكلفة متواضعة مقارنةً بتخطيط عام كامل من العمل على افتراض خاطئ.
ماذا نسأل الفريق السابق قبل أن يغادر؟
إلى جانب صلاحيات الوصول والملفات، اطلب منهم شرحاً للبنية التقنية وعملية الإصدار والمشكلات المعروفة، وسجّل هذا الشرح. واسألهم عمّا كانوا سيصلحونه أولاً، وعمّا لم يكونوا ليلمسوه أبداً. فساعة واحدة من حديث مسجّل مع من بنوا التطبيق توفّر في الغالب أسابيع من البحث لاحقاً.
