React Native-解决所有问题的灵丹妙药吗？ 我们如何为Profi.ru选择跨平台工具

大家好，我叫Gevorg。 我是Profi.ru的移动部门负责人。 我想与您分享我们使用React Native进行实验的故事。 我将告诉您我们如何在理论上和实践上评估React Native开发的利弊。 本文对那些对跨平台移动开发感兴趣但尚未决定是否采用这种方式的人很有用。

最大加速度

一切始于我们决定将公司级别的开发速度提高10倍的事实。 我们设定了一个不可能的目标，超越事件的常规范围并尝试新事物。 所有Profi.ru开发团队都进行了实验。 当时，该公司有13位本地移动开发人员，其中包括我和两名团队负责人。 我的团队致力于两个移动应用程序。 首先，客户需要专家；第二，客户专家。 对我来说，这段时期令人难以理解，情绪上压力很大。 根据我的感觉，我们做了很多事情，以至于一切都能快速进行。

我们在整个项目中使用了通用架构，并监控了代码的纯度。 使用过的生成器来创建所有模块文件。 他们试图提取后端的所有业务逻辑。 我们设置了CI / CD，并且应用程序涵盖了E2E测试。 因此，某些应用程序每周稳定发布一次。 我什至不知道如何加快开发速度。 到目前为止，只有10岁。因此，我们确定了对我们重要的内容。

1. 统一代码库。 我希望我们所有的移动开发人员都编写相同的代码。 用一种语言，iOS和Android之间没有平台差异。 因此，我们可以将开发速度提高一半。
2. 易于学习的新工具。 这样，在扩展团队时，我们在再培训或雇用方面就不会出现问题。
3. 快速发布。 这样我们就不能每周释放一次，而是每天释放一次。
4. 即时更新。 这样所有用户都可以立即收到更新。 由于它正在Web开发中发生。

简短审查后，出现了三个候选人：React Native，Flutter，Kotlin / Native。 Flutter和Kotlin Native均无法快速发布。 我们认为这也许是最重要的。 此外，这些技术当时还完全是原始的。 我们选择了React Native-它可以立即发布。 另外，我们的大多数开发人员已经使用过React。

总的来说，我对跨平台工具持否定态度-就像大多数本地移动开发人员一样。 参加任何移动会议并谈论它-您将立即被困。 我本人很喜欢这个东西：-)因此，为了确认或驳斥恐惧，我们进行了调查。

优点，风险和问题

我们研究了在不同公司中使用React Native的示例-成功但不是很好。 Borey Egorov与开发负责人一起仔细阅读了三十几篇文章和其他材料。 一些人讨论了每个段落。 在文章的结尾-最有趣的链接。 我们指出了可以加速我们发展的要点，可能的风险和问题。 之后，我们与三家公司的开发商进行了交谈。 他们在每个人中创建了一个批量产品，并与React Native一起工作了至少一年。

有了专业人士，一切都显而易见。

1. 通用代码库。
2. 无线或空中更新，绕过商店。
3. 从前两点可以看出，向用户交付功能的速度将会提高。
4. Web开发人员将能够为移动应用程序编写代码。 如果Web开发人员非常了解React，那么他可以快速学习React Native。 并且，如果移动开发人员已经知道该平台，那么它可以相对快速地进入Web开发。

风险清单更长：-)

第一风险 。 从长远来看，我们不得不使用一种平台，而不是一种平台：Android，iOS和React Native。

有时，开发人员屏幕看起来像这样：



现实性 我们的一名对话者将React Native注入了现有代码。 是的，将会出现一个成熟的第三个平台，但是您不能离开本机开发。 他的团队必须在React Native和本机代码之间同步状态。 这需要在不同的代码段/不同的范例和IDE之间进行大量切换。 因此，他们决定从头开始编写一个新项目，在React Native上建立一个框架，并已经在需要它们的地方插入了原生部分。 好了

第二个风险。 React Native Black Box-有时在某些情况下，开发人员不了解为什么会出现错误。 您必须在任何地方搜索：在React Native代码中，在产品的本机部分中或在React Native平台本身中。

现实性 与我们交谈的家伙用日志和各种工具包装了应用程序：Crashlytics，Kibana等。 问题仍然存在，但是很明显它们出现在哪里。

第三个风险。 在文章中经常发现React Native适用于小型项目，但不适用于具有平台功能的大型产品。

现实性 我们研究了市场上是否有与React Native合作的大型公司。 事实证明-有数十种，甚至数百种。 包括Skype，特斯拉，沃尔玛，Uber Eats和该地区的Kitchen。

第四风险。 每次从Apple或Google升级操作系统时，项目可能会中断。

现实性 我们认为风险完全可以接受。 本地开发存在相同的风险。 当适用于iOS和Android的新操作系统问世时，您就可以对其进行调整。

第五风险。 Android不支持64位系统，并且自2015年以来一直未解决此问题。 从2019年8月开始，Google Play不再接受仅支持32位系统的版本。

现实性 我们研究了React Native团队在2018年夏季工作的问题。 他们承诺将在下一个版本中增加支持，尽管他们尚未完全修复对64位系统的支持。 这极大的难过。 后来添加了支持，但是某些Android设备在过渡后掉线了。 正如我们后来发现的那样，这个百分比很少，但这仍然是我最痛苦的一点。

第六风险。 明天，苹果或谷歌将发布其操作系统的新版本并破坏React Native的可能性。 或Profi.ru原则上将无法支持的新技术。

现实性 我们或许多其他公司都无法保证。 您要么意识到风险并做到了，要么尝试其他方法。 我们决定这样做，并解决所有可能出现的问题。

第七风险。 我们无法提前说出React Native与本机应用程序相比将有多快，以及它将显示出什么样的性能。

现实性 我们其中一位对话者的字面意思是“滚动减慢时高度可变的元素的列表”。 我们决定进行实践检查。 有点前进-在编写应用程序的第一个原型时，我们没有看到这样的问题，但是当我们开发成熟的应用程序时，关于React Native的性能存在很多问题。

第八风险。 目前尚不清楚我们能多快找到React Native开发人员。 在HeadHunter上，尽管有超过15万的iOS开发人员，但我还是找到了大约300份简历。

现实性 他们没有深入研究，因为他们不止一次雇用了React开发人员，并且知道要寻找什么。 我们决定作为最后的手段，我们可以在React Native中对React开发人员进行再培训。

由于移动开发人员不喜欢该技术，因此也存在有人离开团队的风险。 顺便说一句，我是对的。 有人离开了:-(

我已经厌倦了编写React Native，所以下面只是RN :-)

我们改变了什么而没有改变

我们与公司创始人Sergey Kuznetsov和Yegor Rudi讨论了调查结果，并批准了该实验。

我们决定从头开始创建新产品，而不是将其插入现有产品中。 而且-不要触摸我们的客户应用程序。 它已经相当成熟，从经济上讲，根本改变某些内容是没有意义的。 另外，对于我们来说重要的是，客户端应用程序对于iOS和Android都有自己的本机体验。

但是我们想从根本上改变专家的申请。 与客户不同，我们不会为专家对iOS和Android应用程序具有相同的交互体验而感到尴尬。 另外，我们相信，在为专家设计的产品中，我们可以做到没有动画和视觉效果。 但是在整个团队切换到新技术之前，有必要先了解一下它是如何工作的。

进行实验

2018年12月，我们组成了一个由三人组成的团队。 两个React开发人员和一个本地人-我。 我了解Android的工作原理，并且精通iOS开发。

作为实验的一部分，我们希望检查以下几点：

• 即时发布如何在RN中工作；
• 本机组件与RN之间的相互作用如何；
• 我们可以使用本机组件吗？
• RN如何与摄影机，推送和DIP链接一起工作；
• RN中的导航和状态保存如何工作；
• 尽我们所能做到RN像素完美；
• RN中自动测试的工作方式；
• 本机或React开发人员可以多快学会该技术。

在投入开发后的一个半月内，我们获得了第一个结果。

• 两周后，我开始在RN下编写代码。 对我来说，这项技术是完全简单的。 我们的一名React开发人员为我提供了很多帮助-他以著名的方式谈论了React / Redux和JS。 有必要输入React / Redux的复杂性，但是过了一会儿，“神经元开始学习”，正如我们公司所说的:-)
• 令我感到惊讶的是，JS + Flow以某种形式提供了强大的输入功能。 对于JS，我的期望值要低得多。 同时，我绝对会偏爱Swift和Kotlin：对我来说，它们比JS更漂亮，更令人愉悦，但这里的主要用语是“对我来说”。
• 这对我们有所帮助，该团队包括可以为iOS，Android和React编写代码的开发人员。 每个平台都有其特定的问题。 要解决这些问题，团队必须具有跨职能部门。
• 即时发布工作。 对我来说，这就像魔术。 无需等待Apple的发布和升级。 通缉-采取并释放。
• 很多时候项目失败了。 这真的不酷。 您从分支机构获取了更改，尝试运行-没关系。 真烦人。 在某个时候，我们只是编写了一个脚本来彻底清理项目。 这并不是说他们整体上解决了问题，而是解决了大部分问题。
• 尽管如此，尽管我们主要在RN上编写代码，但我们仍必须使用三个平台。 所有开发人员都具有三个IDE：Xcode，Android Studio，WebStorm。
• Pushas，深层链接，摄像头，导航开始。 但是它们要么借助第三方库开始，要么本机代码中的库必须自己编写，然后连接到RN。

在文章结尾，我想回到标题。 那么，RN是解决所有问题的灵丹妙药吗？ 我们自己决定不。 同时，他们得到了他们想要的东西。 我们将功能交付的速度提高了数倍，现在我们可以每天将其发布给所有用户。 同样重要的是，跨职能团队已经出现在公司中，每个开发人员都可以在Android / iOS和网络上编写代码。

是的，商店中的应用程序:-)

关于React Native的有用文章

1. 为什么Discord会坚持使用React Native-方芳（Robin）Chen
2. 我如何爱与恨当地人-Andrey Melikhov
3. 从移动开发人员的角度来看React Native-Andrey Konstantinov
4. Instagram上的React Native-Instagram工程
5. React Native：Udacity移动工程团队的回顾-Nate Ebel
6. React Native：一幕事实战-Samat Galimov
7. Sunsetting React Native-Gabriel Peal