将移动团队增加10倍会出现什么问题？ 由于什么原因，在同一家公司中，Android开发人员更喜欢使用知名的库，而在iOS中，他们经常编写自己的解决方案？ 金融科技中的移动开发人员的生活如何？
金融技术中心参加了我们的Mobius会议，在这方面，我们请了两名CFT员工：
Kirill Zuev负责iOS，
Mikhail Emelyanov负责Android。
文本变得如此扩展，以至于我们甚至组成了目录，这样可以很容易地转到特定部分：
关于公司
JUG.ru集团：介绍性问题：向我们介绍该公司以及您在公司中的个人经历。Kirill ：由于CFT业务领域非常多元化，因此无法简单地说出。 但是，请尝试对最受欢迎的产品和服务进行“大刀阔斧”。
CFT已经在俄罗斯金融科技市场运营了30年，我们说，当这样的概念不存在时，我们就进行了金融科技。
如今，CFT为大量各种金融组织，保险公司，国有公司和零售业提供软件的处理和生产。
这就是“金冠”生态系统，其中包括b2c和b2b格式的服务池：在线货币兑换，现金和在线汇款，贷款还款，会员计划，运输和社交卡。
“ KartStandart”处理中心：发行和获取万事达，Visa和“ Mir”支付系统的卡。
联邦系统“城市”汇总了数以万计的各种服务：从支付幼儿园和公用事业到支付税款和补充运输卡。
Faktura.ru网上银行服务已被130多家银行使用。 CFT自动银行系统被更多不同的组织使用。
CFT拥有大型的R，D，ML和AI部门，这些部门已集成到公司几乎所有领域。 我们拥有强大的信息安全团队。 总体而言，在过去的26年中，有3000多人忙于解决金融科技任务。
CFT的“年轻”产品之一是基于“金皇冠-汇款”服务（已有16年历史）的，它是“网上汇款”，这是我们于2016年推出的一个方向。 今天，它是CFT中移动开发的机车：总共有70个人在iOS和Android上进行开发。 而且这个数字还在继续增长，我们计划在今年年底之前增长到数百个。
Faktura.ru系统“城市”中的“预付卡”部门（他们正在开发针对“玉米”，“直线”，“卡里”等卡的解决方案）中也有移动方向。
我和Misha只是在“在线汇款”部门中，从事团队开发，扩展和开发过程介绍。 最初，我们在“预付卡”总局工作，团队规模很小，平台丰富，我们一直生活在2014-2015年的概念中。
Mikhail ：当每个人都坐在同一间办公室时，他们会工作，进行交流。
Kirill ：如此规模的暖灯团队，可容纳10-15人，同时考虑到所有因素-测试和后端。 现在，我们面临新的挑战。
迈克尔 ：是的，组织10个开发人员的工作是一回事，而组织50个则是另一回事。 这包括开发，团队扩展，专业发展和项目本身的所有过程：如果我们的工程师解决了技术问题，我们将参与项目体系结构的开发。 我们正在寻找会干扰该项目扩展的问题，并尝试以各种方式解决它们。
JUG.ru集团：我们将回到增长问题，但现在告诉我：CFT中的移动开发与其他公司有何不同，有何相似之处？ 对于从未在金融科技领域工作过的人，您需要了解什么？ 在面试阶段您是否需要任何特殊知识？Kirill ：当我们与来自外包的候选人交谈时，他们渴望在产品团队中工作，并且渴望稳定。 但是他们总是担心：金融科技是一种沼泽，受到严格的监管并被安全性所包围，从开发者的角度来看，在其中从事自我开发会感到不舒服。
我们总是说，在我们的案例中，移动开发与任何市场产品开发完全相同。 金融科技不是一个用来描述生活方式的词汇，而只是一条工作线，这是我们每天都要面对的事情。
这些是相同的移动银行客户，各种支付，非接触式支付服务等。 但这并不意味着您需要任何特殊技能或知识：任何很酷的移动开发人员只要有兴趣就可以开始从事金融科技业务。
当然，我们只需要基本知识就可以了：银行卡是什么样的，什么是银行帐户。 但是，如果掌握了更深的知识，则可以更轻松，更快地了解分析师的意愿。 有些开发人员不仅想了解“如何完成任务”，而且还想了解“为什么”。
还有其自身的特殊性，例如以中央银行为代表的监管机构的要求。 但是，通常，在业务需求中已将所有这些因素考虑在内，足以阅读它们，提出必要的问题，一切都会很清楚。
从信息安全的角度来看，有某些观点是可以理解的：金融科技是关于安全的。 但是我不能说移动开发人员是第一道防线。 尽管如此，金融科技产品的设计方式还是在后端和数据存储方面都是安全的。
是的，碰巧的是，开发人员来自一家初创公司，并开始说可以更好地设计API：他们说，在这里您可以提出一个请求，而我们要提出三个请求。 但这是由于以下事实：API的设计方式是不提供全部信息。 当开发人员了解这是工程决策，而不是开发人员的愚蠢举动时，他立即接受了。
从移动应用程序的安全性的角度，我们对过去的Mobius进行了报告。 我们没有在那发现美国，也没有表现出黑客手段，但显示了一份清单，表明金融科技应用程序开发人员必须经过检查，以免犯傻的错误：
我们不提交它们，因为进行了代码审查，并且安全团队提出了一些建议，这些建议使我们成为了出色的检查清单。该清单指出了应该解决的漏洞以及由谁（在商业智能，后端开发人员，移动开发人员或测试人员方面） ） 所有这些责任领域对我们都是众所周知的，我们只是遵守规则。
重要的是要理解，我们不仅看到无聊的罐头，而且还试图将自己的面孔转向包括技术方面在内的客户。 因此，我们始终致力于非接触式支付等创新。
2018年，我们的iOS“银行”在“每日银行”类别
的Markswebb排名中
分别位居第四和第五。
我们正在努力成为一个“不羞于向妈妈展示”的应用程序，可以供远离智能手机的人以及对技术了解很多的人使用。 为什么有些移动银行成功，而有些却没有？ 因为它们是用动画技术制作的，甚至可以使用某种文化参考。
迈克尔 ：我要简短地补充一点，我们确实专注于客户-走在街上的人们。 由于我们以金钱来进行运营，因此我们努力使它们尽可能地易于使用，并为人们带来便利。
同时，当员工来找我们时，他们需要了解真正“为人做事”的目的不是在膝盖上乱涂“如我所见”。 在CFT工作之前，我几乎是在没有设计师的情况下亲自完成了几乎所有的设计和UX。 但是公司不适合我们。 有一个由设计师进行实验的整个UX实验室，并且有测试假设的焦点小组。
当一个人来找我们时，他必须明白，一切都将集中在使客户更容易使用该产品上，以免在填写50个字段的表格时死亡。 工作集中在最终用户的需求上。
第二是代码质量要求。 我们对质量，审查，整洁的体系结构，在所有层上应用SOLID原则都有很高的要求。 为了时间而牺牲质量对我们来说是无法接受的。
这与现代技术相邻，没有落后于该行业。 现在，所有Android产品均使用Kotlin编写，而iOS使用Swift编写。 在Android中，在某些项目协程中使用Rx，Dagger。 当新开发人员来临时，我们会定期征求反馈意见，以了解人们的喜好。 而且我不记得员工抱怨过时了，并提出要更改某些东西。 我们只有时间提出想法，“让我们在这样的模块中尝试MVI”，每个人都开始产生想法。
当一个人加入我们的团队时，他应该准备了解现代技术体系并能够驾驭它。 我们对此表示欢迎。 也许这甚至是一个悖论：一个人去金融科技，发展银行业，期望保守主义，而他必须知道Rx和Kotlin如何与所有好东西一起工作。 在我看来，这是一个独特的功能。
移动团队的成长
JUG.ru集团：您已经说过您正在解决随着团队成长而出现的问题。 有具体的例子吗？迈克尔 ：例如。 当团队中的六个人进行一次请求评估时，一个请求中有3-4人进行审查，他们很快就通过了（特别是如果人们在同一个办公室中）。 当员工在不同城市和时区工作时，情况发生了巨大变化，并且团队不断壮大，并且内部出现了单独的单元（由一个团队负责人组成的开发团队）。
我们注意到，随着审阅者数量的有机增长，拉取请求已经开始长达5-6天。 这是一个问题：我们无法按时向企业交付功能。
git flow还存在一个问题：如果您坐在一个分支中花了很长时间，那时另一个团队也可以在其他分支中看到2-4个功能，然后所有这些在发布日期之前就冻结在了分支中，我们会因为合并冲突而感到痛苦。
第二个问题通过更改git flow解决。 他们开始应用基于主干的开发方法，即直接涌入开发分支，废弃的要素分支。 但是由于倾倒无法正常工作的功能是不可能的，这将破坏项目，因此我们应用了功能切换方法。 从而将为发布分支发布功能的期限缩短了几天。 我在Twitter
@mobileunderhood上谈论了更多。
审查存在问题。 以前，大约有4-5个人参加了我们，因为代码的质量对我们很重要，因此我们对质量有严格的原则和方法。 我们担心，如果我们减少评论者的数量，我们的质量将会下降。 在这种情况下，例如，对于50个开发人员，有30个进行了质量评估，其余的是尚未开发出真正技能的初级开发人员或中级开发人员。
因此，我们采取了不同的方法，并提出了公式“ 1位主管+ 1位高级开发人员+ 1位任何开发人员”。 首先，我们在团队框架内使用此公式：例如，“ A”团队的开发人员发出拉动请求，并与策展人和一些单独的开发人员进行审查。 一天半的时间里大约出现20项请求请求：如果早上我们对所有人进行审核，那么到第二天的中旬，将有大约20项新请求。
但是我们遇到了另一个问题。 如果开发人员不断放置他的线索和另一个团队的相邻线索，那么线索将变得超载。 他们较少参与开发，并花费更多时间进行审查。 如果定性地处理大约20个请求，则是一项艰巨的工作。
我们走得更远。 他们为审阅者留出了三个空缺，保留了相同的角色（技术团队，高级开发人员和任何其他角色），但没有理会应该是您团队中的人。 现在，我们可以在一天之内进行拉取请求，最多为一年半。 没有更多的长篇小说。
所有这一切都与功能切换结合在一起：开发人员使用功能时，首先要在代码中创建一个禁用标志，以使它处于冷启动状态。 然后开始开发。 无论团队位于哪个城市，所有这些都可以在一天之内完成。
一个带有时区的单独故事。 如果我们在圣彼得堡提出拉动请求，我们将在晚上进行捐赠，然后在新西伯利亚+4小时进行捐赠，而当我们又有一个夜晚时，他们已经在早上观看拉动请求。 他们下班了-我们得到了他们的请求并进行观察。 事实证明，恒定的连续流在其中时区起作用。
Kirill ：是的，回到关于公司的问题：除了拥有超过3,000名员工的事实之外，我们的开发中心还位于三个城市（托木斯克，新西伯利亚和圣彼得堡），并且在其中分布了移动团队。 延迟四个小时有点复杂，但是公司的总工作时间延长到12个小时。
迈克尔 ：时区不仅提供评论，还可以提供更多帮助。 我们已经形成了一个Android开发项目，在不同的城市中没有任何事情是分开的。 我们的团队是跨职能的，但根据平台的特性而团结在一起，成为社区。 存在标准，一般原则和公认的实践，包括代码样式等。 因此，如果突然出现需要热修复或其他紧急措施的问题，我可以雇用那些现在有工作时间的人，即使他们最初不负责该代码。 我们睡觉时，其他城市的人们都可以提供帮助，反之亦然。
JUG.ru组：随着团队的成长，没有开发人员已经知道整个代码库，或者很容易从附近的人那里弄清楚任何事情。 在这种情况下，可能会出现另一个挑战：记录保存？Kirill：值得一提的是：当我们计划团队增长10倍时，我们意识到我们不会发布10倍以上（甚至7倍）的功能。 随着这种增长，仅为了保持以前的质量水平，就需要付出更多的努力。 对于新开发人员来说，练习之一就是在开始做某事之前先编写文档。
因此，在短时间内，我们在文档中介绍了该应用程序的关键组件。 他们开始让琼斯加入这样的组件，因为有了这样的文档，已经有可能进行代码审查和测试。 这是“延迟排气”变焦。
一年过去了，我们已经准备好了基础，现在我们将一年前来的开发人员带到了完整的生产力水平。 我们走得越远，就越容易。 基于创建的文档，我们使用组件的结构和交互以及与主要服务的集成来构建清单，现在所有这些都不会引起恐慌：“我来这里编程，您在这里有一家企业。”
迈克尔 ：我会补充西里尔。 在团队拥有30多名员工之后，有一段时间，团队负责人和高级开发人员将大量时间花在一个或两个受监督的开发人员上，因为他们不断地传递信息。 我们事先了解了这一点，并开始采取行动。 因此，Android在Confluence中分配了一个单独的空间，不仅在该项目中，而且在其他项目中，都收集了开发的所有原理，实践和约定。
当员工加入团队时，他首先坐下来研究我们如何进行开发，有哪些规则和实践以及项目的体系结构。 他甚至在学习时都不会讲代码。 然后回答控制问题。 没有安全问题的任何培训都不够有效。
现在，我们走得更远，正在创建Galileo自动化培训系统。 它的本质是从发展和方法论的原则，从建筑学的原则到科特林语言的原则，在教育的几个层次上进行。
经过这样的沉浸，一半的问题被扫除了。 潜在客户之前所做的事情现在已经自动化了。 当开发人员直接在一两周内投入生产时，他会提出尖锐的问题，这不是问题。 在此之前，确实存在问题。
我相信，即使该项目是针对10个人的，您仍然需要提前准备文档。 不要碰到这个问题，而要制定一些原则。 将会进行扩展-不会，而且无论如何，当新开发人员到来时，文档消除了很多问题并节省了很多策展人的时间。
我们有平台文档（适用于Android和iOS），并且有项目（业务场景等）。
基里尔 ：我们转向了一些众包。 当新来者到达时，他们对他说：“看，这是第一天要阅读的内容，第二天是要阅读的内容。” 在那里进行设置，提供各种访问权限，工具等。 如果一个人遇到问题，他的任务之一就是将问题写在下一个新来者的相同检查表上。 这样的事情立刻实现了不同的目标：我们还为下一代准备了文档，并教会初学者记录他所做工作的价值。 而且他不怕写什么。
特别热心的人立即开始绘制UML图，这是值得鼓励的。 一旦有人树立好榜样，每个人都会参与其中。 而且我们没有殴打任何人，因为我们知道需要时间，所以我们给了这个时间。
第三方图书馆反对内部发展
JUG.ru集团：我想在iOS和Android的背景下再谈一些“内部厨房”。 据我们了解，您在iOS上有拒绝第三方解决方案的政策，但Android最初也尝试自己编写所有内容，但后来放弃了。 怎么了迈克尔 ：Android一直以来都是这种方式。 2013年，当我们为Kukruza卡制作手机银行时，几乎没有Android开发中的体系结构和库标准。 甚至Google本身也不知道应该在哪里开发Android。 我们在没有Android 5的情况下开始开发，我们将KitKat 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中的Michael 写道： “我们将完全离开Java，我们将在Kotlin上重写所有内容”。 通常，即使已经用Kotlin编写了新代码，Java中现有的代码也会非常缓慢地更改，并且可以在生产中保留很多年。 您为什么决定更积极地这样做？ 您是否像在iOS中一样积极地摆脱了Objective-C代码？迈克尔 ：我一直很喜欢Java。 我一直爱她，甚至通过了Oracle证书，她对我很好。 但是Android中Java的开发和企业中Java的开发是两回事。 几年前，当Kotlin刚刚起步时，在没有库的情况下以裸露形式使用Java的情况开始出现。 冗长的结构，一点句法的糖，这里有一些C＃的同事也扔了他们所拥有的东西，但是我们没有，这通常会使人沮丧。 我想编写运行逻辑的代码，并花费更少的时间自己编写代码，使用更多的东西，更容易理解和阅读代码。
然后是龙目岛之类的东西。 起初我喜欢它，然后就停止了，因为它是一种额外的库，可让您简化代码，将其包装在语法糖中，但这只是一个插件，而不是Java编译器本身。 而Kotlin数据类和具有所有属性以及get / set封装方法的常规Java类则完全不同。
我们很长时间以来第一次决定在一个项目的级别上尝试Kotlin。 我们写了它，有些事情使我们感到困惑-好吧，Kotlin和Kotlin，我们尝试了一下，好吧，有一个项目，我们回到了Java。 他们回来了，一段时间后，我意识到我不能再用Java进行开发了。 就是这样，我已经厌倦了她，再也看不到她了。
显然，我已经习惯了一些语法上的事情，以最小化代码。 最后，我们决定需要使用Kotlin。 更好地感知和阅读。 一些开发人员反对它，但是在我看来这是一个习惯问题。 引入的实践：在Kotlin上编写新项目。 以前的项目仍保留在Java中。 但是当进行一些重大的重构时，我们将所有内容都复制到了Kotlin。 我们已经获得了快速执行此操作的经验。 这并不意味着我们用热键将Java文件转换为Kotlin，然后修复了此代码-我们自己立即以Kotlin风格重写了它。
实际上，还剩下两个Java项目，并且过渡也在逐步进行：用Kotlin编写新的模块，用Kotlin编写新的测试，以及用Java编写旧的逻辑。 如果逻辑由于重构而改变，我们用Kotlin编写。 这些项目之一现在正在经历大量重构。 因此，我们将迁移工作推上了流水，而使用Java两年后，实际上只有一个半项目。
没有人特别反对。 当然，有人对“科特林只是炒作”表示怀疑，但是当Google正式认可科特林进行Android开发时，它对我们大有帮助，对我们而言这只是一颗炸弹。 不再需要说服工程师：要么您是所有现代开发人员的潮流，要么是在这个市场之外。
Kirill ：和Swift一起，第一次会议是这样的：我需要为我们在新西伯利亚举行的一次会议做一个小型展示，当我在Objective-C的屏幕上显示一段代码时，很明显在任何屏幕尺寸下都无法读取它。 然后，我在Swift中为演示文稿编写了这段代码，尽管项目中没有一行“ swift”行。
然后，我们尝试了Swift，从头开始编写了Golden Crown Transport Card项目。 我们在那里跑了一些语言。 有趣的是我们做错了什么，开始着手创建自己的样式指南。 从第二个Swift开始，我们也“移动”到了第三个，took了一口悲伤，然后困扰着所有人。
而且，如果您看看我们现在拥有的拉取请求，那么其中95％的Swift代码都写在这里。 我们没有一项艰巨的任务，不惜一切代价将所有可用的代码从Objective-C转移到Swift。 不过，Swift代码在Money Transfer移动应用程序中的份额为60-65％，我们发布了“快速摘要”，在其中我们绘制了一个Swift / Objective-C文件，代码行的图形，具体取决于发布和日期一切都可见。 65％的份额并不意味着我们复制了10个文件中的6个-主要是由于新文件的增加。
我们尝试了不同的过渡技术，例如，在Corn卡的移动银行中，我们进行了单向过渡（即，我们的Swift代码基于Objective-C，但我们没有将Swift构造转移回Objective-C）。 我们不会拖延Swift功能来加快以这种方式切换到Swift的过程。 在这种情况下，当它变得非常敏捷且Objective-C代码需要所有Swift依赖项时，我们可以说是该组件完全切换到Swift的时候了。
由于用于Golden Crown-Money Transfer服务的产品比开发速度比简单地增加Swift的份额更重要，因此我们有双向的报道。 从Swift黏着剂的角度来看，它们看起来可能不那么漂亮，但是由于这种方法使产品能够更快地移动。
开发人员在没有任何Swift知识的情况下就来了，该语言在两周内就掌握了，并开始起作用。 有时他们担心我们有60％的Swift，但这没关系，还没有员工无法掌握它的情况。 有相反的故事-当他们发现我们拥有40％的Objective-C时，他们开始说我们正在倒退，您需要首先在Swift上重写所有内容，然后剪切功能。 但是，这里的一切都是个体的，我们将与每个个体一起工作。
在Swift上有混合项目，单向混合项目，干净项目，我们尝试了一切。 一切正常，没有灵丹妙药。
JUG.ru集团：关于Swift和Kotlin，他们说：“因为它们很相似，所以Android和iOS开发人员可以方便地查看彼此的代码。” 您是否有针对不同平台的开发人员查看彼此的代码？Kirill ：我记得有个故事，当用Java编写的Android开发人员在Objective-C上研究iOS开发人员的代码，反之亦然，当时我们为Corn map编写了移动应用程序中最复杂的组件之一-著名的表单设计师，后端驱动的UI架构示例。 通过某种协议与后端之间存在非常激烈的互动，而这样做并非完全是犯罪。 当然，我们偷窥。
现在，我们在应用程序中采用了不同的架构方法，应用程序基于不同的UI架构。 我们可以窥视的最大层是业务层，即使如此，我们还是应该挖掘测试工具的方向，以允许您使用一种编程语言进行编写。
实际上，应用程序是该服务的客户端。 在大多数情况下，它会响应用户输入并显示来自服务器的数据。 在某个地方写完全错误的东西是非常困难的。 从这个意义上讲，也许有一些例子。
迈克尔 ：我有例子。 由于我们现在拥有跨职能团队，iOS和Android开发人员几乎同时在不同平台上执行相同的业务功能，因此彼此之间的检查越来越少，因为没有什么可看的，整个开发过程也很顺利。
但是，当有人同时前进时，这个人就会意识到大多数芯片都已实现，而当企业暗示“看看Android如何完成”，而分析还没有准备就绪时，有时双方的开发人员可以顺便看看效果如何。 在这里，斯威夫特和科特林非常相似确实很有帮助。
在移动底层方面，我分享了我在一个项目中的经验，该项目中我们没有跨职能团队，而是一家用于偿还贷款的初创公司。 而且我喜欢研究iOS开发，这很有趣，他们如何解决某些问题，甚至可能向他们扔东西。 他们喜欢扔我。 而且我们经常会花几个小时坐在黑板上，谈论纯多态在iOS和Android中的外观以及如何烹饪。
谈到某种形式的概念，抽象是什么，一切都相当有趣，并且从通常的代码开始。 您会想：为什么您要这样做，是否会有很多开销？ 他们向我解释说，所有事情都是经过计划的并且有意识地去做，以免例如花费2-3天的时间在sprint中更改此代码，以寻求最佳解决方案。 我认为：聪明的人，我们有时需要这样做，而不是考虑五天的某种内部体系结构，后来发现不需要这种内部体系结构。
结果，我经常上来看看Swift代码。 也看过Objective-C，但我更喜欢Swift。 尽管我没有开发它，但我认为编写代码不会有任何困难。 Android开发人员也有同样的想法。
Kirill ：总的来说，我们不仅仅拥有一个平台团队，在内部我们对他们说：“您是最好的，因为Apple提供了这样的工具。” 来自iOS和Android的人员进行互动，一起参与计划并与系统分析师一起解决问题。
而且，如果他们尝试提出一些不太合适的API，他们还将与后端开发人员一起行动。 在这种共生关系中，他们可以监视存储库中的所有内容，我们拥有开放系统，所有开发人员都可以访问存储库。
在“预付卡”总局中，我们讲述了缝合后端的故事，然后Android开发人员设置了环境，环境并拍摄了一些错误修复程序，以提供帮助。
迈克尔 ：我想起了最近的一起案件。 为了使客户对我们更微妙，后端需要做更多的工作，然后我们的移动技巧一起加入并开始推动他们的总体思路。 他们都聚在一起，讨论了如何在两个平台上都感到舒适，去了后端开发人员，并宣布他们如何更舒适地工作以及违反了瘦客户端的概念。 支持者同意他们的观点。
现在，如果一个平台说：“我们将竭尽所能”，而第二个平台则拒绝，说很难，那么他们将迫使第二个平台以某种方式达成共识并采取行动。 因此，这一切都是一起发生的。 因此，协同作用，团队发展正在发挥作用。 语言确实对此有所帮助。 毕竟，如果Java和Objective-C在语法和原理方面完全不同，那么Kotlin和Swift确实更接近。
西里尔 ：顺便说一句，有个例子说明当伙计们成为切换台，甚至是双切换台，在平台之间切换。 有一个切换到iOS的人，结识了他，“动手了”，然后又回到了Android。 然后他完全离开了DevOps。 在这方面，我们也是开放的，这样的时刻被简化了。
这些家伙甚至在不同的飞机上都想要专业发展，真是太好了。 我们给了机会，他们自己选择了想要发展的方式，几乎我们所有的人都受到产品，他们从事的任务的激励，这非常酷。
JUG.ru集团：最后一个问题：跨平台开发如何？Kirill ：我们公司正在为联邦城市系统开发产品。 那就是选择React Native进行实现的地方。 我们对此并不感到嫉妒，因为进行实验并找出实验的结局总是很有趣的。 此外，我们有一些前端开发人员，他们非常了解自己的业务，尝试一些新的东西并进入新的平台很有趣。
迈克尔 ：我们在React Native上有项目，但这有点不对劲，因为它是由前端开发人员完成的，而iOS和Android开发人员的重叠并不多。
至于跨平台，我个人认为是针对小型团队的：当iOS和Android上的资源很少时，并且需要在两个平台上都完成该项目，为什么不这样做。 我们拥有足够的资源，并且产品技术先进，我们可以为iOS和Android进行单独开发。
历史上也发生过，当我们完成大多数项目时，还没有跨平台。 现在，自然而然地，我们将考虑将业务逻辑和抽象逻辑的一部分划分为通用模块，因为没人愿意做一份工作。 但是从历史上看，我们没有这个。
但是，这并不意味着它将一直如此。 我们有许多业务上有前途的任务和项目，有原型，我们迟早会尝试JetBrains的Kotlin Multiplatform或Flutter，这对我们来说更有趣。
跨平台尚未以工业形式进行标准化，您可以在企业中使用和使用它。 从与跨平台开发人员及其报告的沟通来看，现在存在着持续不断的“掠夺”和问题解决。 因此，您可以接受并提交项目，但更多情况下，这只是与耙子作斗争，而且我认为不能有效地了解业务功能。 最近，在报告中询问JetBrains是否可以在生产中完全使用多平台版本的Kotlin，他们说它仍处于试验阶段。
另一端是Flutter，它在去年起飞，这件事真的很有趣，Google在这项业务上的投资并不弱。 而且我知道在Flutter上有很多宠物项目，这些项目已经在应用商店中进行了布局。 这对我们来说更有趣。 我们对Kotlin有点厌倦，对于Kotlin / Native，我们不得不收集很多耙子，但是Flutter with Dart是一件全新的事情。
我们喜欢所有新事物，因此我们肯定会有跨平台的开发。 汇款应用程序中没有特别说明，但是在一些小型的单独应用程序中会有所说明。
JUG.ru集团：感谢您提供详细的答案！