من بين مطوري Android ،
يحظى Artyom Zinnatullin باحترام كبير بحيث يمكنك تكوين
تماثل لـ "حقائق حول Chuck Norris" عنه - شيء مثل هذا:
- أرتيوم قاسي لدرجة أنه عندما يراه ، فإن جيثب نفسه يتحول إلى اللون الأخضر (أي منا يمكنه التباهي بجدول المساهمات هذا؟)
- أرتيوم قاسي لدرجة أنه بالنسبة له بوابة رسول .
- Artyom قاسية لدرجة أنه في سياق تطبيقاته هو بودكاست .
عندما قابلناه في مؤتمر Mobius الخاص بنا ، كان الغرض منه للبث عبر الإنترنت. ولكن بعد أن رأينا كيف يشيرون إليها في دردشة Android ، قررنا أن ذلك قد يكون موضع اهتمام الكثيرين على Habré ، وأعدنا نسخة نصية لك (نرفق أيضًا تسجيل الفيديو).
كيف تعيش مع مشروع على مليون سطر من الكود؟ ما هو عيب كوروتين Kotlin؟ ما الخطأ في Google؟ كيف هي التنمية في سان فرانسيسكو مختلفة عن الروسية؟ ماذا كان يتحدث موبيوس؟ تحت خفض - عن كل هذا.
يفغيني تريفونوف : في هذا Mobius ، فاتني كلامك "Android يبني على Lyft" ، لكن بعد ذلك رأيت حشدًا من الناس يرغبون في طرح سؤال في منطقة المناقشة. أردت أن أوضح: لكن بعد كل شيء ، لا يعمل معظم المشاهدين في مشروع عملاق مثل Lyft ، هل كانت هذه التجربة مناسبة لهم على أي حال؟
أرتيوم : هذا شيء مثير للاهتمام. تختلف الخطوط العريضة الأصلية للتقرير في رأسي ، وكيفية تنفيذها في النهاية ، وذلك بفضل لجنة البرنامج الأنيقة.
في البداية ، كنت سأخبرك كيف بدأ كل شيء في Lyft ، لماذا توصلنا إلى حلول تقنية معينة. لقد تحدث إلى سيرجي بويشتيان من لجنة البرنامج لمدة ساعتين ، واستمع وقال: "رائع ، بالطبع ، لكنك قدمت كلمة رئيسية". وفي النهاية ، أدركت أن مثل هذا التقرير ، بالطبع ، أمر مثير للاهتمام للاستماع إليه ، لكنه في الحقيقة ليس مناسبًا لأحد.
وبعد ذلك أعيد تصميمها ، مع تحويل التركيز على الأساليب الهندسية الأساسية لاختيار أنظمة التجميع ، والأنظمة الأخرى. لم يكن لدي هدف لمعرفة الأدوات التي نستخدمها على وجه التحديد. لا أريد أن يأخذ شخص ما ويبدأ في استخدامه عمياء ، ثم أكتب لي رسائل هائلة لا تعمل كل شيء كما قلت لك. أردت أن أنقل الممارسات الهندسية بالضبط حول كيفية اتخاذ قرار ، وما هو مهم في رأيي (طبيعي ، شخصي). لذلك ، آمل أن تكون التجربة في النهاية ذات صلة بعدد أكبر من الناس ، وليس فقط "خرج المتأنق من ليفت وقال شيئًا ما".
Oleg olegchir Chirukhin : هل هناك أي خيارات Lyft غير عادية يصعب على الآخرين القيام بها؟
أرتيوم : نعم ، بالطبع. لدينا نظامان للبناء في المشروع في نفس الوقت ، لا أنصح أي شخص على الإطلاق
(يضحك) .
من الأمور المؤلمة للغاية الحفاظ على ذلك: أنت تطارد باستمرار عصفورين بحجر واحد ، وفي كليهما ، لا يعمل شيء ما حتى النهاية. ولكن هذه هي حالتنا الحالية ، لذلك تاريخيا ، لأن نظام بناء واحد بدأ يصمت على جزء من المهام ، كان علينا أن نبدأ نظاما ثانيا. تحدثت عن كيفية تجنب هذا والهجرة بشكل صحيح إلى واحد منهم.
أوليغ :
وأي نوع من أنظمة البناء؟
أرتيوم : نحن نستخدم Gradle and Buck ، وتحدثت عن كيفية الوصول إلى Bazel من Google.
أوليغ : هذا نوع من التحرك نحو الشر: من المهد الجميل إلى بازيل ، حيث لا توجد حتى تبعيات طبيعية.
أرتيوم : الآن هناك أكثر أو أقل. حسنًا ، نعم ، بالطبع ، هناك مقايضات ، وبطبيعة الحال ، يتمتع Gradle بمزاياه. كل هذا يتوقف على نوع المشروع. سيكون بعض Gradle أكثر ملاءمة من Buck و Bazel ، لأن لديهم بعض النقاط الأساسية التي لن يقوموا بجمعها بشكل تدريجي داخل الوحدة النمطية نفسها ، ولكن Gradle سيكون كذلك ، وبالنسبة للكثيرين هذا مهم للغاية. ومن الرائع أن Gradle يمكنه فعل ذلك.
شيء آخر هو أنه عند إضافة وحدات - أكثر ، وحدات أكثر ، ثمانمائة ، ألف - Gradle أعيد تصميمها بحيث تبطئ خطيًا التجميع في بعض الأماكن. لكن يبدو لي أن Gradle يمكنه إصلاح كل هذا إذا ضغط المجتمع عليهم - وهو ما ربما أقوم به. لنرى.
(ملحوظة: بعد بضعة أيام من هذه المقابلة ، كتب أرتيوم مقالة طويلة عن مشاكل Gradle)أوليغ: هذا هو ، Bazel فقط لأنني أريد دعم عدد كبير من الوحدات؟
أرتيوم : دعنا نقول فقط أننا في حالتنا "لا نشعر به" ، لكن تقسيم المشروع إلى وحدات يسمح لأعمالنا بالتحرك بشكل أسرع. في الأساس ، كما أفهمها ، هذه عزلة حتى لا تنجح معكرونة ، والتي يصعب الحفاظ عليها. تعطي الوحدات مزيدًا من التحكم في أجزاء الكود التي تتفاعل معها. لدينا ما يقرب من مليون سطر من التعليمات البرمجية. إذا كان في وحدة واحدة ، وأود أن معكرونة. لأنه على رأس اللغة - Java، Kotlin - سيكون من الضروري إنهاء شيء ما لحظر المكالمات بين الحزم التي لم يتوقعها أحد. بالإضافة إلى ذلك ، فإن السؤال الذي يطرح نفسه هو أن Gradle لن يقوم بإخراج الكثير من التعليمات البرمجية في وحدة واحدة. لن تجمعها بشكل متوازٍ ، فقم بتجميعها تدريجياً داخل الوحدة.
كل حل له مقايضات. في حالتنا ، يبدو لي أن هذا هو الحل الصحيح ، ولكن هناك مشكلة - حيث أننا ندعم حاليًا نظامي بناء.
أوليغ : وما هو الأفضل لمئات الوحدات: monorepo أو العديد من المستودعات؟
أرتيوم : هذه نقطة حساسة للغاية. من المحتمل أن يكون أحد المستودعات أفضل من وجهة نظر أنه لا يتعين عليك التفكير في تعيين الإصدار ، وليس هناك جهنم للاعتماد عند الذهاب واستنساخ عشرات المستودعات لإجراء تغيير واحد ، ثم فتح طلب سحب واحد وعشرة أخرى بعده. تتم إزالة "الاحتكاك" من النظام ، والناس لا يخافون من تغيير الرمز. بالنسبة لهم ، تنشأ ذرية التغييرات: يتم تحويل كل شيء إلى مشروع واحد ، ويتم نقل التغييرات من وحدة واحدة تلقائيًا إلى الآخرين دون موافقتهم الصريحة. في الوقت نفسه ، سيتم تنفيذ جميع عمليات التحقق التي كتبتها تلقائيًا في CI والتحقق من تجميع الشفرة واختبارها وكل هذا.
أوليغ : وإذا لم تتوصل إلى حقيقة أنك ، كما هو الحال في بعض Chrome ، ستتغير الفروع لمدة دقيقتين ، بينما تشرب الشاي؟
أرتيوم : نعم ، بالطبع ، هناك احتمال. ولكن هنا ، على الأرجح ، يكون السؤال في حجم المنتج بالفعل: هل يحتاج Chrome إلى احتواء الكثير من التعليمات البرمجية؟ ربما يجدر تسليط الضوء على بعض الأجزاء في أدوات منفصلة ، والتي ستشددها بشكل دوري عندما تحدث تغييرات كبيرة فيها؟ ربما هذا هو السؤال لتنظيم المشروع. مثال رائع ، بالمناسبة. لدي واحدة مماثلة: المراسلات مع الرجال من Yandex.Browser ، حيث لديهم أيضا المقابس الكبيرة.
يمكن تقسيم Chrome إلى عدة مكونات ، وإذا كنت تأخذ V8 - لست متخصصًا كبيرًا ، لكن بقدر ما أفهم ، يمكن أن يكون مشروعًا منفصلاً بشكل عام ، أليس كذلك؟ ولماذا ، إذن ، يجب على واجهة المستخدم الرسومية معرفة المحرك وإعادة تجميعه في كل مرة والتفكير في شفرة المصدر الموجودة في مكان قريب؟ Bazel ، بالمناسبة ، كما يدعم هذا.
بشكل عام ، تدعم الآن جميع أنظمة الإنشاءات الكبيرة - مثل Gradle ، و Buck ، والتي Bazel - شيءًا مثل الإنشاءات المركبة عندما تشير ، على سبيل المثال ، إلى مجموعة Bazel أخرى. هذا وضع صعب ، لكن ، مع ذلك ، هذا يعمل ، فهو يسمح لك بإزالة جزء من الملفات من المستودع ، وتقليل الحجم. على سبيل المثال ، سيكون IDE مجنونًا بفهرسة جميع هذه الملفات ، لذلك أريد فصلها بطريقة أو بأخرى عن المكون العام للمشروع.
لكننا بعيدون عن ذلك. يبدو لي أننا نستطيع أن نحقق بهدوء خمس سنوات أخرى. من غير المرجح أن نواجه الخروج لمدة دقيقتين حتى الآن. ليس لدينا الكثير من الناس.
يوجين : هل لا يزال لدى ليفت تفاصيل خاصة به ، إلى جانب نظامي بناء؟
أرتيوم : نعم ، هناك بعض القصص غير التقليدية هناك. لقد حدث أن الأشخاص الذين أتوا إلى الشركة (من Google و Facebook و في كل مكان) يكرهون المستودعات الأحادية. نتيجة لذلك ، لدينا في Lyft ثلاثة مستودعات أحادية: Android و iOS و L5 (هذه هي سياراتنا
المستقلة ).
وكل شيء آخر هو أكثر من 1500 مستودع للبوابات: لجميع الخدمات المصغرة ، ولجميع المكتبات بشكل منفصل. هذا هو الحال تاريخيا. هذا له ثمنه الضخم الذي ندفعه: دفع التغييرات من خلالها أمر صعب حقًا. من ناحية أخرى ، عند العمل مع كل واحد منهم ، لديك استنساخ بوابة فوري ، دفع فوري ، كل شيء سريع للغاية ، فهارس IDE في الثانية. أستطيع أن أقول أن هذا هو حقا جزء مثير للاهتمام. من الرجال من سان فرانسيسكو ، أتوقع مستودع واحد.
أوليغ : وعندما يتم تحديث أحد هذه المستودعات المنفصلة - تغيير واجهة برمجة التطبيقات ، على سبيل المثال - كيف ينطبق هذا التغيير على بقية الشركة؟
أرتيوم: إنه مؤلم.
(يضحك) حسنًا ، أنا لست مطورًا للواجهة الخلفية ، بمعنى أنني لا أكتب الواجهات الخلفية للميزات ، بل أكتب الواجهات الخلفية للبنية التحتية - فهي عادة ما تكون مستقلة تمامًا في هذا الصدد.
كقاعدة عامة ، هذه مجرد مجموعة من التجمعات والتفاعل المتبادل ثم التخطيط.
أوليغ: إذن المسيرات جزء من نظام التجميع؟ (يضحك)
أرتيوم : نعم ، نحتاج أولاً إلى التجمع ، ثم تجميع مستودع. بالإضافة إلى ذلك ، للأسف ، تاريخياً ، لدينا العديد من هذه الخدمات المصغرة - هذه هي بيثون ، التي لديها أيضًا نكاتها الخاصة.
أوليغ : بعض الكراهية لبيثون انزلق.
أرتيوم : يكرهون الكتابة الديناميكية. Python ، وليس Python - لا يوجد فرق ، لكن الكتابة الديناميكية شيء مؤلم.
يوجين : وتراجع أيضًا "لشركة من سان فرانسيسكو" ، ومن الغريب أن نسأل هذا: ولكن فيما يتعلق بالتطوير ، تختلف الشركات من سان فرانسيسكو عن الشركات من روسيا ، هل هناك فرق ملحوظ؟
أرتيوم : فرق كبير جدا. لست معجبًا كبيرًا بتصنيفها على هذا النحو ، لكن يبدو لي أن هذه مدرسة هندسية أكثر صحة.
أوليغ : هنا - أين هو؟
أرتيوم : في روسيا ، في بلدان الاتحاد السوفيتي السابق. يولي الناس المزيد من الاهتمام للجوانب التقنية لكيفية عمل مكونات النظام الخاصة بهم. وغالبًا ما يحدث في الولايات أن تحل بعض المكتبات مشكلة ، ولا ينظر الناس حتى إلى كيفية تنفيذها. وهم ، كقاعدة عامة ، لا يهتمون مطلقًا بإبطائه أو استخدامه بشكل غير صحيح.
سأقابل الكثير من الناس هناك ، لأن هذا جزء من العمل ، وربما لا يزال المستوى العام للمعرفة أقل. هناك شيء للتغيير. في كل مرة يأتي شخص من أوروبا الشرقية ، يصبح الأمر أكثر إثارة للاهتمام أثناء المقابلات ، لأن الناس لا يخشون مقاومتهم ، للمناقشة في مكان ما. في حين أن المرشحين الأميركيين في كثير من الأحيان قد لا يجيبون على الأسئلة مطلقًا أو يجيبون "لا أتذكر متى استخدمت آخر مرة". لأسئلة مثل "كيف يعمل طلب HTTP؟" أو "ما تنسيق البيانات الذي ستختاره؟" لا يمكنهم إعطاء إجابات هندسية طبيعية ، لكنهم يقولون: "حسنًا ، لقد استخدمت هذا على مدار السنوات الخمس الماضية." بارد ، بالطبع ، ولكن الرب لا يسحب.
من ناحية أخرى ، هناك مشاريع استغرقت سنوات للمقارنة مع ما نقوم به هنا. يصنع الناس المزيد من المنتجات ، وهناك ببساطة نطاق أكبر. على سبيل المثال ، Chrome أو Uber - لديهم بالفعل أكثر من ألف وحدة هناك. هذا هو مجرد حجم المشاكل. دعنا نقول في أوبر تحت ثلاثمائة مطور أندرويد. السؤال الذي يطرح نفسه: لماذا؟
(يضحك) ولكن ، مع ذلك ، تمكنوا من جعل هذا العمل الضخم ، والإفراج باستمرار. أود أن أقول مثل هذه القضايا أقل تواترا حلها هنا.
هنا ياندكس مثال جيد. لدي صديق على Yandex.Maps: يقوم عشرة أشخاص بعمل تطبيق Android. في جوجل ، على الأرجح المئات يجلسون. وفي الوقت نفسه ، Yandex.Mart لديه المزيد من الوظائف. هذا هو الفرق ، في رأيي.
يوجين : بالإضافة إلى ذلك ، يرتبط الوادي أيضًا بالشركات المبتدئة ، ولديه نهج "التحرك السريع وكسر الأشياء" ، ويبدو أن هذا يجب أن يؤثر أيضًا على التطور: العيش على حافة النزيف ، استخدم الأحدث. هل هذا صحيح؟
أرتيوم : لم أعمل في الشركات الناشئة ، يصعب على ليفت تسمية ما يلي: يوجد بالفعل ثلاثة آلاف شخص ، في مكان ما أكثر من ألف منهم مهندسون. وهذا هو ، وهي شركة شكلت بالفعل.
إنها أحدث التقنيات التي نادراً ما تستخدم. إذا تم قلل التكنولوجيا ، ثم نعم. إذا كانت التكنولوجيا مناسبة ، لكنها باردة ، فغالبًا لا. إلى أن تتحدث جميع المؤتمرات عن ذلك ، فإن قلة قليلة من الناس ستستخدمه.
لكن في الوقت نفسه ، ما أحبه حقًا (في سان فرانسيسكو وجزئيًا في الوادي) - يتم حل الكثير من المشكلات نظرًا لحقيقة أن الشركات قريبة جسديًا. في كثير من الأحيان ، تكتب إلى شخص ما في غرفة دردشة: "دعونا نتناول الغداء معًا في مكاننا أو في مكتبك ونقرر ، سنقدم بعض الأسئلة" ، ثم مرة واحدة - يظهر مشروع مفتوح المصدر أو طلب سحب في مشروع آخر ، شيء ما ثابت.
ما هو مثير للاهتمام: الناس في كثير من الأحيان مناقشة الأشياء التي في الواقع لا ينبغي مناقشتها على NDA. لكن هكذا يتحرك الوادي بالكامل ، في النهاية ، يفهم الجميع أين يتحرك الباقي ، وتتجه الصناعة بأكملها. لنفترض أن متعاوني Lyft و Uber يتحدثون دائمًا عن الأشياء الفنية ، لأننا نستخدم المصادر المفتوحة من Uber. وبطبيعة الحال ، هناك خبراء المتشددين مباشرة في بعض التقنيات. هذا رائع أيضًا: يمكنك فقط عبورهم.
أنا أحب هذا ، وهذا لم يكن كافيا بالنسبة لي في بعض المدن التي عشت فيها. هنا في سان بطرسبرغ كانت هناك مجموعة مستخدمي Java رائعة جدًا (لا أعرف بالفعل كيف هي الآن): لقد أتيت بعد العمل ، وأخذت Shipilev عقلك ، وشيء جيد!
ويظهر ذلك مرة أخرى: على سبيل المثال ، يحتوي أيضًا على مجموعة مستخدمي Java الخاصة به ، وغالبًا ما يأتي رجال من أوراكل ، على سبيل المثال ، قاموا بتصوير بعض رد الفعل الجديد JDBC. وتجادل ، لأن بعض قادة Project Reactor أو زعيم Reactive في Spring يجلسون في نفس المكان ، هناك نقاش ساخن ، وهذا رائع.
أوليغ : سوف أسأل عن شيء آخر: نظرت إلى
مستودع Mainframer ، وصدأ يستخدم هناك. لماذا كل هذا ليس مكتوبًا على الجافا المباركة ، ولكن على نوع من الصدأ؟
أرتيوم : لقد ذهبت مؤخرًا إلى الجانب القائل بأن البرنامج يجب أن يحتوي على الحد الأدنى من الموارد. وهذا هو ، أريد أن أكون قريبًا جدًا من كيفية هضم الحديد بايت. وفي Java ، تحدث أشياء كثيرة (لا أتحدث حتى عن جمع القمامة) ، أي JIT وكل هذا. يعجبني حقًا أن Java تتجه الآن نحو حقيقة أنه سيكون هناك أيضًا تجميع مسبق للوقت. يبدو لي أنه سيكون من الرائع جدًا ، على سبيل المثال ، بدء تشغيل خدمة microservice من خلال التنزيل من التجميع التجميعي لها في وقت مبكر ، والذي حدث في الأصل على بعض الأجهزة الأخرى ، وبدء تشغيله بسرعة كبيرة ، دون الاحماء. هذا رائع ، لكن جافا لها سعر. لا يمكنني فقط أن أطلب من الأشخاص الذين يبنون مشروع iOS أن يكون لديهم جافا على نظامهم.
تم كتابة Mainframer في لهجة Bash. لكنني أردت إعادة كتابتها بلغة نظام للحصول على مؤشرات ترابط عادية ، والقدرة على كتابة اختبارات الوحدة العادية ، وليس فقط اختبارات التكامل أعلى الأداة ...
أوليغ : ويمكن للمرء أن يأخذ ، على سبيل المثال ، بيثون.
أرتيوم : نعم. لكن السؤال الذي يطرح نفسه هو حقيقة أن هذا أولاً هو الكتابة الديناميكية ، وثانياً ...
أوليغ : هكذا في باش ، الكتابة الديناميكية أيضًا.
أرتيوم : لذلك أردت إعادة كتابته. وإلى جانب ذلك ، هناك مشكلة في حقيقة أن بيثون الآن هما: على نظام ماكنتوش ، افتراضيا ، والثاني تقريبا على لينكس هو الآن الثالث. هناك كل أنواع هذه النكات. إذا كنت بحاجة إلى نوع من الإدمان لربط أنني سوف أطلب من الناس لتشغيل نقطة؟ أو سوف تضطر إلى فرقعة لها؟
كنت أرغب في استخدام لغة نظام لا تتطلب أي تبعية ، حتى أتمكن من وضع ثنائي يزن ، أقل من ميغابايت ، ويعمل بشكل بسيط.
أوليغ : يمكنك أن تأخذ جولانج ، على الأقل يوجد جامع للقمامة.
أرتيوم : لهذا السبب بالضبط أردت تجربة الصدأ. وانها عملت. زائد ، Golang حزينة نوعا ما مع الأدوية.
يوجين : منذ أن بدأوا مناقشة اللغات ... في سياق تطوير Android ، أصبح السؤال "Kotlin أو Java" متعبًا بالفعل ، لكن ما زلت سأطرحه من أجل الانتقال إلى السؤال التالي.
أرتيوم : حسنًا ، كوتلين ، بالطبع.
يوجين : الآن السؤال الذي يهم حقا. في الآونة الأخيرة ، في Kotlin ، أصبح coroutines مستقرًا ، وتسمع أصوات "هوراي ، هيا بنا بعيدًا عن RxJava". لذلك ، عندما أرى شخصًا أمامي قريب جدًا من RxJava ، أريد على الفور أن أسأل رأيه حول coroutines.
أرتيوم : كنت سلبية للغاية تجاه coroutines. من حيث المبدأ ، لا يزال الجانب السلبي في الغالب ، ولكن هذا قد غير جزئيًا المحادثة الطويلة جدًا مع
روما إليزاروف ، الذي يعمل عليها.
كمستخدم للبرامج ، أريدهم أن يكونوا غير محظورين قدر الإمكان ، وأن يستخدموا الموارد بشكل صحيح قدر الإمكان. أعني بذلك التوازي وحقيقة أنهما يستخدمان واجهات برمجة التطبيقات (APIs) الصحيحة لنظام التشغيل لمنع الوصول إلى الشبكة أو الملفات دون حظر - هناك الكثير من المشاكل في هذا في أنظمة التشغيل ، لكن مع ذلك ، هناك واجهات برمجة التطبيقات هذه. ماذا بالضبط هذا حل؟ كمستخدم ، لا يهمني ذلك - إذا كان المطورون وحدهم سيحلون هذه المشكلة بطريقة تجعلهم يشعرون بالراحة. ليس لدي أي مشاكل كبيرة مع هذا. وهذه هي رؤية روما إليزاروف. بعد هذه المحادثة ، سمحت لها بطريقة ما.
قبل ذلك ، مثل صديقي
آرثر دريموف ، بدا
لي خطوة
إلى الوراء بعد عدة سنوات من استخدام Java في الإنتاج: أصبح الكود مرة أخرى حتمية ونظيفة ، ويفقد فهم خط الأنابيب ، يصبح مرة أخرى فوضى ، يتحول المترجم إلى فوضى غير متزامنة لك.
لا أستخدم coroutines ، لكن كل الأمثلة التي أشاهدها الآن قد تحولت إلى نهج منظم ، حتى عندما لا ترى أي جزء من التعليمات البرمجية من هذا هو coroutine. أن نكون صادقين ، أنا خائف جدًا من النظر إليها. لأنني قمت بفتح طلب السحب على GitHub ، يتم استدعاء بعض الطرق لتحميل الصورة وملف التعريف ، واحدة منها تذهب إلى الشبكة ، والآخر يذهب إلى SQLite المحلي ، وهنا يمكن بسهولة حجب SQLite المحلي. لا أرى هذا في الكود ، لأن الخطوط النقطية مصنوعة بحيث لا تراها. ربما يكون ذلك جيدًا ، لكن بالنسبة لي لا يزال هذا ناقصًا للتصميم ، لأنه في Rx-approach يكون الأمر واضحًا جدًا: هل تفهم ما إذا كان هذا جزءًا من خط أنابيب متزامن أم لا.
ربما هذه هي شكواي الوحيدة إلى coroutines: أريد أن أرى متى يحدث تزامن بلدي ، وعندما لا. من الناحية المثالية ، أريد أن يكتب الأشخاص رمزًا وظيفيًا أكثر عندما تكون هناك قطع صغيرة قابلة لإعادة الاستخدام أو على الأقل قابلة للاختبار تتحد مع الآخرين. ونعود إلى حقيقة أن كل هذا مضمّن في المنطق ، ثم المترجم ثم يقلبه فقط.
أوليغ : اسمحوا لي أن أقدم لكم معارضة صغيرة. الكود القديم أكثر بكثير من الجديد. وإذا أخذنا بعض الأشياء مثل العمل مع شبكة ، والتعامل مع الملفات ، وما إلى ذلك ، فلن يقوم أحد بإعادة كتابة كل هذا بسرعة ، على سبيل المثال ، باستخدام RxJava. وإذا كان لدينا autocoroutines ، فيمكننا ، على سبيل المثال ، تتبع جميع syscalls ، لفها تلقائيا وإرسالها إلى القفل لمواقف السيارات.
Artyom : صحيح ، في أي حال ، سوف تضطر إلى استدعاء وظائف من سياق corutin. لكن هذه فكرة مثيرة للاهتمام ، نعم.
أوليغ : ربما ينبغي دمجها بطريقة أو بأخرى؟ واجهة برمجة التطبيقات (API) عالية المستوى ستكون على RxJava ، وواجهة برمجة التطبيقات (API) منخفضة المستوى على coroutines.
أرتيوم : نعم ، هناك الآن مثل هذه التحولات. ولكن بعد ذلك يطرح السؤال ، لأنه في الوقت الحالي ، يمكن لـ RxJava أن تفعل كل ما تفعله corotines ، ولا تستطيع corotines أن تفعل كل ما تفعله 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 فبراير ، سترتفع أسعار التذاكر. وأيضًا ، نظرًا لأن البرنامج لم يكتمل بعد ، فإن اللحظة مناسبة أيضًا للدخول فيه بأنفسنا: نحن على قدم وساق نقبل طلبات الحصول على التقارير. جميع المعلومات حول المؤتمر والتذاكر موجودة على الموقع .