اختيار التقنية يبدأ من سؤال الصيانة لا من سؤال الموضة

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

لماذا يهم سؤال الصيانة أكثر من سؤال السرعة

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

Swift لتطبيقات آيفون، وKotlin لأندرويد، وFlutter لبناء تطبيق واحد يعمل على المنصتين، وكل واحد منها له مكانه الصحيح. المشكلة تظهر عندما يُختار الواحد منها لأنه يبدو الأحدث أو لأن مقالة ما أثنت عليه، لا لأنه يناسب المنتج وفريقه.

ما الذي يحدد الاختيار فعلاً

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

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

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

الخطأ الشائع: اختيار الأداة قبل تعريف المشكلة

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

خطوة عملية قبل القرار

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

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