"मैं कोरटाइन्स के प्रति बहुत नकारात्मक था": एंड्रॉइड विकास पर अरेटोम ज़ीनतुल्लिन

एंड्रॉइड डेवलपर्स के बीच, आर्टीम ज़ीनतुल्लिन इतने सम्मानित हैं कि आप उनके बारे में "चक नॉरिस के बारे में तथ्य" का एक एनालॉग लिख सकते हैं - कुछ इस तरह:

• एर्टोम इतना गंभीर है कि उसकी दृष्टि में गीथब अपने आप हरा हो जाता है (हम में से कौन इस तरह के योगदान का दावा कर सकता है?)
• आर्टीम इतना कठोर है कि उसके लिए एक संदेशवाहक है ।
• एर्टोम इतना कठोर है कि उसके अनुप्रयोगों के संदर्भ में एक पॉडकास्ट है ।

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

कोड की एक लाख लाइनों पर एक परियोजना के साथ कैसे रहें? कोरोटिन कोटलिन का नुकसान क्या है? Google के साथ क्या गलत है? सैन फ्रांसिस्को में विकास रूसी से कैसे अलग है? मोबियस की बात क्या थी? कटौती के तहत - इस सब के बारे में।


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

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

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

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

ओलेग ओलेचिर चिरुखिन : क्या कोई असामान्य Lyft विकल्प हैं जो दूसरों के लिए बनाना मुश्किल है?

आर्टीम : हां, बिल्कुल। हमारे पास प्रोजेक्ट में एक ही समय में दो बिल्ड सिस्टम हैं, मैं बिल्कुल किसी की सिफारिश नहीं करता (हंसते हुए) ।

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

ओलेग : और किस तरह के बिल्ड सिस्टम हैं?

आर्टीम : हम ग्रैडल और बक का उपयोग करते हैं, और मैंने बात की कि Google से बाजेल कैसे आया जाए।

ओलेग : यह बुराई के प्रति कुछ प्रकार का आंदोलन है: सुंदर ग्रैडल से बाजेल तक, जिसमें सामान्य निर्भरताएं भी नहीं हैं।

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

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

ओलेग: यही है, Bazel केवल इसलिए कि मैं बड़ी संख्या में मॉड्यूल का समर्थन करना चाहता हूं?

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

प्रत्येक समाधान में व्यापार बंद होता है। हमारे मामले में, यह मुझे लगता है कि यह सही समाधान है, लेकिन एक समस्या है - इसमें हम वर्तमान में दो निर्माण प्रणालियों का समर्थन करते हैं।

ओलेग : और सैकड़ों मॉड्यूल के लिए क्या बेहतर है: मोनोरेपो या कई रिपॉजिटरी?

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

ओलेग : और यदि आप इस तथ्य पर नहीं आते हैं कि आप, जैसे कि कुछ क्रोम में, शाखाएं दो मिनट के लिए बदल जाएंगी, जबकि आप चाय पीते हैं?

आर्टीम : हां, निश्चित रूप से, एक संभावना है। लेकिन यहां, शायद, सवाल पहले से ही उत्पाद के आकार में है: क्या क्रोम को इतना कोड शामिल करने की आवश्यकता है? हो सकता है कि यह अलग-अलग उपकरणों में कुछ हिस्सों को उजागर करने के लायक है, जो समय-समय पर उनमें बड़े बदलाव होने पर कसता है? यह शायद परियोजना के संगठन के लिए एक सवाल है। ठंडा उदाहरण, वैसे। मेरे पास एक समान है: Yandex.Browser से दोस्तों के साथ पत्राचार, जहां उनके पास बड़े प्लग भी हैं।

क्रोम को कई घटकों में विभाजित किया जा सकता है, और यदि आप कुछ V8 लेते हैं - मैं एक बड़ा विशेषज्ञ नहीं हूं, लेकिन जहां तक ​​मैं समझता हूं, यह सामान्य रूप से एक अलग परियोजना हो सकती है, है ना? और फिर, जीयूआई को इंजन के बारे में क्यों जानना चाहिए, हर बार इसे फिर से इकट्ठा करना चाहिए और पास में पड़े स्रोत कोड के बारे में सोचना चाहिए? वैसे, Bazel भी इसका समर्थन करता है।

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

लेकिन हम इससे बहुत दूर हैं। यह मुझे लगता है कि हम शांति से एक और पांच साल लगा सकते हैं। हमें अभी दो मिनट के चेकआउट में भाग लेने की संभावना नहीं है। हमारे पास कई लोग नहीं हैं।

यूजीन : क्या Lyft में अभी भी दो बिल्ड सिस्टम के अलावा अपनी खुद की बारीकियां हैं?

एरीटम : हां, वहाँ कुछ एटिपिकल कहानियां हैं। ऐसा हुआ कि कंपनी (Google, फेसबुक, हर जगह) से आए लोग मोनो-रिपॉजिटरी से नफरत करते हैं। नतीजतन, हमारे पास Lyft में तीन मोनो-रिपॉजिटरी हैं: एंड्रॉइड, आईओएस और एल 5 (ये हमारी स्वायत्त कार हैं )।

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

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

आर्टीम: दर्द होता है। (हंसते हुए) ठीक है, मैं इस मायने में बैकएंड डेवलपर नहीं हूं कि मैं फीचर बैकेंड नहीं लिखता, मैं इन्फ्रास्ट्रक्चर बैकेंड लिखता हूं - वे आमतौर पर इस संबंध में काफी स्वायत्त होते हैं।

एक नियम के रूप में, यह सिर्फ रैलियों, क्रॉस-इंटरैक्शन, और फिर योजना का एक गुच्छा है।

ओलेग: तो रैलियां विधानसभा प्रणाली का हिस्सा हैं? (हंसते हुए)

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

ओलेग : पायथन के लिए कुछ नापसंद फिसल गया।

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



यूजीन : और यह "सैन फ्रांसिस्को की एक कंपनी के लिए" फिसल गया, और यह पूछने के लिए उत्सुक है: लेकिन विकास के संदर्भ में, सैन फ्रांसिस्को की कंपनियों रूस की कंपनियों से भिन्न हैं, क्या ध्यान देने योग्य अंतर है?

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

ओलेग : यहाँ - यह कहाँ है?

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

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

दूसरी ओर, ऐसी परियोजनाएं हैं जिनकी तुलना हम यहां कर रहे हैं। लोग अधिक बड़े पैमाने पर उत्पाद बनाते हैं, और बस अधिक पैमाना होता है। उदाहरण के लिए, क्रोम या उबेर - उनके पास पहले से ही एक हजार से अधिक मॉड्यूल हैं। यह सिर्फ समस्याओं का पैमाना है। आइए उबर में तीन सौ Android डेवलपर्स के तहत कहते हैं। सवाल उठता है: क्यों? (हंसते हुए) लेकिन, फिर भी, वे लगातार काम करते हुए इस कॉलोज़ को बनाने में कामयाब रहे। मैं कहूंगा कि इस तरह के मुद्दों को यहां अक्सर हल किया जाता है।

यहां यैंडेक्स एक अच्छा उदाहरण है। Yandex.Maps पर मेरा एक दोस्त है: दस लोग एक Android एप्लिकेशन बनाते हैं। Google में, सबसे अधिक संभावना है कि सौ बैठे हैं। और एक ही समय में, Yandex.Mart में अधिक कार्यक्षमता है। यही अंतर है, मेरी राय में।

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

Artyom : मैंने स्टार्टअप में काम नहीं किया, Lyft को कॉल करना मुश्किल है: पहले से ही तीन हजार तीन लोग हैं, कहीं न कहीं उनमें से एक हजार से ज्यादा इंजीनियर हैं। यानी यह पहले से गठित कंपनी है।

यह अत्याधुनिक तकनीक है जिसका उपयोग शायद ही कभी किया जाता है। यदि तकनीक सम्मोहित है, तो हाँ। यदि तकनीक आला है, लेकिन शांत, बहुत बार नहीं। जब तक सभी सम्मेलन इसके बारे में बात नहीं करते, तब तक बहुत कम लोग इसका उपयोग करेंगे।

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

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

मुझे यह पसंद है, और कुछ शहरों में जहां मैं रहता था, मेरे लिए यह पर्याप्त नहीं था। यहां सेंट पीटर्सबर्ग में एक बहुत ही शांत जावा उपयोगकर्ता समूह था (मैं पहले से ही नहीं जानता कि यह अब कैसे है): आप काम के बाद आते हैं, और शिपिलेव आपके मस्तिष्क को निकालता है, और कुछ अच्छा है!

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

ओलेग : मैं कुछ और के बारे में पूछूंगा: मैंने मेनफ्रेमर रिपॉजिटरी को देखा, और वहां जंग का उपयोग किया जाता है। यह सब धन्य जवका पर नहीं, बल्कि किसी प्रकार की रस्ट पर क्यों लिखा गया है?

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

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

ओलेग : और एक, उदाहरण के लिए, पायथन ले सकता है।

ऐरीटॉम : हाँ। लेकिन फिर इस तथ्य के साथ सवाल उठेगा कि, सबसे पहले, यह गतिशील टाइपिंग है, और दूसरी बात ...

ओलेग : तो बैश में भी, गतिशील टाइपिंग।

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

मैं एक ऐसी प्रणाली भाषा लेना चाहता था जिसमें शून्य निर्भरता की आवश्यकता हो, ताकि मैं एक बाइनरी लगा सकूं जो वजन, सशर्त, मेगाबाइट से कम, और न्यूनतम ओवरहेड के साथ काम करेगा।

ओलेग : आप गोलंग ले सकते हैं, कम से कम एक कचरा कलेक्टर है।

Artyom : यही कारण है कि मैं जंग की कोशिश करना चाहता था। और इसने काम किया। इसके अलावा, गोलांग जेनेरिक के साथ थोड़े दुखी है।

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

एरीटॉम: ठीक है, कोटलिन, बिल्कुल।

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

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

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

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

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

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

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

एरीटॉम : सच है, किसी भी मामले में, आपको कोरुटिन के संदर्भ से कार्यों को कॉल करना होगा। लेकिन यह एक दिलचस्प विचार है, हाँ।

ओलेग : शायद वे किसी भी तरह संयुक्त होना चाहिए? शीर्ष-स्तरीय API RxJava पर होगा, और निम्न-स्तरीय API coroutines पर होगा।

ऐरिटॉम : हाँ, अब इस तरह के बदलाव हैं। लेकिन फिर सवाल उठता है, क्योंकि इस समय, RxJava सब कुछ कर सकता है जो कि coroutines करते हैं, और coroutines वह सब कुछ नहीं कर सकते हैं जो RxJava करता है। , — . , , , - Rx Kotlin. . forEach - map, . , , Java- , . .

, Kotlin — . , Go , , API, , : . , , , , legacy, , . , Java Kotlin — legacy, , . , . - , .

, , . , , , — . .



: , . , , : Android-? , .

: … . , Android- . , . , : , . RxJava , : - . , , .

, iOS. , Lyft iOS- dependency injection RxSwift. 2019-. iOS-, , , clean, . , Android — .

, , — Google. « opinionated, , : , , ». — , , .

, «RxJava — , ...» : «, LiveData». , — RxJava, , . , , Google , .

: «, Google MVVM». , MVVM , , , MVVM . , Google.

, , scope . .

: , Room . - Architecture Components — , . Google , ? .

: , . , . !

: .

अगला मोबियस 22-23 मई को सेंट पीटर्सबर्ग में आयोजित किया जाएगा । अब उनके कार्यक्रम की घोषणा नहीं की गई है, लेकिन टिकट खरीदने के लिए यह सबसे लाभदायक क्षण है: 1 फरवरी को, टिकट की कीमतें बढ़ जाएंगी। और यह भी, चूंकि कार्यक्रम अभी तक पूरा नहीं हुआ है, यह क्षण स्वयं में प्राप्त करने के लिए भी उपयुक्त है: हम पूरी तरह से रिपोर्ट के लिए आवेदन स्वीकार कर रहे हैं । सम्मेलन और टिकट के बारे में सभी जानकारी साइट पर है ।