出于很多原因，
Denis Neklyudov对于Android开发人员来说
很有趣。 他从事Android Dev Podcast的工作，在会议上发表演讲，参加GDE峰会-通常，他以各种方式参与社区的生活。 由于他现在居住在美国并在Lyft工作，因此他可以将西方情况与俄罗斯情况进行比较。
在Mobius 2019 Piter的前夕，他
谈到 “注重缩放的体系结构”时，我们向他询问了所有这一切。 俄罗斯播客如何引起西方听众的兴趣？ 在成百上千的移动开发人员眼中，如何工作？ Google针对Android开发人员的解决方案出了什么问题？ 一般而言，使用智能手机有什么问题？
播客
-您参与了Android Dev Podcast ，最近还出现了Flutter Dev Podcast-这种“萌芽”是如何发生的？-最初，我是最重要的Flutter巨魔。 那些曾参加GDE峰会的人不会让你说谎。 我直接告诉了Google的主要经理：这是一种什么样的手工艺品，如何将其放在我们认真的成人Android旁边？
但是，在我说完所有这些内容之后的几个月，我自己亲手尝试了所有事情，看了看自己能做什么，并意识到这根本不是玩具。
最初，我们认为存在某种虚拟机，即JavaScript。 然后事实证明，所有内容都被编译成本机代码，并且在两个平台上都可以快速运行。 同时，对于这样的实验平台，调优已经足够老了。 事实证明，Dart语言还不错。 是的，这不是我们所熟悉的Kotlin，而是一门非常成熟的好语言，具有现代编程语言的所有魅力。
我改变了主意，很明显Flutter有前景。 甚至React Native，Xamarin和其他第三方框架也已经传播开来，并且在这里Google得到了支持，甚至有关于新的Fuchsia操作系统的传闻，该操作系统将首先使用Dart和Flutter。
但是我们不会在Android Dev Podcast中涵盖所有Flutter新闻。 然后我想到制作一个单独的播客会很好。 我转向大学时代的老朋友珍雅·萨图洛夫（Zhenya Saturov）说：“您想采取主动吗？ 我不会播第二部播客，但是您还年轻，也许您会接受。” 因此Flutter Dev Podcast诞生了。
-当同一家Google公司同时开发本机Android开发和Flutter时，对于新手开发人员来说“可能，我应该去哪里”可能还不清楚。 对您来说这似乎是一个问题吗？-如果初学者不能决定，就让他们立即着手Unity上的游戏开发！ 但认真的说，有一种描述的效果，但是Google一直坐在两把椅子上：Web和本机。 Google也正在开发类似Progressive Web Apps之类的东西。 似乎有本机平台，为什么您要忙于PWA？ 此外，还有诸如WebAssembly之类的计划，它与浏览器中一切可能的执行有关（Google最初来自网络世界）。
因此，Google并不是第一次为解决同一问题的不同类别创建不同的工作。 这是一个巨大的庞然大物，里面有许多不同的小公司在互相斗争。 因此，一家公司内部存在竞争也就不足为奇了。
-继续播客主题：Lyft公司（您在其中工作）今年拥有自己的移动开发播客 。 你与此有关系吗？-他们是在我到达之前开始的：公司要播客时，并不是“记录，布置”，而是一个漫长的过程，就可以谈论的话题达成共识，而不能谈论的话题。 但是他们答应邀请我参加这些主题之一（他们没有给主持人打电话）。
关于移动开发的播客很多-最近出现了
另一种俄语。 我认为，越多越好：想要成为顶尖人的素质更高。 但是很明显，听众必须消耗越来越多的材料。 mitaps，会议，报告平台也是如此。
-还有一个与Artyom Zinnatullin一起的Context播客，由于您现在正与他在同一家公司合作，所以问题是，您是否想以某种方式联合起来。-据我所知，由于工作量很大，Artyom已经错过了某些版本的Context。 但是他也很高兴地在Android Dev Podcast中找到我们，这完全取决于主题。 Artyom不编辑版本，但带有专家意见。 我经常喜欢进行编辑，在这里我们做的是完全不同的事情。
-当您在国外居住时从事俄语播客时，是否感觉像是两个平行的生活，您的播客在工作中没有被聆听，而在播客中，他们只能从您的语言中了解到您的工作中的某些内容？-在新加坡，没有这种感觉，但是在美国，确实感觉到这是两个不同的世界。 在俄罗斯，他们认识我，我的名字已经有分量。 在美国没有人认识我，因此在回答“我有播客”一词时，他们问为什么他们没有听到。 因为他是俄语。 当然，我在这里输了。
因此，我个人的主旨是制作播客的英语版本，多说英语以扩大受众。 我们在俄罗斯讨论的内容与西方国家一样重要，有许多空缺。 在我看来，我们在播客中提出的主题很适合在这里进行更多地介绍。
-讲英语的听众已经拥有Fragmented之类的播客-您认为Android Dev Podcast可以提供什么，而他们没有？-我一直想相信我们离听众更近了。 我们不努力做到客观，通常我们的个人观点仍然是公开表达的个人观点。 但是与此同时，这种意见在我们背后也有丰富的经验，我们的发言并不感到尴尬。
也许在西方国家，这种情况不会持续下去，所以“零散”是一个更加精致的播客，那里没有足够的背景，细节和困难（很多人根本不了解）。 为了吸引更多观众参加试听，一些播客删除了复杂的话题进行讨论。
-不谈论播客，而是谈论Android开发，您是否感觉到美国和俄罗斯之间的显着差异？-我是这样。 我还没有准备好做出严格的判断，但是主要的感觉（不像新加坡那样难）是每个人对其职业和技能都非常不感兴趣。 在这里，当公司在同一平台上有许多开发人员时，人们只是坐着做他们的任务，因为对他们来说Android不是他们的生活，不是他们的热情，不是他们的爱好，而是他们必须执行的任务列表。
大规模的移动开发
-您在一家拥有一百多名移动开发人员的公司工作。 他们是否不断问这个问题：“您在大约一个屏幕上有一个应用程序，那么这样的人群在那里应该做什么？”-我本人最初是对此询问的。 当您了解所有这些内容时，答案就来了。
首先，我们不能说我们有一个单屏应用程序。 首先，有两个应用程序（驾驶员和乘客），然后，如果我们谈论乘客体验，那么我们有一个应用程序涉及汽车，踏板车，自行车，自动驾驶汽车以及针对不同地区（付款和用户）的不同芯片。
其次，规模带来许多困难。 有很多工作与思考指标，创建实验，跟踪以前的工作进展有关。 数百万用户的规模影响了开发时间，现在我对此有了更好的了解。
我们分为几个小的跨功能子命令，每个人都负责一个部分。 有人负责这次旅行，有人负责自行车和踏板车，这就是形成二十多个不同的团队的方式，其中有两个或三个开发人员。 我负责与用户标识有关的部分。 我希望看到另一位同事出现在这部分中，从而增加我们的总柜台数。
如果我们谈论的是小型应用程序的开发人员，这些开发人员在我们的读者中名列前茅，那么事实证明，我们只是在一个大的内部包含了十几个小型应用程序。
在许多大型应用程序中，情况也类似。 当我们首先制作MVP，然后将其带入良好状态时，分为功能团队和度量驱动的开发（由度量驱动一切，度量方法驱动开发），以及启动方法：对于某些产品，它以整个产品的形式存在，对于某些人以内部特征的形式。 甚至Google都将其小型团队置于一种像初创公司一样的方式，并试图最小化官僚主义和漫长的开发周期。
-在这种情况下，特定员工的工作是什么样的？ 您能谈谈您的一些繁重任务吗？-我花了两个月的时间来创建用户个人资料，尽管这本身并不困难。 屏幕本身是新的，以前用户没有配置文件，只有设置。 除了需要整理成品外，事实证明，从体系结构的角度来看，某些组件还不够用，这使我进入了体系结构，以帮助他们。
我还决定尝试使用Dagger，这也花费了时间。 还需要考虑指标，建立仪表板，收集对实验成功的分析，这需要时间。 然后，我开始将现有屏幕从设置添加到配置文件的内部屏幕并进行更新。
根据“侦查规则”进行更新需要重构所涉及的内容。 重构最新的架构也花费了一些时间。 另外，我们有一个设计系统，并且某些组件未从最新批准的元素中实施。 我等了写这些元素的团队之后，我采取了行动，并帮助他们将工作复制到他们身上，以免受到阻碍。
在这一切之中，形成了两个月的工作，乍一看似乎需要几个星期。
-当您想在任务中进行“与匕首的实验”时，是否鼓励进行此类实验？-取决于工程师的水平。 我认为，如果他是入门级工程师，那么他和经理就会清楚地了解到，他不会被任何建筑实验所干扰，因为他本人对此仍然很环保。
从经验丰富的工程师那里，他们有责任直接为广泛的领域做出贡献：整个组织范围内，或至少在整个应用程序范围内。 因此，无处可去：即使从事建筑不是很有趣，但是想要发展，您也必须将生活与不仅仅是功能联系起来。
-如果您进行了试验，但结果成功了，那么它将成为一项通用政策，还是可以保留在团队中？-很少保留在一个团队中。 通常，如果有人开始进行实验，则这与核心架构团队立即一致，并且随后被视为一般的良好做法。 例如，现在有两个团队正在与Redux并行进行试验，以了解我们当中谁将获胜，谁的解决方案将更通用，并且我们将开始在整个公司中使用它。
-当您不编码但做一些相关的事情时，团队人数的增加也是“文书工作”的增加。 显然这是必要的，但是与他在一个小项目中“表现”的方式相比，这会使开发人员的速度减慢多少？-再次取决于工程师的水平。 如果工程师是中级或初学者，则无需编写大量文档，他可以在高级工程师的监督下坐下来并弄清楚特征。 但是，与其他公司一样，高级工程师已经开始承担管理职责。 如果这是一家初创公司，他无法与老板交谈，或者如果这是一家大公司，他不能为他的经理写文件。
-当您为出租车创建Android应用程序时，问题和当前问题是否与其他大型应用程序相同，或者您有自己的详细信息？-我们面临的问题非常相似。 例如，多模块组装问题使基础架构工程师每天都感到同样的担忧，因此Uber，Facebook，Airbnb和Lyft使用相同的Buck构建系统也就不足为奇了。
其他人也在看它，达到了我们的规模，这证实了问题是相同的。 同时，发生相同的过程-例如，所有过程都缓慢地变为反应性。 好吧，有人比较保守，有人仍然有回调，没有反应性，甚至没有Kotlin，因为开发人员的规模和资格不允许这样做。
与独联体国家不同的是，我们经常互相说：“来自Gradle的人，有帮助。” 就是说，尽管CIS使用了Valley语言编写的工具，但在这里我们也不断地相互交流。
Google正确吗？
-最近，杰克·沃顿（Jake Wharton）对Google的Android开发解决方案提出了许多批评，您对此表示同意。 您认为Google到底在做什么错？-讨论中没有必要调用ViewModel并将上下文放入其中。 我认为，与此同时，许多人也会同意。 我感到非常沮丧的是，许多人认为Google的库是不可否认且最正确的资源。
候选人参加了我们的采访，十分之九使用Android体系结构组件来解决我们为他们设置的任务，以描述他们将编写的应用程序的设计。 在这里，我不能不同意Jake所说的ViewModel存在争议的问题，尽管每个人都非常喜欢生命周期。
至于数据绑定库，Android Summit是今年秋天的指示，在炉边聊天中，十分之五的问题是关于数据绑定不起作用的。 该工具太强大了，以我个人的观点，对于多模块和快速组装它从来没有想到。 但与此同时，每个人都把他当作真理。
实际上，它非常方便，但是我认为Google并未分配足够的资源来继续支持它。 然后社区迅速响起：他们信任Google，但是我们没有得到足够的支持。
“有些人对Google的许多解决方案只是在最近几年才出现的事实感到不满：“晚餐的好汤匙，您已经呆了很多年，社区已经发现了，现在您已经醒了。” 您如何看待？ 公司为什么要这样行，这是不好的吗？-我从预算分配的角度以及从一些单独的高级管理人员的战略角度来看这一切，这些高级管理人员以前具有一种观点或只是其他人，但是现在他们已经改变了，采用了不同的方法。
也就是说，这不是Google，而是由Android资源分配团队中的几个决策者组成。 因此，他们得到了想要做到这一点的资源，devrel和库开发人员-Google提供了解决方案。 他们出现绝对是一件好事！ 对于一个无条件地相信他们所告诉的事情并且不进行任何严格评估的社区，我感到不高兴。
-Google在有关Udacity的最新Android开发视频教程中，提供了每个人都需要的基本内容以及诸如数据绑定之类的解决方案。 您是否看到这样的问题，即不熟悉上下文的初学者会认为它们是不争的事实，而不是可选的选择？-关于Udacity的视频课程是一个单独的故事。 自2016年以来，我就在那里开始熟悉Android课程，当时我们为他们开设了第一门Study Jam课程。 总的来说，那里一切都进行得很顺利，基本情况也得到了很好的解释。 但是，在本课程的八节课中，有两节处于中间-不可消化，不可逾越，非常复杂的ContentProvider主题。 为什么初学者会知道ContentProvider的结构，但在2016年尚不清楚。
我仍然对它们如何构成主题和强调口音有疑问。 因此，现在所有的东西都混在一起的话根本不会令我感到惊讶。 但是，值得赞扬的视频课程通常总是一个复杂的话题。 一旦您将它们淘汰，它们就会过时。
准备高质量的材料非常困难。 社区中有很多地方，您可以获取新鲜的更新资源以及对正在发生的事情和如何进行了解。 但是，如果初学者阅读了我们-在任何从事移动开发的公司中工作，那么您将立即被教会如何正确做所有事情。 通过口口相传，或多或少相关。
-在这里，初学者会遇到一个问题：“如果您还没有花一年的时间来学习，那么没有经验，该怎么办？”-这是一个很好的问题。 我相信，许多适当的公司都会在不了解任何框架的情况下接受计算机科学的基础知识。 因为您总是可以找到框架，并获得有关求解算法的基础知识，所以很难获得面向对象编程的知识以及足够的判断力。 这是基础。 有了基础，您就会被带走。 如果您也有英语，那么通常为您敞开大门。
-以前，您对Android Things平台感兴趣，而最近，一切对她来说都变得很难过。 我们应该从历史中得出什么结论？ 您永远无法完全信任大公司，并且您需要使用任何平台以期望明天不会成为现实吗？-结论-我们需要监视趋势。 今年不是出现任何趋势的第一年，任何电子设备，无论是真空吸尘器还是微波炉，都开始从云端进行控制，好像我们偏执的人对此并不感到难过。
Android Things作为一个平台，对于简单的Android任务而言过于繁琐，但是从云或某种机器学习的角度来看，这并没有太大帮助（同样由于性能问题）。 这表明Android Things并不是很酷。 但是我本人直到最后才相信这个平台至少可以解决Kickstarter的铁片停止更新的问题。 Google至少会更新操作系统并发布安全补丁。
, : , Google Cloud Next , IoT Google - , — .
— , , . ?— Telegram- , , TikTok —
, - — . — . — , .
— , . , , .
— , TikTok ?— - , - , . , , — . , .
— 90 Seconds, — ? ?— . , . , Telegram, WhatsApp Google Docs, . B2B-, , . , , , — .
— , , . Twitter, — , ?— , , Telegram. , . , Twitter.
— : Mobius?— , . , over engineering, , .
, , , 60 ( Android). — , . , «2-5 2 » .