"यह हमारे लिए रेट्रोफिट का उपयोग करने के लिए कोई मतलब नहीं है": Sberbank ऑनलाइन पर Android विकास के बारे में

Google Play पर कितने रूसी एप्लिकेशन "50,000,000+ इंस्टॉलेशन" कहते हैं? जाहिर है, इस तरह के प्रत्येक मामले की अपनी बारीकियों के साथ एक अनूठी कहानी है, इसलिए डेवलपर्स के साथ बात करना दिलचस्प होगा। और जब इस तरह के एप्लिकेशन की रेटिंग भी 4.6 है, तो यह ब्याज को मजबूत करता है।

व्लादिमीर Tebloev Sberbank ऑनलाइन Android आवेदन पर काम कर रहे लोगों में से एक है। वसंत में, जब सेर्बैंक टेक्नोलॉजीज ने हमारे मोबियस सम्मेलन में भाग लिया, तो उन्होंने वहां एक रिपोर्ट की, और अब हमने व्लादिमीर से उसके काम की विशेषताओं के बारे में पूछने का फैसला किया।


- सबसे पहले, हमें बताएं कि आप वास्तव में क्या कर रहे हैं?

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

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

- हर किसी के पास शब्द "Sberbank" और "मोबाइल विकास" Sberbank ऑनलाइन के साथ जुड़ा हुआ है। लेकिन इतनी बड़ी कंपनी में, क्या शायद आंतरिक मोबाइल विकास भी है? क्या यह बाहर से अलग है?

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

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

- और यह कैसे "यहां तक ​​कि एक दुर्लभ समस्या कई को चोट पहुँचाती है" काम को प्रभावित करती है? क्या आपको कुछ विदेशी समस्याओं से निपटना होगा जो छोटे अनुप्रयोग रडार के नीचे से गुजर सकते हैं?

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

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



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

- अब यह 16 है, और हमने इसे पिछले साल 14. से हटा लिया। 14. हम एक विशिष्ट एसडीके के साथ ग्राहकों की संख्या को देखते हैं, और अगर यह 5% से कम हो जाता है, तो हम संस्करण बढ़ा सकते हैं। अब तक, हमारे पास एंड्रॉइड 4.4 किटकैट पर कई उपयोगकर्ता हैं, लगभग 16% - हमें उनका समर्थन करने की आवश्यकता है।

- क्या कोई नया संस्करण है जिसे आप अभी देख रहे हैं और सोच रहे हैं, "जैसे ही हम MinSdkVersion बढ़ाते हैं, क्या हम इसे तुरंत उपयोग करते हैं?"

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

कुछ ऐसे मामले हैं जिनमें हम संस्करण की जांच करते हैं, उदाहरण के लिए, एसएसएल पिनिंग। यह एंड्रॉइड के विभिन्न संस्करणों में अलग-अलग तरीके से काम करता है, इसलिए हम कोड के दो संस्करणों को लागू करते हैं, एंड्रॉइड डिवाइस के लिए "4.4 तक" और "4.4 से"।

बेशक, मैं "केवल Android P के लिए विकसित करना चाहता हूं और किसी भी चीज के बारे में नहीं सोचना चाहता" - लेकिन यह हमेशा ऐसा होता है, कहीं भी नहीं मिलता है।

- उल्लिखित एसएसएल पिनिंग के लिए। जाहिर है, बैंक के लिए सुरक्षा मुद्दे बहुत महत्वपूर्ण हैं। और यह आपको कैसे प्रभावित करता है, गैर-बैंकिंग एप्लिकेशन पर काम करने से आपका काम कैसे अलग है?

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

छोटी कंपनियों में, मुझे लगता है, अक्सर कोई सुरक्षा विभाग नहीं होता है जो आवेदन को शांत करेगा। यदि कोई थानेदार पाए जाते हैं, तो वे w3bsit3-dns.com या एक समान संसाधन पर पॉप अप कर सकते हैं।

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

- सुरक्षा कारणों से, बैंक रूट किए गए स्मार्टफ़ोन के मामले में अपनी कार्यक्षमता सीमित करते हैं। रूट किए गए उपकरणों के लिए Sberbank Online के लिए क्या निषिद्ध है?

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

- और सुरक्षा के नाम पर, कुछ उपयोगकर्ताओं को नहीं, बल्कि खुद को डेवलपर्स के रूप में प्रतिबंधित करना आवश्यक था, मना कर दिया कि वे अन्यथा इसका उपयोग करेंगे?

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



- अपरिहार्य प्रश्न: आपके पास कोटलिन के साथ क्या है?

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

इसलिए कोटलिन को छोटे चरणों में लागू किया जाता है: उदाहरण के लिए, हम कोटलिन पर परीक्षण लिखते हैं और डेटा कक्षाओं का उपयोग करते हैं (इसलिए हम समय की बचत करते हैं ताकि गेटर्स, सेटर्स, बराबरी के लिए परीक्षण न लिखें), हैशकोड () और इतने पर)।

अब यह धीरे-धीरे चल रहा है, और अगले चरण में हम कोटलिन पर परीक्षण के लिए अपने डीएसएल को लिखना चाहते हैं। और समानांतर में, हम कंपनी में कोटलिन ज्ञान के स्तर को ऊपर उठाना चाहते हैं: उदाहरण के लिए, माइटैप्स की मदद से।

- "डायलॉग्स" के मामले में आप मैसेजिंग में लगे हैं, लेकिन व्हाट्सएप का सीधा एनालॉग नहीं है। और इसलिए यह दिलचस्प है: अन्य लोगों के समाधान आपके लिए कितने उपयोगी हैं? क्या आप कोड में ओपन सोर्स मैसेंजर का उपयोग करते हैं?

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

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

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

पहला बिंदु: आप "एप्लिकेशन मॉड्यूल आर्किटेक्चर" में हैं। हमने पहले ही इस तथ्य के बारे में कहा था कि एप्लिकेशन को मॉड्यूल में विभाजित किया गया है - आप वास्तुकला के बारे में और क्या कह सकते हैं?

- यह हमारे साथ चलने का विकास कर रहा है, संस्करणकरण चल रहा है, अब हम 17 वें संस्करण में पहुंच गए हैं।

16 वीं पर, क्लीन आर्किटेक्चर पेश किया गया था। हम इस बात पर सहमत थे कि कौन (प्रेजेंटेशन, डोमेन, डेटा-लेयर) के लिए कौन ज़िम्मेदार है, किन संस्थाओं और कहाँ उपयोग किया जाना चाहिए, कन्वर्टर्स कहाँ होने चाहिए - सामान्य तौर पर, उन्होंने सभी वास्तुशिल्प मुद्दों को चित्रित किया और उन्हें लागू किया।

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

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

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

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

- दूसरा बिंदु "काम और स्मृति की खपत का अनुकूलन" है। यह प्रश्न कितना तीव्र है, क्या मुझे लगातार पुराने उपकरणों वाले उपयोगकर्ताओं के बारे में सोचना है?

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

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

- चलिए सवालों के परीक्षण की ओर बढ़ते हैं: यह आपके साथ कैसे हो रहा है?

- मैं केवल हमारी टीम के बारे में बात कर सकता हूं, दूसरों में यह प्रक्रिया अलग तरीके से बनाई जा सकती है।

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

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

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

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

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



- अगला आइटम: कोड समीक्षा। क्या आपके पास कोई विशिष्टता है, या "हर किसी की तरह"?

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

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

- अगला बिंदु विरासत कोड का पुन: निर्धारण है। यह व्यवस्थित रूप से कैसे होता है: नियोजित कार्यों के साथ ठीक है, या "क्या आपको पुराने कोड में परिवर्तन करने की आवश्यकता है - एक ही समय में इसे फिर से भरना"?

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

- सेर्तेख में भी, आप ट्रेनिंग प्रोग्रामर में शामिल हैं। कंपनी के अंदर प्रशिक्षण कैसा दिखता है?

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

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

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

- साक्षात्कार: क्या आप उन्हें "हर किसी की तरह" या एक विशिष्टता है?

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

, : , OOD (Object Oriented Design, ), Java Core Android SDK. . , , . : , , - . . , , , Dagger 2, RxJava. , Kotlin. , . - , , , . , .

— « ». - , .

— — RxJava, , . , , . .

Retrofit, : , , . , — .

TinyMachine - — , , , . , «» , , . -, , - rocket science, .

— : . , , ?

- हां। — Java-. « »: Java- — - («» — Android-: , , , ). , , , — Java-. , . , , , , « payment? payment payment ? paymentTest?».

, Confluence. , material design , - , . , , Confluence. , , , , , , . : RxJava Confluence best practices — , , . : , .

, . Confluence 200 . . Confluence, , , .