هل لغة برمجة تطبيق iOS تغير سعر عرض الوكالة وميزانية الصيانة؟

هل وضّحتم بالضبط ما سيفعله التطبيق؟ هل سيتضمن قراءة الباركود عبر البلوتوث، أو تتبع GPS لحظي في الخلفية، أو رسوم متحركة معقدة للكاميرا؟ إذا كانت المسألة مجرد عمليات قاعدة بيانات قياسية مثل عرض المنتجات وتأكيد الطلبات وإرسال الإشعارات، فقد لا يستحق الأمر دفع فرق 110.000 TL مقابل الـ native. لكن إذا كان هناك تكامل ثقيل مع العتاد، فالمنصات المتقاطعة ستكلفكم أكثر لاحقاً.

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

فكرة أن الـ native هو الحل الصلب الوحيد مبالغ فيها شوي. اليوم حتى تطبيقات البنوك والتجارة الإلكترونية الكبرى كثير من شاشاتها تعمل بواجهات منصات متقاطعة أو مبنية على الويب. الأهم من اللغة التي تستخدمها الوكالة هو مدى خبرة الفريق بتلك اللغة. تطبيق native مكتوب بمعمارية سيئة ينتج تكاليف صيانة أكثر بكثير من تطبيق منصات متقاطعة مُصمَّم جيداً.

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

البنود التي يجب أن تُضيفوها إلى دفتر الشروط قبل الجلوس مع الوكالة: 1) يجب التحقق من أن الأكواد المصدرية مكتوبة وفق معايير المعمارية النظيفة وأن التعليقات داخل الكود كاملة. 2) يجب إلزامهم بأن تكون اللغة المستخدمة بإصدار حديث ومدعوم على المدى الطويل. 3) عند تسليم المشروع يجب تقديم بيان تراخيص وإصدارات لجميع المكتبات الخارجية. 4) في حال توقف الوكالة عن الدعم، يجب إعداد دليل تثبيت خطوة بخطوة حتى يتمكن فريق آخر من تشغيل المشروع.

حنا بعد كنا بنفس الحيرة لكن لما دورنا على مبرمج freelance بعدين شفنا التالي: معظم اللي يشتغلون بالهجين جدد في السوق ويعرفون المنصتين بشكل ناقص. لما اشتغلت الشغلة اضطرينا ننتقل للـ native. إذا الميزانية تسمح والهدف iOS فقط، البدء بالـ native النظيف من البداية يعطيك راحة بال.

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

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

صحيح. يجب فتح بيانات الوصول باسم المؤسسة، وليس بحسابات شخصية.

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

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

أتمنى أن يفيدك هذا.

أنت محق.

أنت محق تمامًا. أغلى شيء في النظام الموروث هو التبعيات غير المعروفة.

مثبت بالتجربة.

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

معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة. لو كنت مكانك، لسلك هذا المسار.

هل يمكنك توضيح هذا أكثر؟ فعل الجميع لشيء ما لا يعني أنه صحيح.

بالتوفيق.

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

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

ليس لدي خبرة في لغة تطبيق ios، لذا أسأل. محاولة فعل هذا بمفردك هي أغلى الطرق.

هناك نقطة أثارت فضولي. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.