"" लोगों के लिए एक आवेदन करें "- यह घुटने पर नहीं लगाया जाना है:" सीएफटी में मोबाइल विकास के बारे में

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

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

पाठ इतना विस्तारित हो गया कि हमने सामग्री की एक तालिका भी बना दी ताकि किसी विशिष्ट भाग में जाना आसान हो जाए:

• इसमें कंपनी और मोबाइल के विकास के बारे में बताया गया है
• मोबाइल टीम की ग्रोथ
• आंतरिक विकास के खिलाफ तीसरे पक्ष के समाधान
• स्विफ्ट और कोटलिन

कंपनी के बारे में

JUG.ru समूह: परिचयात्मक प्रश्न: हमें कंपनी के बारे में बताएं और आप व्यक्तिगत रूप से इसमें क्या करते हैं।

किरिल : संक्षेप में यह बताना असंभव है, क्योंकि सीएफटी व्यावसायिक क्षेत्र बहुत विविध हैं। लेकिन सबसे लोकप्रिय उत्पादों और सेवाओं के बारे में "बड़े स्पर्श" का प्रयास करें।

सीएफटी तीसरे दशक के लिए रूसी फिनटेक बाजार में काम कर रहा है, और हम कहते हैं कि हमने फिनटेक किया जब ऐसी अवधारणा मौजूद नहीं थी।

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

यह गोल्डन क्राउन इकोसिस्टम है, जिसमें बी 2 सी और बी 2 बी प्रारूप की सेवाओं का एक पूल शामिल है: ऑनलाइन मुद्रा विनिमय, नकद और ऑनलाइन मनी ट्रांसफर, ऋण चुकौती, वफादारी कार्यक्रम, परिवहन और सामाजिक कार्ड।

प्रसंस्करण केंद्र "कार्टस्टैंडार्ट": भुगतान प्रणाली मास्टरकार्ड, वीज़ा और "मीर" के कार्ड प्राप्त करना और प्राप्त करना।

फ़ेडरल सिस्टम "सिटी" हजारों किन्नरों को कई तरह की सेवाएँ देता है: किंडरगार्टन और उपयोगिताओं का भुगतान करने से लेकर कर भुगतान करने और परिवहन कार्डों की भरपाई करने तक।

Faktura.ru ऑनलाइन बैंकिंग सेवाओं का उपयोग 130 से अधिक बैंकों द्वारा किया जाता है। CFT स्वचालित बैंकिंग प्रणाली और भी विभिन्न संगठनों द्वारा उपयोग की जाती है।

CFT बड़े R & D, ML और AI डिवीजनों को नियुक्त करता है, जिन्हें कंपनी के लगभग सभी क्षेत्रों में एकीकृत किया जाता है। हमारे पास एक शक्तिशाली सूचना सुरक्षा टीम है। सामान्य तौर पर, ये 3,000 से अधिक लोग हैं जो पिछले 26 वर्षों से फिनटेक कार्यों को सुलझाने में व्यस्त हैं।

"युवा" सीएफटी उत्पादों में से एक सेवा "गोल्डन क्राउन - मनी ट्रांसफर" (जो पहले से ही 16 साल पुरानी है) पर आधारित है - यह "मनी ट्रांसफर ऑनलाइन", एक दिशा है जिसे हमने 2016 में लॉन्च किया था। और आज यह CFT में मोबाइल विकास का एक लोकोमोटिव है: कुल मिलाकर, 70 लोग इस पर iOS और Android में काम करते हैं। और यह संख्या लगातार बढ़ रही है, हम वर्ष के अंत तक सैकड़ों तक बढ़ने की योजना बनाते हैं।

"प्रीपेड कार्ड" डिवीजनों में मोबाइल दिशा-निर्देश भी हैं (वे कार्ड के लिए समाधान विकसित कर रहे हैं "कॉर्न", "बीलाइन", "कारी", आदि), Faktura.ru में, सिस्टम "सिटी"।

और मीशा और मैं सिर्फ टीम के विकास, विस्तार और विकास प्रक्रियाओं से परिचय कराने के लिए "ऑनलाइन मनी ट्रांसफर" डिवीजन में हैं। प्रारंभ में, हमने "प्रीपेड कार्ड" निदेशालय में काम किया, टीमें छोटी थीं, प्लेटफ़ॉर्म थीं, और हम उन अवधारणाओं में रहते थे जो 2014-2015 में थे।

मिखाइल : जब सभी एक ही कार्यालय में बैठे होते हैं, तो वे काम करते हैं, संवाद करते हैं।

किरिल : 10-15 लोगों के लिए इस तरह की छोटी गर्म और दीपक टीमें, सब कुछ ध्यान में रखते हुए - परीक्षण और बैकएंड दोनों। और अब हमारे सामने नई चुनौतियां हैं।

माइकल : हाँ, 10 डेवलपर्स के काम को व्यवस्थित करना एक बात है, और 50 एक और है। इसमें टीम के विकास, स्केलिंग, इसके पेशेवर विकास और स्वयं प्रोजेक्ट के लिए सभी प्रक्रियाएं शामिल हैं: यदि हमारे इंजीनियर तकनीकी समस्याओं को हल करते हैं, तो हम प्रोजेक्ट आर्किटेक्चर के विकास में लगे हुए हैं। हम उन समस्याओं की तलाश कर रहे हैं जो इस परियोजना के स्केलिंग में हस्तक्षेप करेंगे, और उन्हें हर तरह से हल करने का प्रयास करेंगे।

JUG.ru समूह: हम विकास के मुद्दों पर वापस आएंगे, लेकिन अब मुझे यह बताएं: CFT में मोबाइल विकास अन्य कंपनियों से अलग कैसे है, और क्या समान है? आपको उन लोगों के बारे में जानने की जरूरत है जिन्होंने कभी फिनटेक में काम नहीं किया है। क्या आपको साक्षात्कार के चरण में पहले से ही किसी विशेष ज्ञान की आवश्यकता है?

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

हम हमेशा बताते हैं कि हमारे मामले में मोबाइल विकास बिल्कुल किसी भी उत्पाद के विकास के समान है। फिनटेक जीवन के तरीके का वर्णन करने के लिए एक शब्द नहीं है, लेकिन बस काम की एक पंक्ति है, कुछ ऐसा जो हम हर दिन सामना करते हैं।

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

बेशक, हमें प्राथमिक स्तर पर न्यूनतम ज्ञान की आवश्यकता है: बैंक कार्ड कैसा दिखता है, बैंक खाता क्या है। लेकिन अगर गहन ज्ञान है, तो यह विश्लेषकों की इच्छाओं को समझने में आसान और तेज़ बनाता है। ऐसे डेवलपर हैं जो न केवल "कार्य कैसे करें", बल्कि "क्यों" भी समझना चाहते हैं।

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

सूचना सुरक्षा के दृष्टिकोण से कुछ बिंदु हैं, यह समझ में आता है: फिनटेक सुरक्षा के बारे में है। लेकिन मैं यह नहीं कह सकता कि मोबाइल डेवलपर्स रक्षा की पहली पंक्ति हैं। फिर भी, फिनटेक उत्पादों को इस तरह से डिज़ाइन किया गया है कि बैकएंड और डेटा स्टोरेज साइड पर सुरक्षित रहें।

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

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



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

यह समझना महत्वपूर्ण है कि हम सिर्फ उबाऊ डिब्बे नहीं देख रहे हैं, बल्कि तकनीकी पक्ष सहित हमारे चेहरे को ग्राहकों की ओर मोड़ने की कोशिश कर रहे हैं। इसलिए, हम हमेशा संपर्क रहित भुगतान जैसे नवाचारों के लिए हैं।

2018 में हमारे iOS "बैंकों" ने दैनिक बैंकिंग श्रेणी में मार्कस्वेब रैंकिंग में 4 वें और 5 वें स्थान पर ले लिया।

हम एक ऐसा अनुप्रयोग बनाने की कोशिश कर रहे हैं जो "माँ को दिखाने में शर्म नहीं करता है", जिसका उपयोग स्मार्टफोन से दूर रहने वाले लोग कर सकते हैं, और जो लोग प्रौद्योगिकी के बारे में बहुत कुछ समझते हैं। कुछ मोबाइल बैंक सफल क्यों हैं और कुछ नहीं? क्योंकि वे तकनीकी रूप से बनाए गए हैं, एनीमेशन के साथ, शायद कुछ प्रकार के सांस्कृतिक संदर्भों के साथ भी।

माइकल : मैं संक्षेप में यह जोड़ना चाहता हूं कि हम वास्तव में ग्राहकों - सड़कों पर चलने वाले लोगों पर केंद्रित हैं। चूंकि हम पैसे के साथ संचालन करते हैं, इसलिए हम उन्हें लोगों के लिए जितना संभव हो उतना आसान बनाने का प्रयास करते हैं।

उसी समय, जब कर्मचारी हमारे पास आते हैं, तो उन्हें यह समझने की आवश्यकता होती है कि वास्तव में "लोगों के लिए क्या करें" अपने घुटनों पर "जैसा कि मैं देखता हूं" को स्क्रिबल नहीं करना है। CFT में काम करने से पहले, मैंने डिज़ाइन के बिना लगभग सभी डिज़ाइन और UX खुद ही किए। लेकिन कंपनी उस तरह से हमारे लिए काम नहीं करती है। डिजाइनरों के साथ एक संपूर्ण यूएक्स प्रयोगशाला है जो प्रयोगों का संचालन करते हैं, और फोकस समूह हैं जो परिकल्पना का परीक्षण करते हैं।

और जब कोई व्यक्ति हमारे पास आता है, तो उसे समझना चाहिए कि उत्पाद का उपयोग करने के लिए क्लाइंट के लिए सब कुछ आसान बनाने पर ध्यान केंद्रित किया जाएगा, ताकि 50 क्षेत्रों का फॉर्म भरते समय मृत्यु न हो। काम अंतिम उपयोगकर्ता की जरूरतों पर केंद्रित है।

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

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

जब कोई व्यक्ति हमारी टीम में आता है, तो उसे आधुनिक तकनीक के ढेर को समझने और उसे नेविगेट करने में सक्षम होने के लिए तैयार होना चाहिए। हम इसका स्वागत करते हैं। यह, शायद, यहां तक ​​कि एक विरोधाभास है: एक व्यक्ति फिनटेक में जाता है, बैंकिंग विकास के लिए, रूढ़िवाद की उम्मीद करता है, और उसे यह जानना आवश्यक है कि आरएक्स और कोटलिन सभी अच्छाइयों के साथ कैसे काम करते हैं। यह, यह मुझे लगता है, एक अनूठी विशेषता है।

मोबाइल टीम की ग्रोथ

JUG.ru समूह: आपने पहले ही कहा था कि आप टीम की वृद्धि के साथ आने वाली समस्याओं को हल कर रहे हैं। क्या कोई ठोस उदाहरण है?

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

हमने देखा कि समीक्षकों की संख्या में जैविक वृद्धि के साथ, 5-6 दिनों के लिए पहले से ही अनुरोधों को खींचना शुरू हो गया। यह एक समस्या थी: हम समय पर व्यापार को सुविधाएँ नहीं दे सकते थे।

गिट प्रवाह के साथ एक समस्या भी थी: यदि आप एक शाखा में बैठते हैं और लंबे समय तक देखते हैं, तो उस समय दूसरी टीम भी अन्य शाखाओं में 2-4 विशेषताएं देख सकती है, और फिर यह सब रिलीज की तारीखों से शाखाओं में जमे हुए हैं, हमें मर्ज संघर्ष के रूप में दर्द मिलता है।

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

समीक्षा के साथ समस्या थी। पहले, लगभग 4-5 लोगों ने हमारे साथ भाग लिया था, क्योंकि कोड की गुणवत्ता हमारे लिए महत्वपूर्ण है, हमारे पास गुणवत्ता के लिए काफी सख्त सिद्धांत और दृष्टिकोण हैं। हमें डर था कि अगर हम समीक्षकों की संख्या कम कर देते हैं, तो हमारी गुणवत्ता बिगड़ जाएगी। इस मामले में, 50 डेवलपर्स के लिए, उदाहरण के लिए, 30 गुणवत्ता की समीक्षा करते हैं, और बाकी कनिष्ठ डेवलपर्स या मध्य वाले हैं जिन्होंने अभी तक एक वास्तविक कौशल विकसित नहीं किया है।

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

लेकिन हम दूसरी समस्या में भाग गए। यदि कोई डेवलपर लगातार अपना लीड करता है और दूसरी टीम से पड़ोसी लीड लेता है, तो लीड ओवरलोड हो जाते हैं। वे विकास में कम शामिल हैं और समीक्षा पर अधिक समय बिताते हैं। यदि आप गुणात्मक रूप से संपर्क करते हैं तो लगभग 20 पुल अनुरोध गंभीर कार्य हैं।

और हम और भी आगे बढ़ गए। उन्होंने समीक्षकों के लिए तीन स्लॉट छोड़ दिए, एक ही भूमिका (टेक टीम, वरिष्ठ डेवलपर, और किसी भी अन्य) को छोड़ दिया, लेकिन परेशान नहीं किया कि यह आपकी टीम के लोग हों। और अब हमारे पास एक-डेढ़, अधिकतम डेढ़ दिन में होने वाले पुल-अनुरोध हैं। और अधिक लंबी कहानियाँ नहीं।

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

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

किरिल : हां, कंपनी के बारे में सवाल पर लौटते हुए: इस तथ्य के अलावा कि हमारे पास 3,000 से अधिक कर्मचारी हैं, हमारे विकास केंद्र तीन शहरों (टॉम्स्क, नोवोसिबिर्स्क और सेंट पीटर्सबर्ग) में स्थित हैं, और मोबाइल टीमों को उनके बीच वितरित किया जाता है। यह थोड़ा जटिल है कि चार घंटे का अंतराल है, लेकिन कंपनी का कुल कार्य दिवस 12 घंटे तक बढ़ा दिया गया है।

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

JUG.ru समूह: जब कोई टीम बढ़ती है, तो कोई भी डेवलपर पहले से ही पूरे कोड आधार को नहीं जान सकता है या पास में बैठे किसी व्यक्ति से कुछ भी स्पष्ट करना आसान है। इस मामले में, शायद, एक और चुनौती पैदा होती है: रिकॉर्ड रखना?

किरिल: यहां यह कहने योग्य है: जब हमने 10 बार टीम के विकास की योजना बनाई, तो हमने महसूस किया कि हमने 10 गुना अधिक सुविधाएँ (या यहां तक ​​कि 7 बार) जारी नहीं की हैं। इस तरह की वृद्धि के साथ, गुणवत्ता के पिछले स्तर को बनाए रखने के लिए, अतिरिक्त प्रयासों की आवश्यकता होती है। और नए डेवलपर्स के लिए एक अभ्यास कुछ करने के लिए शुरू करने से पहले सिर्फ दस्तावेज लिख रहा था।

इस प्रकार, कुछ ही समय में हमने प्रलेखन में आवेदन के प्रमुख घटकों को शामिल किया। और उन्होंने इस तरह के घटकों में जोंस को छोड़ना शुरू कर दिया, क्योंकि इस तरह के प्रलेखन के साथ कोड की समीक्षा और परीक्षण को वहन करना पहले से ही संभव है। यह एक "विलंबित निकास" ज़ूम था।

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

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

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

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

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

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

हमारे पास प्लेटफ़ॉर्म डॉक्यूमेंटेशन (एंड्रॉइड और आईओएस के लिए) है, और इसमें प्रोजेक्ट्स (व्यावसायिक परिदृश्य और पसंद) हैं।

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

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

आंतरिक विकास के खिलाफ तीसरे पक्ष के पुस्तकालय

JUG.ru ग्रुप: मैं iOS और Android के संदर्भ में "इनर किचन" के बारे में कुछ और बात करना चाहूंगा। जहां तक ​​हम समझते हैं, आपके पास आईओएस पर तीसरे पक्ष के समाधानों को अस्वीकार करने की नीति है, लेकिन एंड्रॉइड ने शुरू में खुद को सब कुछ लिखने की कोशिश की, लेकिन फिर इसे छोड़ दिया। क्यों?

माइकल : एंड्रॉइड ऐतिहासिक रूप से इस तरह से रहा है। 2013 में, जब हम कुकरूजा कार्ड के लिए एक मोबाइल बैंक बना रहे थे, एंड्रॉइड डेवलपमेंट में आर्किटेक्चर और लाइब्रेरी के लिए लगभग कोई मानक नहीं थे। यहां तक ​​कि Google को खुद भी समझ नहीं आया कि उसे एंड्रॉइड कहां विकसित करना चाहिए। हमने तब विकास शुरू किया था जब कोई एंड्रॉइड 5 नहीं था, हमारे पास अधिकतम संस्करण के रूप में किटकैट 4.4 था।

चूंकि पुस्तकालय नहीं हैं, इसलिए हम स्वयं लिखते हैं। , , . : , HTTP- Volley , API- Retrofit ( ). , . , . Dagger , , Retrofit, «», .
- , , , - . Volley . , , - .

, - . , , Rx , . , . . . , - .

, : «, , », : «- - , », .

, , , -. Kotlin, - 1.0 . , best practices . .

« » « », . , -. .

, : , - , , . , , , , , - . , . , -, .

: iOS, , . . - — , . - AFNetworking, — 40-50 ( ). .

Mobius ( ): third-party . , , , , . , , .



— , SSL- , - , .
, , . , ReactiveCocoa, 4-5 . -, , -, , ? , Swift, .

, , , . Android Dagger , , Google. Apple - , . , Swift, , , Swift.

6 , 2011 . 6-8 : , ? , , — SnapKit ( ) , , — , -, . , , .

— . , , , , , , .

: iOS Swift. — , , , . UI-, , -.

Swift — , Objective-C , . , , , , , , …

3 « » VIPER -, : «, MVP, VIPER». MVP- - . , , .

Swift Kotlin

JUG.ru समूह: माइकल ने @mobileunderhood में लिखा है, "हम जावा को पूरी तरह से छोड़ रहे हैं, हम सब कुछ कोटलिन पर लिख रहे हैं।" आमतौर पर, यहां तक ​​कि जब कोटलिन में नया कोड पहले से ही लिखा जाता है, तो जावा में मौजूदा को बहुत धीरे-धीरे बदल दिया जाता है, और यह कई और वर्षों तक उत्पादन में बना रह सकता है। आपने इसे अधिक सक्रिय रूप से करने का निर्णय क्यों लिया? और क्या आप iOS में सक्रिय रूप से ऑब्जेक्टिव-सी कोड से छुटकारा पा लेते हैं?

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

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

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

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

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

किसी का खास विरोध नहीं हुआ। कुछ संदेह था "कोटलिन सिर्फ प्रचार है", लेकिन यह वास्तव में हमारी मदद करता है जब Google ने एंड्रॉइड विकास के लिए आधिकारिक तौर पर कोटलिन को मान्यता दी थी, हमारे लिए यह सिर्फ एक बम था। इंजीनियरों को समझाने के लिए यह आवश्यक नहीं था: या तो आप सभी आधुनिक डेवलपर्स की लहर पर हैं, या इस बाजार के बाहर।

किरिल : और स्विफ्ट के साथ, पहली बैठक इस तरह से थी: मुझे नोवोसिबिर्स्क में हमारे एक सम्मेलन के लिए एक छोटी सी प्रस्तुति देने की जरूरत थी, और जब मैंने ऑब्जेक्टिव-सी में स्क्रीन पर कोड का एक टुकड़ा लाया, तो यह स्पष्ट हो गया कि इसे किसी भी स्क्रीन आकार में नहीं पढ़ा जा सकता है। और फिर मैंने स्विफ्ट में प्रस्तुति के लिए उस कोड ऑफ़ कोड को लिखा, हालाँकि प्रोजेक्ट में एक भी "स्विफ्ट" लाइन नहीं थी।

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

और अगर आप हमारे पास अभी आए पुल अनुरोधों को देखते हैं, तो स्विफ्ट कोड का 95% वहां लिखा जाता है। हमारे पास किसी भी कीमत पर उद्देश्य-सी से स्विफ्ट तक सभी उपलब्ध कोड को स्थानांतरित करने का एक सुपर काम नहीं है। फिर भी, मनी ट्रांसफर मोबाइल एप्लिकेशन में स्विफ्ट कोड का हिस्सा 60-65% है, हम "स्विफ्ट डाइजेस्ट" जारी करते हैं, जिसमें हम स्विफ्ट / ऑब्जेक्टिव-सी फाइलों के लिए, कोड की लाइनों के लिए, और रिलीज और तारीख के आधार पर एक ग्राफ बनाते हैं। सब कुछ दिख रहा है। 65% शेयर का मतलब यह नहीं है कि हमने 10 में से 6 फाइलों को कॉपी किया - मुख्य रूप से नई फाइलों के कारण वृद्धि।

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

चूंकि गोल्डन क्राउन के लिए उत्पाद - मनी ट्रांसफर सेवा केवल स्विफ्ट की हिस्सेदारी बढ़ाने की तुलना में विकास की गति से अधिक महत्वपूर्ण है, हमारे पास द्वि-दिशात्मक कहानियां हैं। वे स्विफ्ट अनुयायियों के दृष्टिकोण से कम सुंदर लग सकते हैं, लेकिन चूंकि यह दृष्टिकोण उत्पाद को तेजी से आगे बढ़ने की क्षमता देता है।

डेवलपर्स स्विफ्ट के किसी भी ज्ञान के बिना आए, भाषा को दो सप्ताह में महारत हासिल थी, यह काम करना शुरू कर दिया। कभी-कभी वे डरते हैं कि हमारे पास 60% स्विफ्ट है, लेकिन यह ठीक है, अभी तक ऐसा मामला नहीं आया है जहां कोई कर्मचारी इसे मास्टर नहीं कर सकता है। विपरीत कहानियां हैं - जब उन्हें पता चलता है कि हमारे पास 40% ऑब्जेक्टिव-सी हैं, तो वे यह कहना शुरू कर देते हैं कि हम प्रतिगामी हैं, और आपको पहले स्विफ्ट पर सब कुछ फिर से लिखना होगा, और फिर सुविधाओं में कटौती करनी होगी। लेकिन यहां सब कुछ व्यक्तिगत है, और हम प्रत्येक के साथ व्यक्तिगत रूप से काम करते हैं।

मिश्रित परियोजनाएं हैं, अप्रत्यक्ष मिश्रित परियोजनाएं हैं, स्विफ्ट पर स्वच्छ परियोजनाएं हैं, हमने हर चीज की कोशिश की। सब कुछ बहुत अच्छा काम करता है, कोई चांदी की गोली नहीं है।

JUG.ru समूह: स्विफ्ट और कोटलिन के बारे में वे कहते हैं "क्योंकि वे समान हैं, यह एंड्रॉइड और आईओएस के लिए डेवलपर्स के लिए सुविधाजनक हो गया है कि वे एक-दूसरे के कोड को देखें।" क्या आपके पास विभिन्न प्लेटफार्मों के लिए डेवलपर्स हैं जो एक-दूसरे के कोड को देख रहे हैं या नहीं?

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

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

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

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

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

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

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

नतीजतन, मैं अक्सर ऊपर आया और स्विफ्ट कोड को देखा। ऑब्जेक्टिव-सी को भी देखा, लेकिन मुझे स्विफ्ट ज्यादा पसंद है। हालाँकि, मैंने इसे विकसित नहीं किया, लेकिन मुझे नहीं लगता कि कोड लिखने में कोई कठिनाई होगी। Android डेवलपर्स के पास एक ही बात है।


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

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

"प्रीपेड कार्ड" निदेशालय में, जब बैकएंड को सीवन किया गया था, तब हमारे पास कहानियां थीं, और फिर एंड्रॉइड डेवलपर्स ने एक पर्यावरण, एक वातावरण स्थापित किया और बग फिक्स के एक जोड़े को फिल्माया, बस मदद करने के लिए।

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

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

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

यह बहुत अच्छा है कि लोग पेशेवर विकास चाहते हैं, यहां तक ​​कि विभिन्न विमानों पर भी। हम अवसर देते हैं, और वे स्वयं चुनते हैं कि वे किस तरह से विकास करना चाहते हैं, और हमारे लगभग सभी लोग उत्पाद से प्रेरित होते हैं, उन कार्यों द्वारा जो वे काम करते हैं, जो बहुत अच्छा है।

JUG.ru समूह: अंतिम प्रश्न: क्रॉस-प्लेटफॉर्म विकास के बारे में क्या?

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

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

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

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

हालांकि, इसका मतलब यह नहीं है कि यह हमेशा ऐसा रहेगा। हमारे पास व्यवसाय से कई आशाजनक कार्य और परियोजनाएं हैं, प्रोटोटाइप हैं, और जल्द ही या बाद में हम या तो कोटलिन मल्टीप्लेटमीटर को जेटब्रेन्स या फ्लटर से आज़माएंगे, जो हमारे लिए अधिक दिलचस्प है।

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

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

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

JUG.ru समूह: विस्तृत उत्तरों के लिए धन्यवाद!