الرد الأم - رصاصة فضية لجميع المشاكل؟ كيف اخترنا أداة عبر منصة ل Profi.ru

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

أقصى تسارع

بدأ كل شيء بحقيقة أننا قررنا تسريع عملية التطوير بمقدار 10 مرات على مستوى الشركة. وضعنا هدفًا مستحيلًا هو تجاوز الأفق المعتاد للأحداث وتجربة أشياء جديدة. أخذت جميع فرق التطوير Profi.ru التجارب. في ذلك الوقت ، كان لدى الشركة 13 مطورًا للهواتف المحمولة ، بمن فيهم أنا وقائدان للفريق. عمل فريقي على تطبيقين للجوال. في البداية ، يبحث العملاء عن متخصصين ، في الثاني - خبراء العملاء. بالنسبة لي ، كانت هذه الفترة غير مفهومة ومرهقة عاطفيا. وفقًا لمشاعري ، فعلنا الكثير حتى يعمل كل شيء بسرعة.

استخدمنا بنية مشتركة طوال المشروع ورصدنا نقاء الكود. المولدات المستخدمة التي تنشئ جميع ملفات الوحدة النمطية. حاولوا إخراج كل منطق الأعمال في الخلفية. قمنا بإعداد CI / CD وتطبيقات مغطاة باختبارات E2E. بسبب كل هذا ، تم إصدار بعض التطبيقات بشكل ثابت مرة واحدة في الأسبوع. لم يكن لدي أي فكرة عن كيفية تسريع التنمية مرتين. إلى حد بعيد في 10. لذلك ، قررنا ما هو مهم بالنسبة لنا.

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

بعد مراجعة قصيرة ، ظهر ثلاثة مرشحين: React Native ، Flutter ، Kotlin / Native. لا يمكن إصدار رفرفة أو Kotlin Native بسرعة. واعتبرنا هذا ربما الأكثر أهمية. بالإضافة إلى ذلك ، كانت هذه التقنيات الخام بالكامل في ذلك الوقت. استقرنا على React Native - يمكن إصداره على الفور. بالإضافة إلى ذلك ، استخدم معظم المطورين برنامج React بالفعل.

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

الايجابيات والمخاطر والقضايا

درسنا أمثلة لاستخدام React Native في شركات مختلفة - ناجحة وغير جيدة. مع Head of Dev ، قرأت Borey Egorov بعناية أكثر من ثلاثين مقالة ومواد أخرى. ناقش البعض كل فقرة. في نهاية المقال - روابط إلى الأكثر إثارة للاهتمام. لاحظنا النقاط التي يمكن أن تسرع لنا ، والمخاطر المحتملة والأسئلة. بعد ذلك ، تحدثنا مع المطورين من ثلاث شركات. في كل من اللاعبين قاموا بإنشاء منتج كبير وعملوا مع React Native لمدة عام على الأقل.

مع الايجابيات ، كان كل شيء واضح جدا.

1. قاعدة الكود العام.
2. الإفراط في الهواء ، أو التحديث عن طريق الجو ، وتجاوز المتجر.
3. من النقطتين الأوليين ، ستزداد سرعة تسليم الميزات للمستخدمين.
4. سيتمكن مطورو الويب من كتابة التعليمات البرمجية للتطبيقات المحمولة. إذا كان مطور الويب يعرف React جيدًا ، فيمكنه تعلم React Native بسرعة. وإذا كان مطور الهاتف المحمول يعرف بالفعل هذه المنصة ، فيمكنه الدخول في تطوير الويب بسرعة نسبية.

قائمة المخاطر كانت أطول :-)

الخطر الأول . بدلاً من نظام أساسي واحد ، على المدى الطويل ، نحن مضطرون لدعم ثلاثة: Android و iOS و React Native.

في بعض الأحيان تبدو شاشة المطور مثل هذا:



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

الخطر الثاني. React Native Black Box - في بعض الأحيان تكون هناك مواقف عندما لا يفهم المطور سبب ظهور خطأ. يجب عليك البحث في كل مكان: في React Native code ، في الجزء الأصلي من المنتج أو في React Native platform نفسها.

حقيقة واقعة. لف الرجال الذين تحدثنا معهم التطبيق بالسجلات والأدوات المختلفة: Crashlytics و Kibana وما إلى ذلك. تبقى المشاكل قائمة ، لكن يصبح من الواضح أين تنشأ.

الخطر الثالث. غالبًا ما يوجد في المقالات أن React Native مناسبة للمشروعات الصغيرة ، ولكن ليس للمنتجات الكبيرة مع وظائف النظام الأساسي.

حقيقة واقعة. نظرنا إلى ما إذا كانت هناك شركات كبيرة في السوق تعمل مع React Native. اتضح - هناك العشرات ، إن لم يكن المئات. بما في ذلك Skype و Tesla و Walmart و Uber Eats ومطبخ في المنطقة.

الخطر الرابع. في كل مرة تقوم فيها بترقية نظام التشغيل الخاص بك من Apple أو Google ، قد يتوقف المشروع.

حقيقة واقعة. قررنا أن الخطر كان مقبولا تماما. نفس الخطر موجود للتنمية المحلية. عندما يخرج نظام التشغيل الجديد لنظام التشغيل iOS و Android ، يمكنك تكييف تطبيقك عليه.

الخطر الخامس. لا يوجد دعم لنظام 64 بت في نظام Android ، والمشكلة مفتوحة منذ عام 2015. ومنذ أغسطس 2019 ، لم تقبل Google Play عمليات الإنشاء التي تدعم أنظمة 32 بت فقط.

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

الخطر السادس. احتمالية أن تطلق Apple أو Google غدًا إصدارًا جديدًا من نظام التشغيل وتنتهي من React Native. أو تقنية جديدة لن يتمكن Profi.ru من حيث المبدأ من دعمها.

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

الخطر السابع. لم نتمكن من تحديد مقدماً مدى سرعة مقارنة React Native بالتطبيق الأصلي والأداء الذي سيظهره.

حقيقة واقعة. الاقتباس الحرفي لأحد محاورينا هو "قوائم عناصر الارتفاع المتغير عند التمرير البطيء." قررنا أن تحقق في الممارسة. إلى الأمام قليلاً - في وقت كتابة النموذج الأولي للتطبيق ، لم نر مثل هذه المشكلة ، لكن عندما قمنا بتطوير تطبيق كامل ، كان هناك العديد من الأسئلة حول أداء React Native.

الخطر الثامن. ليس من الواضح مدى سرعة العثور على مطوري React Native. على HeadHunter ، وجدت حوالي 300 سيرة ذاتية ، على الرغم من وجود أكثر من 150 ألف مطور لنظام iOS.

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

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

لقد سئمت من كتابة React Native ، فما يلي هو RN فقط :-)

ما نغير وما لا

ناقشنا نتائج التحقيق مع مؤسسي الشركة ، سيرجي كوزنتسوف ويغور رودي ، وحققنا نتائج التجربة.

قررنا إنشاء منتج جديد من البداية ، وليس لإدراجه في منتج حالي. وأيضا - لا تلمس تطبيق عملائنا. لقد كانت ناضجة للغاية ، ومن الناحية الاقتصادية ، لم يكن من المنطقي تغيير شيء جذري. بالإضافة إلى ذلك ، كان من المهم بالنسبة لنا أن يتمتع تطبيق العميل بتجربته الأصلية لكل من iOS و Android.

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

تجربة في العمل

في ديسمبر 2018 ، قمنا بتجميع فريق من ثلاثة أشخاص. اثنين من المطورين React واحد الأصلي - لي. أفهم كيف يعمل Android ، وأنا على دراية جيدة بتطوير iOS.

كجزء من التجربة ، أردنا التحقق من النقاط التالية:

• كيف تعمل الإصدارات الفورية في RN ؛
• كيف يتم التفاعل بين المكونات الأصلية و RN ؛
• هل يمكننا استخدام مكوناتنا الأصلية؟
• كيف يعمل RN مع الكاميرا والدفع والشهادة ؛
• كيف الملاحة وحفظ الدولة العمل في RN ؛
• بقدر ما يمكننا القيام به مع RN بكسل الكمال ؛
• كيف يعمل الاختبار التلقائي في RN ؛
• مدى سرعة المطور الأصلي أو React يستطيع تعلم التكنولوجيا.

حصلنا على النتائج الأولى في غضون شهر ونصف بعد الغوص في التنمية.

• لقد بدأت كتابة التعليمات البرمجية تحت RN بعد أسبوعين فقط. بالنسبة لي ، كانت التكنولوجيا غير معقدة تماما. ساعدني أحد مطوري React لدينا كثيرًا - تحدث عن مشاهير React / Redux و JS بشكل عام. كان من الضروري إدخال تعقيدات React / Redux ، لكن بعد فترة من الوقت بدأت "العصبونات في التعلم" ، كما تقول شركتنا :-)
• لقد فوجئت بسرور بأن JS + Flow في شكل ما يوفر طباعة قوية. بالنسبة إلى JS ، كان لدي توقعات أقل بكثير. في الوقت نفسه ، سأفضل بالتأكيد Swift و Kotlin: بالنسبة لي فهي أجمل كثيرًا وأكثر متعة من JS ، ولكن الكلمات الرئيسية هنا هي "بالنسبة لي".
• لقد ساعدنا ذلك على أن يضم الفريق مطورين يمكنهم كتابة التعليمات البرمجية لنظامي التشغيل iOS و Android و React. كل منصة لها مشاكلها الخاصة. لحلها ، يجب أن يكون الفريق متعدد الوظائف.
• النشرات الفورية العمل. بالنسبة لي هو مثل السحر. لا حاجة لانتظار الإصدارات والترقيات من Apple. مطلوب - أخذ وأفرج عنه.
• في كثير من الأحيان المشروع انهار. هذا حقا ليس باردا. لقد أخذت التغييرات من الفرع ، وحاولت الركض - ولا تمانع. كان مزعج جدا. في مرحلة ما ، كتبنا للتو برنامج نصي ينظف المشروع بالكامل. هذا لا يعني أنهم حلوا المشكلة ككل ، لكنهم انتهوا من معظمها.
• ومع ذلك ، يتعين علينا العمل مع ثلاث منصات ، على الرغم من حقيقة أننا نكتب رمزًا بشكل أساسي على RN. كان لدى جميع المطورين ثلاثة معرفات: Xcode ، و Android Studio ، و WebStorm.
• Pushas ، deeplinks ، الكاميرا ، بداية الملاحة. لكنها تبدأ إما بمساعدة مكتبات الطرف الثالث ، أو يجب أن تدون المكتبات في الكود الأصلي بنفسك ، ثم تتصل بـ RN.

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

ونعم ، التطبيقات في المتجر :-)

مقالات مفيدة حول React Native

1. لماذا الخلاف يتمسك مع رد الفعل الأصلي - فانغهاو (روبن) تشن
2. كيف أحببت وأكره رد فعل السكان الأصليين - أندريه مليخوف
3. الرد الأم من وجهة نظر المطور المحمول - أندريه كونستانتينوف
4. الرد الأصلي في Instagram - هندسة Instagram
5. React Native: A بأثر رجعي من فريق الهندسة المتنقلة في Udacity - Nate Ebel
6. رد فعل أصلي: معارك حقيقة واحدة - سامات غالموف
7. غروب الشمس رد فعل الأم - غابرييل بيل