प्रतिक्रियाशील मूल निवासी - सभी समस्याओं के लिए एक चांदी की गोली? कैसे हमने Profi.ru के लिए एक क्रॉस-प्लेटफ़ॉर्म टूल चुना

सभी को मेरा नमस्कार, मेरा नाम गेवॉर्ग है। मैं Profi.ru पर मोबाइल का प्रमुख हूं। मैं आपके साथ रिएक्ट नेटिव के साथ हमारे प्रयोग की कहानी साझा करना चाहता हूं। मैं आपको बताऊंगा कि कैसे हमने रिएक्ट नेटिव पर - सिद्धांत और व्यवहार में विकास के पेशेवरों और विपक्षों का मूल्यांकन किया। लेख उन लोगों के लिए उपयोगी होगा जो क्रॉस-प्लेटफॉर्म मोबाइल विकास में रुचि रखते हैं, लेकिन अभी तक यह तय नहीं किया है कि इस तरह से जाना है या नहीं।

अधिकतम त्वरण

यह सब इस तथ्य से शुरू हुआ कि हमने कंपनी के स्तर पर 10 गुना विकास को गति देने का फैसला किया। हम घटनाओं के सामान्य क्षितिज से परे जाने और नई चीजों की कोशिश करने के लिए एक असंभव लक्ष्य निर्धारित करते हैं। सभी Profi.ru विकास टीमों ने प्रयोग किए। उस समय, कंपनी में 13 देशी मोबाइल डेवलपर्स थे, जिनमें मेरे और दो टीम लीडर शामिल थे। मेरी टीम ने दो मोबाइल ऐप पर काम किया। पहले में, ग्राहक विशेषज्ञों की तलाश में हैं, दूसरे में - ग्राहक विशेषज्ञ। मेरे लिए, यह अवधि अतुलनीय और भावनात्मक रूप से तनावपूर्ण थी। मेरी भावनाओं के अनुसार, हमने इतना कुछ किया कि सब कुछ जल्दी से काम किया।

हमने पूरे प्रोजेक्ट में एक सामान्य आर्किटेक्चर का इस्तेमाल किया और कोड की शुद्धता पर नजर रखी। प्रयुक्त जनरेटर जो सभी मॉड्यूल फ़ाइलों को बनाते हैं। उन्होंने बैकेंड पर सभी व्यापारिक तर्क को बाहर निकालने की कोशिश की। हम CI / CD सेट करते हैं, और E2E परीक्षणों से आच्छादित होते हैं। इस सब के कारण, कुछ अनुप्रयोगों को सप्ताह में एक बार जारी किया गया था। मुझे नहीं पता था कि दो बार भी विकास को कैसे गति दी जाए। 10. अब तक, हमने यह निर्धारित किया कि हमारे लिए क्या महत्वपूर्ण है।

1. एकीकृत कोड आधार। मैं चाहता था कि हमारे सभी मोबाइल डेवलपर्स एक ही कोड लिखें। एक भाषा में, आईओएस और एंड्रॉइड के बीच प्लेटफ़ॉर्म अंतर के बिना। इसलिए हम विकास को आधा कर सकते हैं।
2. नया टूल सीखना आसान है। ताकि टीम का विस्तार करते समय हमें मुकरने या नौकरी पर रखने की समस्या न हो।
3. जल्दी रिलीज। ताकि हम सप्ताह में एक बार नहीं, बल्कि हर दिन रिलीज कर सकें।
4. तुरंत अपडेट। ताकि सभी उपयोगकर्ताओं को तुरंत अपडेट प्राप्त हो। जैसा कि अब वेब डेवलपमेंट में हो रहा है।

एक छोटी समीक्षा के बाद, तीन उम्मीदवार सामने आए: प्रतिक्रिया मूल, स्पंदन, कोटलिन / मूल। न तो स्पंदन और न ही कोटलिन मूल निवासी जल्दी से जारी किया जा सकता है। और हमने इसे सबसे महत्वपूर्ण माना। इसके अलावा, ये प्रौद्योगिकियां उस समय पूरी तरह से कच्ची थीं। हम रिएक्ट नेटिव पर बस गए - यह तुरन्त जारी किया जा सकता है। साथ ही, हमारे अधिकांश डेवलपर्स पहले ही रिएक्ट का उपयोग कर चुके हैं।

सामान्य तौर पर, मैं क्रॉस-प्लेटफ़ॉर्म टूल के बारे में नकारात्मक था - अधिकांश देशी मोबाइल डेवलपर्स की तरह। किसी भी मोबाइल सम्मेलन में जाएं और इसके बारे में बात करें - आप तुरंत पत्थर हो जाएंगे। मुझे यह बात खुद पसंद है :-) इसलिए, आशंकाओं की पुष्टि या खंडन करने के लिए, हमने अपनी जाँच की।

पेशेवरों, जोखिम, और मुद्दे

हमने विभिन्न कंपनियों में रिएक्ट नेटिव का उपयोग करने के उदाहरणों का अध्ययन किया - सफल और इतना अच्छा नहीं। देव के प्रमुख के साथ, बोरे ईगोरोव ने तीन दर्जन से अधिक लेखों और अन्य सामग्रियों को ध्यान से पढ़ा। कुछ ने प्रत्येक अनुच्छेद पर चर्चा की। लेख के अंत में - सबसे दिलचस्प लिंक। हमने उन बिंदुओं को नोट किया जो हमें तेज कर सकते हैं, संभावित जोखिम और प्रश्न। उसके बाद, हमने तीन कंपनियों के डेवलपर्स के साथ बात की। प्रत्येक लोगों में उन्होंने एक बड़े पैमाने पर उत्पाद बनाया और कम से कम एक वर्ष के लिए रिएक्ट नेटिव के साथ काम किया।

पेशेवरों के साथ, सब कुछ बहुत स्पष्ट था।

1. सामान्य कोड आधार।
2. ओवर-द-एयर, या स्टोर को दरकिनार करके अपडेट करें।
3. पहले दो बिंदुओं से यह इस प्रकार है कि उपयोगकर्ताओं को सुविधाओं के वितरण की गति बढ़ जाएगी।
4. वेब डेवलपर्स मोबाइल एप्लिकेशन के लिए कोड लिख सकेंगे। यदि कोई वेब डेवलपर रिएक्ट को अच्छी तरह से जानता है, तो वह तेजी से रिएक्ट नेटिव सीख सकता है। और अगर मोबाइल डेवलपर पहले से ही इस प्लेटफॉर्म को जानता है, तो यह अपेक्षाकृत तेजी से वेब विकास में प्रवेश कर सकता है।

जोखिमों की सूची लंबी थी :-)

पहला जोखिम । एक मंच के बजाय, लंबे समय में हमें तीन का समर्थन करने के लिए मजबूर किया जाता है: एंड्रॉइड, आईओएस और रिएक्ट नेटिव।

कभी-कभी डेवलपर स्क्रीन कुछ इस तरह दिखती है:



हकीकत। हमारे एक वार्ताकार ने मौजूदा कोड में रिएक्ट मूल निवासी को इंजेक्ट किया। हां, एक पूर्ण विकसित तीसरा मंच दिखाई देता है, लेकिन आप मूल विकास से कहीं नहीं जाते हैं। उनकी टीम को प्रतिक्रियाशील मूल निवासी और मूल कोड के बीच राज्य को सिंक्रनाइज़ करना था। इसने कोड / विभिन्न प्रतिमानों और IDEs के विभिन्न टुकड़ों के बीच बहुत से स्विचन किए। इसलिए, उन्होंने स्क्रैच से एक नई परियोजना लिखने का फैसला किया, रिएक्ट नेटिव पर एक फ्रेमवर्क बनाया, और पहले से ही इसमें देशी टुकड़े डालें जहां उन्हें आवश्यकता है। यह बेहतर हो गया।

दूसरा जोखिम। रिएक्टिव नेटिव ब्लैक बॉक्स - कभी-कभी ऐसे हालात होते हैं जब कोई डेवलपर समझ नहीं पाता है कि बग क्यों दिखाई दिया। आपको हर जगह खोजना होगा: रिएक्ट नेटिव कोड में, उत्पाद के मूल भाग में या रिएक्ट नेटिव प्लेटफॉर्म में ही।

हकीकत। जिन लोगों के साथ हमने बात की, उन्होंने लॉग और विभिन्न उपकरणों के साथ एप्लिकेशन को लपेटा: क्रैशलाईटिक्स, किबाना और इतने पर। समस्याएं बनी रहती हैं, लेकिन यह स्पष्ट हो जाता है कि वे कहाँ पैदा होते हैं।

तीसरा जोखिम। यह अक्सर लेखों में पाया गया है कि रिएक्ट नेटिव छोटी परियोजनाओं के लिए उपयुक्त है, लेकिन प्लेटफ़ॉर्म कार्यक्षमता वाले बड़े उत्पादों के लिए नहीं।

हकीकत। हमने इस बात पर ध्यान दिया कि क्या बाजार में बड़ी कंपनियां हैं जो रिएक्ट नेटिव के साथ काम करती हैं। यह पता चला - सैकड़ों नहीं तो दर्जनों हैं। जिसमें स्काइप, टेस्ला, वॉलमार्ट, उबर ईट्स और किचन इन द एरिया शामिल हैं।

चौथा जोखिम। हर बार जब आप अपने ऑपरेटिंग सिस्टम को Apple या Google से अपग्रेड करते हैं, तो प्रोजेक्ट टूट सकता है।

हकीकत। हमने तय किया कि जोखिम पूरी तरह से स्वीकार्य है। देशी विकास के लिए समान जोखिम मौजूद है। जब iOS और Android के लिए नया OS सामने आता है, तो आप अपने एप्लिकेशन को इसके अनुकूल बनाते हैं।

पांचवां जोखिम। एंड्रॉइड में 64-बिट सिस्टम समर्थन नहीं है, और मुद्दा 2015 से खुला है। और अगस्त 2019 से, Google Play ने केवल 32-बिट सिस्टम का समर्थन करने वाले बिल्ड को स्वीकार नहीं किया है।

हकीकत। हमने इस मुद्दे को देखा कि रिएक्ट नेटिव टीम ने 2018 की गर्मियों में काम किया। उन्होंने अगली रिलीज में समर्थन जोड़ने का वादा किया, हालांकि उन्होंने अभी तक 64-बिट सिस्टम के लिए पूरी तरह से तय समर्थन नहीं किया है। इससे बहुत परेशान हुए। बाद में समर्थन जोड़ा गया था, लेकिन कुछ Android डिवाइस संक्रमण के बाद गिर जाते हैं। जैसा कि हमें बाद में पता चला, प्रतिशत बहुत कम है, लेकिन फिर भी यह मेरे लिए सबसे दर्दनाक बिंदु था।

छठा खतरा। संभावना है कि कल, Apple या Google अपने OS का एक नया संस्करण जारी करेंगे और React Native को तोड़ेंगे। या एक नई तकनीक जो Profi.ru, सिद्धांत रूप में, समर्थन करने में सक्षम नहीं होगी।

हकीकत। हमारे लिए या कई अन्य कंपनियों के लिए कोई गारंटी नहीं है। आप या तो जोखिम का एहसास करते हैं और इसे करते हैं, या कुछ और करने की कोशिश करते हैं। हमने ऐसा करने का फैसला किया, और उपलब्ध होने के साथ ही सभी समस्याओं को हल करने के लिए।

सातवां जोखिम। हम पहले से यह नहीं कह सकते थे कि देशी एप्लिकेशन की तुलना में रिएक्ट नेटिव कितनी तेजी से होगा और यह कैसा प्रदर्शन दिखाएगा।

हकीकत। हमारे एक वार्ताकार का शाब्दिक उद्धरण "चर ऊंचाई के तत्वों की सूची है जब स्क्रॉल धीमा हो जाता है।" हमने अभ्यास में जांच करने का फैसला किया। थोड़ा आगे आगे - आवेदन के पहले प्रोटोटाइप को लिखने के समय, हमने इस तरह की समस्या नहीं देखी थी, लेकिन जब हमने एक पूर्ण अनुप्रयोग विकसित किया, तो रिएक्ट नेटिव के प्रदर्शन के बारे में कई सवाल थे।

आठवां जोखिम। यह स्पष्ट नहीं है कि हम कितनी जल्दी रिएक्ट नेटिव डेवलपर्स पा सकते हैं। हेडहंटर पर मुझे लगभग 300 रिज्यूमे मिले, इस तथ्य के बावजूद कि आईओएस के लिए 150 हजार से अधिक डेवलपर्स थे।

हकीकत। वे यहां गहराई में नहीं गए, क्योंकि उन्होंने रिएक्टर डेवलपर्स को एक से अधिक बार काम पर रखा था और जानते थे कि क्या देखना है। हमने फैसला किया कि अंतिम उपाय के रूप में हम रिएक्ट नेटिव में रिएक्ट डेवलपर्स को फिर से प्राप्त कर सकते हैं।

एक जोखिम यह भी था कि कोई टीम को छोड़ देगा, क्योंकि मोबाइल डेवलपर्स को यह तकनीक पसंद नहीं है। वैसे, मैं सही था। किसी ने छोड़ दिया :-(

मैं रिएक्टिव नेटिव लिखने से थक गया हूँ, इसलिए जो निम्नानुसार है वह सिर्फ RN :-)

हम क्या बदलते हैं और क्या नहीं

हमने कंपनी के संस्थापक सर्गेई कुजनेत्सोव और येगोर रुडी के साथ जांच के परिणामों पर चर्चा की और प्रयोग के लिए आगे बढ़ गए।

हमने स्क्रैच से एक नया उत्पाद बनाने का फैसला किया, न कि मौजूदा में डालने के लिए। और यह भी - हमारे क्लाइंट एप्लिकेशन को स्पर्श न करें। यह काफी परिपक्व था, और आर्थिक रूप से इसने कुछ परिवर्तन करने के लिए कोई मतलब नहीं था। इसके अलावा, हमारे लिए यह महत्वपूर्ण था कि आईओएस और एंड्रॉइड दोनों के लिए क्लाइंट एप्लिकेशन का अपना मूल अनुभव था।

लेकिन हम विशेषज्ञों के लिए आवेदन को मौलिक रूप से बदलना चाहते थे। क्लाइंट के विपरीत, हम इस बात से शर्मिंदा नहीं थे कि विशेषज्ञों के पास आईओएस और एंड्रॉइड एप्लिकेशन के लिए समान बातचीत का अनुभव होगा। इसके अलावा, हम मानते हैं कि विशेषज्ञों के लिए एक उत्पाद में हम एनीमेशन और दृश्य प्रभावों के बिना कर सकते हैं। लेकिन इससे पहले कि पूरी टीम एक नई तकनीक पर स्विच करती, यह महसूस करना आवश्यक था कि यह कैसे काम करता है।

कार्रवाई में प्रयोग

दिसंबर 2018 में, हमने तीन लोगों की एक टीम को इकट्ठा किया। दो रिएक्टर डेवलपर्स और एक देशी - मुझे। मैं समझता हूं कि एंड्रॉइड कैसे काम करता है, और IOS विकास में अच्छी तरह से वाकिफ है।

प्रयोग के भाग के रूप में, हम निम्नलिखित बिंदुओं की जाँच करना चाहते थे:

• आरएन में तत्काल रिलीज कैसे काम करती है;
• देशी घटकों और आरएन के बीच बातचीत कैसे होती है;
• क्या हम अपने मूल घटकों का उपयोग कर सकते हैं;
• RN कैमरा, पुश और डिप्लोमा के साथ कैसे काम करता है;
• आरएन में नेविगेशन और राज्य की बचत कैसे काम करती है;
• जहाँ तक हम RN पिक्सेल सही के साथ कर सकते हैं;
• आरएन में स्वचालित परीक्षण कैसे काम करता है;
• कितनी जल्दी मूल निवासी या रिएक्टर डेवलपर तकनीक सीख सकता है।

विकास में गोता लगाने के डेढ़ महीने के भीतर हमें पहला परिणाम मिला।

• मैंने आरएन के तहत सिर्फ दो सप्ताह के बाद कोड लिखना शुरू किया। मेरे लिए, प्रौद्योगिकी पूरी तरह से सीधी थी। हमारे रिएक्ट डेवलपर्स में से एक ने मेरी बहुत मदद की - उन्होंने सामान्य रूप से रिएक्ट / रेडक्स और जेएस के बारे में बात की। रिएक्ट / रेडक्स की पेचीदगियों में प्रवेश करना आवश्यक था, लेकिन थोड़ी देर बाद "न्यूरॉन ने सीखना शुरू किया," जैसा कि वे हमारी कंपनी में कहते हैं :-)
• मुझे सुखद आश्चर्य हुआ कि किसी प्रकार से JS + Flow मजबूत टाइपिंग प्रदान करता है। जेएस के लिए, मुझे बहुत कम उम्मीदें थीं। उसी समय, मैं निश्चित रूप से स्विफ्ट और कोटलिन पसंद करूंगा: मेरे लिए वे जेएस की तुलना में कई गुना अधिक सुंदर और सुखद हैं, लेकिन यहां मुख्य शब्द "मेरे लिए" हैं।
• इसने हमारी मदद की कि टीम में ऐसे डेवलपर शामिल हैं जो iOS, Android और React के लिए कोड लिख सकते हैं। प्रत्येक मंच की अपनी विशिष्ट समस्याएं हैं। उन्हें हल करने के लिए, टीम को क्रॉस-फंक्शनल होना चाहिए।
• तुरंत काम जारी। मेरे लिए यह जादू जैसा है। Apple से रिलीज और अपग्रेड के लिए इंतजार करने की जरूरत नहीं है। चाहता था - लिया और जारी किया।
• बहुत बार परियोजना टूट गई। यह वास्तव में अच्छा नहीं है। आपने शाखा से परिवर्तन लिया, आप दौड़ने की कोशिश करते हैं - और कभी बुरा नहीं मानते। यह बहुत कष्टप्रद था। कुछ बिंदु पर, हमने अभी एक स्क्रिप्ट लिखी है जो परियोजना को पूरी तरह से साफ करती है। यह कहना नहीं है कि उन्होंने समस्या को संपूर्ण रूप से हल किया, लेकिन अधिकांश इसे समाप्त कर दिया।
• फिर भी, हमें तीन प्लेटफार्मों के साथ काम करना होगा, इस तथ्य के बावजूद कि हम मुख्य रूप से आरएन पर कोड लिखते हैं। सभी डेवलपर्स के पास तीन IDE थे: Xcode, Android Studio, WebStorm।
• पुशस, डीपलिंक, कैमरा, नेविगेशन शुरू। लेकिन वे या तो तीसरे पक्ष के पुस्तकालयों की मदद से शुरू करते हैं, या मूल कोड में पुस्तकालयों को स्वयं लिखा जाना चाहिए, और फिर आरएन से जुड़ा होना चाहिए।

लेख के अंत में मैं शीर्षक पर लौटना चाहता हूं। तो क्या आरएन सभी समस्याओं के लिए एक चांदी की गोली है? हमने अपने लिए तय किया कि नहीं। उसी समय, उन्हें वह मिल गया जो वे चाहते थे। हमने कई बार सुविधाओं की डिलीवरी की गति बढ़ाई है और अब हम इसे हर दिन सभी उपयोगकर्ताओं के लिए जारी कर सकते हैं। यह भी महत्वपूर्ण है कि क्रॉस-फंक्शनल टीमें कंपनी में दिखाई दी हैं, जहां प्रत्येक डेवलपर एंड्रॉइड / आईओएस और वेब पर दोनों पर कोड लिखता है।

और हाँ, स्टोर में आवेदन :-)

प्रतिक्रियाशील मूल के बारे में उपयोगी लेख

1. क्यों डिस्क्राइब स्टिकिंग है रिएक्ट नेटिव के साथ - फांगहाओ (रॉबिन) चेन
2. हाउ आई लव्ड एंड हेटेड रिएक्ट नेटिव - एंड्री मेलिखोव
3. मोबाइल डेवलपर के दृष्टिकोण से प्रतिक्रिया मूलक - एंड्री कोन्स्टेंटिनोव
4. इंस्टाग्राम पर रिएक्टिव नेटिव - इंस्टाग्राम इंजीनियरिंग
5. रिएक्टिव नेटिव: उडेसिटी में मोबाइल-इंजीनियरिंग टीम से एक पूर्वव्यापी - नैट ईबेल
6. रिएक्टिव नेटिव: वन-एक्ट फैक्ट बैटल - सामत गैलिमोव
7. सनसेटिंग रिएक्ट नेटिव - गेब्रियल पील