如何建立您的React Native团队。

最近,我与一些成长中的公司进行了交谈,这些公司启动React Native应用程序或正在考虑构建一个应用程序。 他们想弄清楚如何组建一支团队以及之后的去向。 在我上一份工作中担任React Native首席开发人员后,我想就采用它所带来的一些技术和组织方面的问题发表看法。 本文适用于已经决定使用React Native的初创公司创始人或CTO。 我将探讨(1)优缺点(2)如何组成您的团队 ,以及(3)如何进行您的项目


这些观点中有一些已经说不过去了,但是当您为公司做出决策时,请牢记这些观点。

聘请React Native首席开发人员后,您应该再聘请两个对React感到满意的人。 他们不需要具有本地移动经验,也不需要具有特定的资历。 但是,请确保您雇用的是那些致力于构建移动应用程序的人 -不要招来怀疑的Web开发人员。 React Native开发人员的体验并不像Web那样好,他们会很快失去他们的舒适感。

我认为由3名专门开发人员组成的团队应该足够了,但是显然这取决于您公司的成长阶段。 您的主要开发人员可能会花费一半的时间来编写功能,而花费一半的时间来维护项目并为其他开发人员提供支持。

想要给您钱但不打扰信用卡表格的用户。

最重要的是,我将确保雇用一名了解移动应用程序的设计师,而不是尝试利用网络专业设计师。 如果您的用户发现该应用程序难以使用,那么您的开发团队有多出色并不重要。 应用程序的用户体验应该与Web应用程序的移动版本不同。 您不希望它在小屏幕上的滚动视图内有10个输入字段。 有一个了解这一点的设计师很重要。 React Native还使您可以轻松地通过手势和动画来进行创新,因此请一名愿意利用这一点的设计师。

避免让开发人员陷入困境。 我建议您每年至少将它们发送一次。 这是保持最新状态并与知识渊博的人建立关系的一种好方法。 您的开发人员将使用大量将要在工作中应用的新知识,新技术和内部信息来重新工作。 我不确定为什么大多数公司都将发展的责任放在开发人员身上,但是如果您自私自利并想要最好的团队,请投资于他们的发展。


利用您现有的Javascript和Web开发人员。

不要让您的Web开发人员处理Android构建问题。

一旦建立了项目和团队,就可以开始利用现有的Web代码库和Web开发团队。 如果您已经为Web编写了auth和API客户端代码,请将其拆分到自己的项目中,以便可以在您的应用程序中使用它。 您的Web团队的开发人员会为构建移动功能感到兴奋,但是他们会因构建问题或本机层错误而变得脾气暴躁。 让您的RN主管编写非常好的指南,并充当本机层的技术支持。

设置TypesScript。

从ActionScript 3时代起(我很高兴),我就一直喜欢输入ECMAScript,但是我很长时间以来一直拒绝TypeScript,因为它看起来有些痛苦且不稳定。 那已经改变了。 社区看中了打字稿作为输入标准:巴贝尔7拥有一流的打字稿的支持,并作出反应本土57个附带打字稿(击败了̶F̶a̶c̶e̶b̶o̶o̶k̶’̶s̶自己的流)̶(洛伦佐希安德拉- @Kelset,其中一个阵营原始开放消息来源维护者澄清说,带有TypeScript支持的React Native发行并不意味着它得到认可,而是意味着Flow和TS都一样容易集成。感谢Lorenzo!)我知道那里有Javascript纯粹主义者,但是在两年内没有TypeScript进行编码可能会很奇怪。 无论如何,拥有类型是件好事。 现在,投资类型和单元测试将使您免于以后不可避免的重构。 Microsoft的这篇文章向您展示了如何在React Native中设置TypeScript。

建立设计系统

如果您想以惊人的速度前进,请为您的应用程序创建一个设计系统。 设计系统是遵循明确准则的可重复使用组件的集合。 它是开发人员和设计人员之间的协作,以创建共享的UX语言,并有助于创建统一的用户体验。

设计系统对于开发速度非常重要,因为它可使设计人员和开发人员保持同一页面(🥁)。 有时,设计师首先构建屏幕,而不是首先构建组件 。 当设计师专注于整个屏幕时,可能会在间距,字体大小,颜色等方面引入变化。当开发人员不得不从头开始构建整个屏幕时,他们可能会在细节上不知所措(或懒惰)。 如果没有设计系统,随着时间的流逝,更新旧屏幕将变得困难,并且您的应用程序将失去其统一性。

以这种方式工作的团队往往会责怪开发人员不够注重细节。 如果您陷入细节之中,请努力降低设计的复杂性。 将屏幕指定为具有明确定义的准则的组件集合要容易得多。 将设计系统作为参考可简化团队之间的沟通,使每个人都诚实,并加快功能开发。

如果您已经有一个现有的应用程序,则启动设计系统来重新创建您的设计可能会花费很多精力。 相信我,停止您的工作并立即创建一个。 您不知道自己浪费了多少时间。 使用Storybook,您可以轻松地将设计系统从Sketch移植到代码。 萨曼莎·布雷托(Samantha Bretous)(@samanthabretous)在构建组件套件方面进行了精彩的演讲。

建立设计系统后的团队

通用组件呢? Web上的React和React Native非常相似,但是它们之间有一些关键的区别(即

与,CSS与StyleSheet,不同的平台功能)。 通用组件是为在两个平台上均可使用而构建的React组件。 如果您要同时为两个平台构建产品,则可能会选择采用这种方法。 以我的经验,由于两次制作一个React组件并不麻烦,所以我没有必要这么做。 Kurtis Kemple(@kurtiskemple)在MLS期间实施了这些程序,您可以在这里阅读有关他的经验。

设置您的构建过程。

您将需要您的RN主管创建该应用程序的Beta版和正式版。 测试版指向您的非生产后端,并具有最新的更改供您的团队试用。 您可以使用Fastlane自动部署到应用商店。 Gant Laborde(@GantLaborde)撰写了有关设置的指南。 您可以通过使用Github Webhooks在master分支发生变化时自动部署 beta应用程序,并在标记了新版本的情况下发布生产应用程序进一步扩展此功能。

有两种管理生产错误的方法:您可以在发布后进行修补,也可以避免一开始就创建它们。 我更喜欢后者,但是众所周知,狗屎会吸引粉丝。 如果您向用户发布了一个错误并需要立即修复,则CodePush是您的朋友。 React Native通过从捆绑在应用程序中的捆绑包中运行Javascript来工作。 使用CodePush,您可以直接推出新捆绑包,而不必向App / Play商店发布新版本。 这是有限的,因为它只能修复Javascript错误。 如果您有本地错误,则需要完整版本。

运输回归

如果您首先要避免发布错误,请投资Detox进行端到端测试。 我必须处理的最常见的错误类型是回归。 在发布之前,开发中的功能会得到质量检查的最多关注,有时对新功能的更改会破坏旧功能。 当回归被忽视数月之久时,这尤其糟糕。 通过在构建过程中实施Detox,您可以放心,并节省大量质量检查团队的时间。 这是使用Detox进行E2E测试的快速说明和演示。 Rotem Mizrachi-Meidan(@rotemmiz)在这里有更多文章。

关于CodePush的注释:如果使用FastLane自动化发布,则可以使用semver版本控制方案有时通过CodePush进行发布。 次版本的凹凸可以指示一个完整的发行版(也就是您在本机代码中有所更改),而一个补丁版本的凹凸可以指示一个CodePush发行版。 例如,如果您使用的是应用程序版本“ 2.3.1”,则标记版本“ 2.3.2”将获得CodePush处理,而标记版本“ 2.4.0”将获得应用程序/播放商店处理。

不要在星期五下午的时间编码推送

保持应用程序的安全性。

正如我之前提到的,RN仍在迅速发展。 就像野马一样。 您可以骑它并快速行驶,但是如果您不注意它,可能会屈服并留下您。 因此,每个月,当新版本的React Native出现时,您的团队都需要就何时进行升级做出战略决策。 升级是否有您需要的东西? 它会影响您的第三方依赖性吗? 重大更改有多严重?您如何在项目进度中实现平衡? 平台维护肯定要比本机应用更多,但是速度优势远远不能弥补。

我希望您发现本文对于决定使用React Native的地方很有用。 如果您需要更多建议,可以致信rmendiola@alum.mit.edu。