嗨，我是Skyeng移动开发团队负责人Andrey Kucherenko。 我们为iOS和Android开发移动应用程序。 它们具有与样式完全相同的功能和相同的界面。 但是由于平台不同，看似一个应用程序的开发非常昂贵。 为了寻找节省移动跨平台开发机会的方法，我们尝试了四种解决方案：
- 将iOS和Android开发人员合为一个团队
- 建立工作组以解决复杂问题
- 节省文件
- 编写通用代码
我有机会就此事做几份报告。 在本文中，我收集了主要的观察结果。
将iOS和Android开发人员合为一个团队
两年前，我们有两个单独的移动应用程序和两个开发团队，仅由一个共同的产品经理连接。 随之而来的是很多问题：彼此之间的应用程序仅在远程上相似，它们以多种方式工作，开发人员不知道相邻应用程序的排列方式，他们经常发现逻辑中的各种错误和错误。 在某个时候，很明显这是无法继续进行的，在这方面，我们要做的第一件事是将iOS和Android的开发人员团结成一个产品团队，使许多流程变得通用。
这些过程之一已成为技术审查。
在接触开发人员之前，任务已经完成了一定的工作。 首先，将其以“用户故事”格式进行表述，并在其上绘制草图或布局，然后开始编写史诗，其中描述了用户问题及其解决方案。 以这种形式，如果故事是跨团队史诗，则属于团队领导者；如果属于同一团队，则属于一个团队领导者。 在那里，一切都分解为单个任务的级别。 在每一个这样的任务中，如果合适，将描述一个可能的解决方案，Epic内部的任务彼此链接，并附加各种阻止程序，从而消除了许多不必要的通信。 此后，将直接进行技术审查，最终决定将由该技术审查确定，然后进行估算。 同样在此阶段，如果获得的估计超过两天，则可以进一步分解任务。
我们如何节省联合技术审查的费用：
- 在大多数情况下，事实证明适用于iOS和Android的技术解决方案相同。 也可能有不同的解决方案，这可能是由于平台的体系结构不同而引起的，但是在任务中，差异通常很小。
- 同步两个应用程序的体系结构和结构。 这样就消除了产品具有其他功能时的情况，并且我们在两个小时内评估iOS任务，在一周内评估Android任务，因为所有内容都必须在那里重写。
- 很多时候，我们会得到很好的成绩。 如果我们对平台的评估相差很大，则可能表明开发人员不了解任务，或者表明某些平台问题需要解决；
- 通过这次审查，iOS和Android开发人员之间进行了经验交流，我相信他们应该对相邻平台的工作原理有所了解。 通常结果表明，从一个平台来的解决方案对另一个平台来说是成功的。
- 简化手动测试。 功能是在一个技术解决方案的基础上实现的，如果QA发现任何错误，那么这是在另一个平台上重复相同步骤的机会。 大多数情况下，同样的错误也在那里。
- 通用士兵，能够在两个平台上进行编写：如果是，则可以在项目之间进行切换，这会增加公交车的使用率，并轻松转移休假和缺勤时间。 在假期期间，任何平台都不会遥遥领先。
总线系数：必须降低总线以使项目无法继续进行的团队人数。
解决复杂问题的工作组
为了解决问题，很多时候，除了直接编写代码外，我们还需要进行一些研究，进行设计，并且如果任务涉及团队之间的互动，则需要花费大量时间进行交流。 在移动开发的上下文中，不需要所有这些的任何任务都是微不足道的，不涉及后端的工作。 我称它们为“简单”，其余的称为“复杂”。
我分析了有关在代码编写，通信，设计和研究上花费的时间分配的工作日志。 这是简单任务的结果：
这里的一切都清楚了，基本上我们编写了代码，其成本高达80％的时间。
很多时候，任务需要从后端进行某种改进，这自动使其成为命令间的。 在这里，更多的时间花费在设计和通信上。 代码编写的份额减少了：
通常，产品附带的任务与当前应用程序的体系结构不太吻合，我们需要花费时间来寻找好的解决方案：也许计划一些重构，立即将其作为任务的一部分执行，等等。 在这种情况下，将在设计上花费大量时间：
最后，通常不清楚如何处理的任务，您必须首先在何处进行研究和设计：
如果复杂任务的工作无法以任何方式进行协调，那么与编写代码不直接相关的所有工作将进行两次。 在复杂的任务中，这是解决方案时间的50％，甚至更多。
我找到了出路：我只是把所有这些任务锁定在自己身上。 我设法节省了时间，但是我却变得不知所措，我没有足够的时间来关注低优先级的任务，开发人员不得不等我，一切都很糟糕。 问题再次出现，我们已经通过创建工作组解决了该问题。
该工作组是一些iOS和Android开发人员，他们将直接参与此功能的实现。 一个人被任命为领导者，由他负责设计，研究和与其他团队的互动。 他的工作结果将是形成文件，所有内容都已固定。 然后，工作组和团队负责人将对这些码头进行审查，然后团队继续进行实施。
结果，我们收到了：
- Timlid上的负担减少了，而他并没有失去对任务进度的控制。 我参加了所有关键会议，审查了技术解决方案，在任务直接发展之前实际控制了任务；
- 开发人员非常有动力。 当我们测试了这种做法时，每个人都说“很酷，让我们再试一次”。 没有人愿意这样做，而更喜欢“只是编码”。 人们有更多的发展机会；
- 公车因素增加，团队变得更加独立，加上可以进一步发展为团队负责人的人在这些任务上清晰可见。 解决使蒂姆利达休假的问题。
保存文档
我们决定将文档保留在市场中，并将其存储在github存储库中。 该文档连同代码和请求请求一起进行了修订，因此我们排除了写某些东西但没人读的情况，并且当需要它时，没人能理解的情况。 带有代码的文档使您可以深入了解上下文，以了解pull-rikvest的全部含义。
我们直接从IDE中编辑文档，大多数文档都可以呈现markdown，它不会中断编写代码，您不必走到一起，降低了开发人员将忘记更新的风险。 对于那些在本地下载资源库的人，我们抛出了指向Github的链接，他们也可以阅读所有内容。
最后，这种停靠样式有助于新开发人员的入职：他与代码一起接收所有可能的代码样式，约定，应用程序组装说明，并且更容易进入团队。
通用代码
编写通用代码的想法并不是最新的；有很多工具可以做到这一点。 我们尝试使用C ++编写词汇库，并且有一个完全用Kotlin Multiplatform编写的小应用程序。 从理论上讲，使用跨平台开发工具时，我们的代码编写成本应减半。 但是还会出现其他内容：
启动费用。 在收集，启动，测试，检验假设和培训团队方面将花费大量时间。 在某些情况下，这些成本是如此之大，以至于根本看不到利润。
编写平台代码。 根据我自己的经验，并且基于许多资料，我可以说，无论选择哪种工具，如果您有一个相当复杂的应用程序，则迟早必须编写平台代码。 编写时间取决于所选择的工具。
消除缺陷。 大多数工具还很原始，它们都有错误，您将不得不处理一些破坏向后兼容性的发行版，并且还需要一些时间来解决所有这些问题。
规避限制。 跨平台工具可能会遇到体系结构或其他一些限制，您可能会花一些时间来规避它们。 有时，这样的限制变得如此严格，以至于必须完全放弃该工具。 例如， Airbnb放弃了React Native，然后回滚到本机开发；
开发的复杂性。 您必须一次为两个平台编写代码，而这并不是每个人都知道的，另外还会出现其他通信。 缺少本机IDE也不能简化此开发。
为了比较我们尝试的跨平台开发方法的成本，我确定了四个主要组：
- 起始费用
- 一般代码编写成本
- 平台代码编写成本
- 基础设施成本（不适用于前三点）
他进行了一次洗牌，并比较了实际花费在跨平台开发上的时间和我们应该花在原生开发上的时间。
每列都是任务。 对于C ++来说，这是一个相当容易的开始，但是基础架构成本却非常可观，总共节省了29％。 C ++也被放弃了，因为这种语言降低了总线因素：我们的移动开发人员不知道C ++，他们可以支持代码，但是团队中没有人有任何认真的经验。
新兴企业非常多，但是平台代码和基础架构的成本却很低。 我们没有足够的信息来很好地分析任务的数量，在目前的位置上节省了19％。 假设我们将完成许多任务并放弃启动成本，那么我们将节省大约40％的费用，当然，除非将来出现任何严重的问题。 另一个优点是，大多数开发人员都熟悉Kotlin。
缺点很明显-过程的复杂性。 我们要么立即为这两个平台编写代码，但并非所有平台都可以，或者等到有人编写了通用部分，然后我们对其进行修改，然后发现它不合适，以此类推。 等 我们必须在设计阶段付出额外的费用，以便所有内容都可能立即被清盘。
总计：
- 您可以并且应该节省移动开发流程和代码编写的时间。 正确构造的流程不仅可以节省，还可以解决许多其他任务。
- 在选择用于跨平台移动开发的工具时，您需要仔细评估风险和实际人工成本。