मोबाइल क्रॉस-प्लेटफॉर्म विकास पर बचत: स्काईेंग केस स्टडी

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

• एक टीम में iOS और Android डेवलपर्स को मिलाकर
• जटिल समस्याओं को हल करने के लिए कार्य समूहों का निर्माण
• प्रलेखन पर बचत
• कॉमन कोड लिखना

मुझे इसके बारे में कई रिपोर्ट बनाने का अवसर मिला; इस लेख में, मैंने मुख्य टिप्पणियों और परिणामों को एकत्र किया है।

एक टीम में iOS और Android डेवलपर्स को मिलाकर

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

इनमें से एक प्रक्रिया एक तकनीकी समीक्षा बन गई है।

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

हम संयुक्त तकनीकी समीक्षा कैसे बचाते हैं:

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

बस कारक: टीम में लोगों की संख्या जो बस को नीचे लाना चाहिए ताकि परियोजना जारी न रह सके।

जटिल समस्याओं के समाधान के लिए कार्यदल

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

मैंने कोड लेखन, संचार, डिजाइन और अनुसंधान पर खर्च किए गए समय के वितरण के संबंध में कार्य-विवरणों का विश्लेषण किया। यहाँ सरल कार्यों के लिए क्या होता है:

यहां सब कुछ स्पष्ट है, मूल रूप से हम कोड लिखते हैं, इसकी लागत 80% तक होती है।

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

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

अंत में, जिन कार्यों के साथ यह आमतौर पर स्पष्ट नहीं है कि कैसे दृष्टिकोण करना है, जहां आपको पहले अनुसंधान और डिजाइन करना होगा:

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

मुझे एक रास्ता मिल गया: मैंने बस इन सभी कार्यों को अपने ऊपर ले लिया और बंद कर दिया। मैं समय बचाने में कामयाब रहा, लेकिन मैं लगातार अतिभारित हो गया, मेरे पास कम-प्राथमिकता वाले कार्यों पर ध्यान देने के लिए पर्याप्त समय नहीं था, डेवलपर्स को मेरे लिए इंतजार करना पड़ा, सब कुछ खराब था। समस्या फिर से पैदा हुई, और हमने पहले से ही काम करने वाले समूह बनाकर इसे हल किया।

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

परिणामस्वरूप, हमने प्राप्त किया:

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

प्रलेखन पर सहेजें

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

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

अंत में, डॉकिंग की यह शैली एक नए डेवलपर की ऑनबोर्डिंग में मदद करती है: कोड के साथ मिलकर, उसे सभी संभव कोड शैली, कन्वेंशन, एप्लिकेशन असेंबली निर्देश प्राप्त होते हैं, और टीम में प्रवेश करना बहुत आसान है।

आम कोड

कॉमन कोड लिखने का विचार सबसे नया नहीं है; ऐसा करने के लिए उपकरणों का एक समूह है। हमने शब्दावली लाइब्रेरी लिखने के लिए C ++ की कोशिश की, और हमारे पास पूरी तरह से Kotlin Multiplatform में लिखा गया एक छोटा अनुप्रयोग है। सैद्धांतिक रूप से, एक क्रॉस-प्लेटफॉर्म डेवलपमेंट टूल का उपयोग करते समय, हमारे कोड लिखने की लागत को आधा किया जाना चाहिए। लेकिन अतिरिक्त दिखाई देते हैं:

• स्टार्टअप की लागत। एक टीम को इकट्ठा करने, लॉन्च करने, परीक्षण करने, परीक्षण करने, परिकल्पना करने और प्रशिक्षण के लिए बहुत समय देना होगा। कुछ मामलों में, ये लागत इतनी बड़ी है कि लाभ बिल्कुल दिखाई नहीं देता है;

  
  

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

  
  

• दोषों का उन्मूलन। अधिकांश उपकरण अभी भी बहुत कच्चे हैं, उनके पास कीड़े हैं, आपको कुछ रिलीज से निपटना होगा जो पिछड़े संगतता को तोड़ते हैं, और यह सब भी ठीक करने में कुछ समय लगेगा;

  
  

• प्रतिबंधों की परिधि। क्रॉस-प्लेटफ़ॉर्म टूल में वास्तुशिल्प या कुछ अन्य प्रतिबंध हो सकते हैं जिन्हें आप चला सकते हैं और उन्हें दरकिनार करने के लिए समय बिता सकते हैं। कभी-कभी ऐसे प्रतिबंध इतने गंभीर हो जाते हैं कि व्यक्ति को पूरी तरह से उपकरण को छोड़ना पड़ता है। उदाहरण के लिए, Airbnb ने प्रतिक्रियाशील मूल को त्याग दिया और मूल विकास में वापस आ गया;

  
  

• विकास की जटिलता। आपको या तो एक साथ दो प्लेटफार्मों के लिए कोड लिखना होगा, जो हर कोई नहीं जानता है, साथ ही अतिरिक्त संचार दिखाई देंगे। देशी आईडीई की कमी भी इस विकास को सरल नहीं बनाती है।

  
  

क्रॉस-प्लेटफ़ॉर्म विकास विधियों की लागतों की तुलना करने के लिए जो हमने कोशिश की, मैंने चार मुख्य समूहों की पहचान की:

• खर्च शुरू करना
• सामान्य कोड लेखन लागत
• मंच कोड लेखन लागत
• बुनियादी ढांचे की लागत (जो पहले तीन बिंदुओं पर लागू नहीं होती है)

उन्होंने फेरबदल किया और वास्तव में क्रॉस-प्लेटफ़ॉर्म विकास पर खर्च किए गए समय की तुलना की और उस समय की, जो हम मूल विकास पर खर्च करेंगे।

प्रत्येक स्तंभ कार्य है। सी ++ के मामले में, यह काफी आसान शुरुआत थी, लेकिन बुनियादी ढांचे की लागत महत्वपूर्ण थी, कुल बचत - केवल 29%। C ++ को भी छोड़ दिया गया क्योंकि इस भाषा ने बस कारक को कम कर दिया: हमारे मोबाइल डेवलपर्स C ++ को नहीं जानते हैं, वे कोड का समर्थन कर सकते हैं, लेकिन टीम में किसी को भी कोई गंभीर अनुभव नहीं था।

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

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

कुल:

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