المطور يقترح لغة Kotlin لتطبيق Android، فهل هذا هو الخيار الصحيح؟

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

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

إحنا طلعنا تطبيق حجوزات مشابه بإطار متعدد المنصات مع مبرمج واحد في 4 شهور وبمجموع 18,000 دولار على الأندرويد والـ iOS مع بعض. صار له سنتين شغال ومصروف الصيانة الشهري ما يتعدى 1,500 دولار راتب دعم لمطور واحد. لو بدأنا بلغتين محليتين منفصلتين كان هالمصروف صار على الأقل 3,500 دولار شهريًا.

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

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

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

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

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

عانيت من نفس الشيء. وضع عملية لطلبات التغيير لا يبطئ العمل، بل يسرّعه.

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

أخذت ملاحظة، شكرًا لك. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

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

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

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

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

القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

تشتت النقاش، دعني ألخصه. تسير الأمور على ما يرام في الأشهر الثلاثة الأولى، وتظهر المشاكل في الشهر الرابع.

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

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

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

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

صححوا لي إن أخطأت.

هناك نقطة لم أفهمها لكن يعني كل عبارة "سننظر في ذلك لاحقًا" في الاجتماع تعني عملًا غير مُسعّر.

يجب فتح بيانات الوصول باسم المؤسسة، وليس بحسابات شخصية. أتمنى أن يفيدك هذا.

شكراً لكتابة هذا، فهو صحيح تماماً... الكود بدون وثائق تثبيت لا يُعتبر ملكك حتى لو كان بين يديك.

هذا كل شيء، أرجو المعذرة إذا أطالت.

سأجمع الموضوع، لأن هناك عدة إجابات مختلفة. أغلى شيء في النظام الموروث هو التبعيات غير المعروفة.

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.