مرحبًا ، أنا أندري كوتشرينكو ، قائد فريق تطوير الأجهزة المحمولة Skyeng. نصنع تطبيقات الهاتف المحمول لنظامي التشغيل iOS و Android. لديهم نفس الوظيفة ونفس الواجهة دقيقة للأسلوب. ولكن نظرًا لوجود منصات مختلفة ، فإن تطوير تطبيق واحد يبدو مكلفًا للغاية. بحثًا عن فرص للحفظ في تطوير الأنظمة الأساسية المحمولة ، جربنا أربعة حلول:
- الجمع بين مطوري iOS و Android في فريق واحد
- إنشاء مجموعات عمل لحل المشكلات المعقدة
- حفظ على الوثائق
- كتابة التعليمات البرمجية الشائعة
لقد أتيحت لي الفرصة لتقديم عدة تقارير حول ما جاء منها ؛ في هذه المقالة ، جمعت الملاحظات والنتائج الرئيسية.
الجمع بين مطوري iOS و Android في فريق واحد
قبل عامين ، كان لدينا تطبيقان منفصلان للهاتف المحمول وفريقان للتطوير ، متصلان فقط بواسطة مدير منتج مشترك. نشأت الكثير من هذه المشاكل: كانت تطبيقات بعضها البعض تشبه ظاهريًا عن بُعد فقط ، فقد عملوا بطرق عديدة ، ولم يكن لدى المطورين أي فكرة عن كيفية ترتيب التطبيق المجاور ، فقاموا دائمًا بإخراج كل أنواع الأخطاء والأخطاء في المنطق. في مرحلة معينة ، أصبح من الواضح أن هذا لا يمكن أن يستمر ، وكان أول ما فعلناه في هذا الصدد هو توحيد مطوري iOS و Android في فريق منتج واحد ، مما يجعل عددًا من العمليات شائعة.
أصبحت إحدى هذه العمليات مراجعة تقنية.
قبل الوصول إلى المطور ، فإن المهمة تسير بطريقة معينة. بادئ ذي بدء ، يتم صياغتها بتنسيق قصة المستخدم ، ويتم رسم الرسومات أو التخطيطات عليها ، وبعد ذلك تبدأ ملحمة يتم فيها وصف مشكلة المستخدم والحل. في هذا النموذج ، تندرج القصة في قيادة الفريق إذا كانت ملحمة مشتركة للفريق ، أو لقيادة فريق واحد إذا كانت موجودة في نفس الفريق. هناك كل شيء متحلل إلى مستوى المهام الفردية. في كل مهمة من هذه المهام ، إذا كان ذلك مناسبًا ، يتم وصف حل ممكن ، والمهام الموجودة داخل Epic تصل إلى بعضها البعض ، ويتم تثبيت حاصرات متعددة ، مما يزيل الكثير من الاتصالات غير الضرورية. بعد ذلك ، تتم المراجعة الفنية مباشرةً ، والتي سيتم فيها تحديد القرار النهائي وسيتم وضع التقدير. في هذه المرحلة أيضًا ، يمكن أن تتحلل المهمة أكثر إذا تم الحصول على التقدير لأكثر من يومين.
كيف نحفظ في المراجعة الفنية المشتركة:
- في معظم الحالات ، يتحول إلى نفس الحل التقني لنظامي التشغيل iOS و Android. الحلول المختلفة ممكنة أيضًا ، وقد يكون هذا بسبب اختلاف بنية المنصات ، لكن في سياق المهمة يكون الفرق في كثير من الأحيان ضئيلًا ؛
- مزامنة بنية وهيكل التطبيقين. هذا يلغي الموقف عندما يأتي المنتج بميزة أخرى ، ونقوم بتقييم مهمة iOS خلال ساعتين ، و Android في الأسبوع ، لأنه يجب إعادة كتابة كل شيء هناك ؛
- في أكثر الأحيان ، نحصل على درجة جيدة. إذا كانت تقييماتنا للمنصات مختلفة تمامًا ، فقد يشير ذلك إما إلى أن المطورين لم يفهموا المهمة ، أو بعض مشكلات النظام الأساسي التي تحتاج إلى معالجة ؛
- من خلال هذا الاستعراض ، يتم تبادل الخبرات بين مطوري iOS و Android ، وأعتقد أنه ينبغي أن يكون لديهم فكرة عن كيفية عمل النظام الأساسي المجاور. غالبًا ما يتبين أن الحل من نظام أساسي ناجح لآخر ؛
- تبسيط الاختبار اليدوي. يتم تطبيق الميزات على أساس حل تقني واحد ، إذا وجدت QA أي أخطاء ، فهذه مناسبة لتكرار نفس الخطوات على منصة أخرى. في أغلب الأحيان نفس الأخطاء موجودة أيضًا ؛
- جنود عالميون ، قادرون على الكتابة لكلتا المنصتين: إذا كان الأمر كذلك ، فيمكنك التبديل بينهما بين المشاريع ، مما يزيد من عامل الناقل ويجعل من السهل نقل الإجازات والغياب. لا توجد مواقف عندما يتم تشغيل منصة واحدة إلى الأمام بعيدًا خلال العطلات.
عامل الحافلة: هو عدد الأشخاص في الفريق الذين يجب أن تسقط الحافلة بحيث لا يمكن أن يستمر المشروع.
مجموعات العمل لحل المشكلات المعقدة
لحل مشكلة ، في كثير من الأحيان ، بالإضافة إلى كتابة التعليمات البرمجية مباشرة ، نحتاج إلى إجراء بعض الأبحاث ، وتنفيذ التصميم ، وإذا كانت المهمة تنطوي على تفاعل بين الفريق ، وقضاء الكثير من الوقت على التواصل. في سياق تطوير الأجهزة المحمولة ، فإن أي مهام لا تتطلب كل هذا تعتبر شيئًا تافهًا ، ولا تنطوي على عمل من الواجهة الخلفية. أنا أسميها "بسيطة" ، وكل ما تبقى - "معقدة".
قمت بتحليل سجلات العمل فيما يتعلق بتوزيع الوقت الذي يقضيه في كتابة التعليمات البرمجية والاتصال والتصميم والبحث. إليك ما يحدث للمهام البسيطة:
كل شيء واضح هنا ، نكتب الكود بشكل أساسي ، وتكلفته تصل إلى 80٪ من الوقت.
في كثير من الأحيان ، تتطلب المهام نوعًا ما من التحسين من الواجهة الخلفية ، وهذا يجعله تلقائيًا أمرًا داخليًا. هنا ، يتم قضاء المزيد من الوقت في التصميم والتواصل. يتم تقليل حصة كتابة التعليمات البرمجية:
غالبًا ما تأتي المنتجات بمهام لا تتلاءم بشكل جيد مع البنية الحالية للتطبيق ، ونحن بحاجة إلى قضاء بعض الوقت لإيجاد حل جيد: ربما تخطط لبعض عمليات إعادة البناء ، أو قم بتنفيذها على الفور كجزء من المهمة ، إلخ. في هذه الحالة ، يتم إنفاق الكثير من الوقت على التصميم:
أخيرًا ، المهام التي من غير الواضح عمومًا كيف تتعامل معها ، حيث يجب عليك أولاً البحث والتصميم:
إذا كان العمل في المهام المعقدة لا يمكن تنسيقه بأي شكل من الأشكال ، فسيتم كل العمل الذي لا يرتبط مباشرة بكود الكتابة مرتين. وفي المهام المعقدة ، هذا هو 50 ٪ من وقت الحل ، وغالبا ما يكون أكثر.
لقد وجدت طريقة للخروج: لقد أخذت كل هذه المهام وحبستها على نفسي. تمكنت من توفير الوقت ، لكنني أصبحت مثقلة باستمرار ، لم يكن لدي ما يكفي من الوقت لإيلاء الاهتمام للمهام ذات الأولوية المنخفضة ، وكان على المطورين الانتظار بالنسبة لي ، كل شيء كان سيئًا. نشأت المشكلة مرة أخرى ، وقمنا بالفعل بحلها عن طريق إنشاء مجموعات عمل.
مجموعة العمل هي بعض مطوري iOS و Android الذين سيشاركون مباشرة في تنفيذ هذه الميزة. يتم تعيين أحدهم كقائد ، وسيكون هو المسؤول عن التصميم والبحث والتفاعل مع الفرق الأخرى. ستكون نتيجة عمله وثائق ، حيث يتم إصلاح كل شيء ؛ يتم بعد ذلك مراجعة هذه الأرصفة بواسطة مجموعة العمل وقيادة الفريق ، ويستكمل الفريق عملية التنفيذ.
نتيجة لذلك ، تلقينا:
- انخفض الحمل على Timlid ، في حين أنه لا يفقد السيطرة على تقدم المهمة. أشارك في جميع الاجتماعات الرئيسية ، واستعرض الحل التقني ، وأتحكم فعليًا في المهمة قبل أن تدخل مرحلة التطوير ؛
- كان المطورون متحمسون للغاية. عندما اختبرنا هذه الممارسة ، جاء الجميع وقالوا "بارد ، دعونا نحاول مرة أخرى." لم يكن هناك أشخاص لا يريدون القيام بذلك ويفضلون "الترميز فقط". الناس لديهم المزيد من الفرص للتنمية.
- زاد عامل الحافلة ، أصبح الفريق أكثر استقلالية ، بالإضافة إلى أولئك الذين يمكن تطويرهم بشكل أكبر ليصبحوا قادة فريق مرئيين بشكل واضح في مثل هذه المهام. يتم حل مشكلة ترك Timlida في إجازة.
حفظ على الوثائق
قررنا الاحتفاظ بالوثائق في السوق وتخزينها في مستودع جيثب. تتم مراجعة الوثائق جنبًا إلى جنب مع الكود وطلب السحب ، لذلك نستبعد المواقف التي يكون فيها شيء ما مكتوبًا ، ولكن لا أحد يقرأه ، وعندما يكون مطلوبًا ، لا أحد يفهم أي شيء. يتيح لك التوثيق الذي يحتوي على رمز الغوص في السياق وفهم ما كان كل شيء يجلبه المستثمرون.
نقوم بتحرير الوثائق مباشرة من IDE ، معظمها قادر على تقديم تخفيض ، ولا يمزقك من كتابة التعليمات البرمجية ، لا يتعين عليك الذهاب إلى نقطة التقاء في مكان ما ، يتم تقليل خطر أن ينسى المطور تحديثه. بالنسبة لأولئك الذين قاموا بتنزيل المستودع محليًا ، نرمي روابط إلى جيثب ، ويمكنهم أيضًا قراءة كل شيء.
أخيرًا ، يساعد أسلوب الإرساء هذا في تطوير مطور جديد: إلى جانب الكود ، يتلقى جميع أنماط التعليمات البرمجية والاتفاقيات وتعليمات تجميع التطبيقات ، ودخول الفريق أسهل كثيرًا.
كود مشترك
ليست فكرة كتابة الكود الموحد هي الأحدث ؛ فهناك مجموعة من الأدوات للقيام بذلك. جربنا C ++ لكتابة مكتبة المفردات ، ولدينا تطبيق صغير مكتوب بالكامل في Kotlin Multiplatform. من الناحية النظرية ، عند استخدام أداة تطوير مشتركة بين الأنظمة الأساسية ، يجب تخفيض تكاليف كتابة التعليمات البرمجية الخاصة بنا إلى النصف. ولكن تظهر إضافية:
تكاليف بدء التشغيل. يجب إنفاق الكثير من الوقت على جمع وفرض واختبار واختبار الفرضيات وتدريب فريق. في بعض الحالات ، تكون هذه التكاليف كبيرة لدرجة أن الربح غير مرئي على الإطلاق ؛
كتابة رمز النظام الأساسي. من تجربتي الخاصة وبناءً على عدد من المصادر ، يمكنني القول أنه بغض النظر عن الأداة التي تختارها ، إذا كان لديك تطبيق معقد إلى حد ما ، فسوف يتعين عليك عاجلاً أم آجلاً كتابة رمز النظام الأساسي. يختلف الوقت اللازم لكتابتها اعتمادًا كبيرًا على الأدوات المحددة ؛
القضاء على العيوب. معظم الأدوات لا تزال غير جيدة ، ولديها أخطاء ، سيتعين عليك التعامل مع بعض الإصدارات التي تعطل التوافق السابق ، وسوف يستغرق الأمر بعض الوقت لإصلاح كل ذلك أيضًا ؛
التحايل على القيود. قد تحتوي أدوات النظام الأساسي على قيود معمارية أو بعض القيود الأخرى التي يمكنك تشغيلها وقضاء بعض الوقت للتحايل عليها. في بعض الأحيان ، تتحول هذه القيود إلى درجة تجعل المرء يتخلى عن الأداة تمامًا. على سبيل المثال ، ترك Airbnb React Native وتراجع إلى التنمية المحلية ؛
تعقيد التنمية. يجب عليك إما كتابة رمز لنظامي تشغيل في آن واحد ، وهو ما لا يعرفه الجميع ، بالإضافة إلى اتصالات إضافية ستظهر. عدم وجود IDEs الأصلي أيضًا لا يسهل هذا التطور.
لمقارنة تكاليف أساليب التطوير عبر الأنظمة الأساسية التي جربناها ، حددت أربع مجموعات رئيسية:
- نفقات الانطلاق
- تكاليف كتابة التعليمات البرمجية العامة
- تكاليف كتابة رمز النظام الأساسي
- تكاليف البنية التحتية (التي لا تنطبق على النقاط الثلاث الأولى)
أخذ خلط ورق اللعب وقارن الوقت الذي يقضيه فعليًا في تطوير الأنظمة الأساسية والوقت الذي من المفترض أن ننفقه على التنمية المحلية.
كل عمود هو المهمة. في حالة C ++ ، اتضح أنها بداية سهلة إلى حد ما ، ولكن تبين أن تكاليف البنية التحتية كانت كبيرة ، حيث بلغ إجمالي المدخرات 29٪ فقط. تم التخلي عن C ++ أيضًا لأن هذه اللغة خفضت من عامل الأتوبيس: مطورو المحمول لدينا لا يعرفون C ++ ، يمكنهم دعم الكود ، لكن لم يكن لدى أي فرد في الفريق أي تجربة جدية.
الشركات المبتدئة عالية جدًا ، لكن تكاليف رمز النظام الأساسي والبنية التحتية منخفضة للغاية. لم يكن لدينا ما يكفي لتحليل جيد لعدد المهام ، في الموقف الحالي حفظ 19 ٪. على افتراض أننا سنقوم بالكثير من المهام ونتجاهل تكاليف بدء التشغيل ، فسوف نحقق وفورات بنحو 40 ٪ ، ما لم تكن هناك بالطبع مشاكل خطيرة في المستقبل. إضافة أخرى هي أن معظم المطورين على دراية Kotlin.
ناقص واضح - تعقيد العمليات. إما أن نكتب لكلتا المنصتين في وقت واحد ، لكن ليس كلهم يستطيعون ، أو ننتظر حتى يكتب شخص ما الجزء العام ، ثم سنراجعه ، ثم اتضح أنه غير مناسب ، إلخ. إلخ علينا أن نتحمل تكاليف إضافية لمرحلة التصميم ، حتى ينتهي كل شيء على الفور.
المجموع:
- يمكنك ويجب عليك حفظ في عمليات تطوير المحمول وكتابة التعليمات البرمجية. لا تساعد العمليات التي تم إنشاؤها بشكل صحيح في توفير عدد من المهام الإضافية فحسب ، بل حلها أيضًا.
- عند اختيار أدوات لتطوير الأجهزة المحمولة عبر الأنظمة ، فأنت بحاجة إلى تقييم المخاطر وتكاليف العمالة الحقيقية بعناية.