我们知道有一个词叫做主观能动性，表示没有条件创造条件也可以上，这个词的主体就是人，聊完移动端设备现状和社区现状后，我们来聊聊人的问题。RN 在国内真正开始普及使用，是从 2015 年开始，也就意味着，到 2018 年，一个 RN 工程师也就只有 3 年的工作经验，而 RN 的 “Learn once, write anywhere” 也刺激着一切 Care 人员开支， Care 产品研发投入性价比的公司纷纷跳水研究 RN，争抢 RN 人才，RN 是前端中的移动前端，前端有多抢手，那么 RN 工程师就比它还要抢手。

这导致基本上 RN 工程师，很难靠外部招聘，只能靠内部培养，这也是小菜前端的成长历程，我们有 2 名资深 RN 工程师，一个是从服务端 Java，一个是从原生 Android 开发转过来的。如果 RN 人手不足，产品支持的力度和速度就一定会遇到瓶颈，这就是我们曾经面临的问题，就是人才现状，外招数量不足，内培速度有限，RN 工程师的数量和能力就时不时成为公司业务扩张的瓶颈。

4. 【公司现状】高密集业务的交付质量

作为工程师，我们有很强的自尊心和不容挑战的代码洁癖，但在一个创业公司里面，甚至大公司的一个创业团队里面，我们需要对接一些关键的业务节点，冲刺一些特定的时间窗口，并且要及时响应多变的业务，和业务背后多变的产品形态，这都会带来非常密集的需求队列。

这些密集的需求队列对我们的代码实现质量有非常高的挑战，一个组件用 5 分钟思考如何抽象和用 50 分钟思考，实现后的稳定性、兼容性都是不同的，如何保证产品按期交付上线，会是摆在我们面前一个非常关键的命题，而这个难题之外，还有一个更难的命题等着我们，那就是如何保证交付不延期的同时，还能保证交付质量。

要知道，如果一个项目代码赶的太毛糙，后期维护起来的成本会是巨大的，甚至只能用更高的成本重构重写。本质上，再次重构就一定是公司在为早期的猛冲买单，为这些技术债买单，如何不去买单或者如何用最小的成本买单，这跟我们早期的业务密集程度，交付周期，质量把控有很大的关系。

综上，移动端碎片化所带来的兼容难度，RN 框架的局限性，版本间差异带来的不稳定性，技术社区资源的匮乏和前端团队技术能力掣肘，再叠加上高密度的业务排期，让前端开发这个本来很酷的事情，变得晴雨不定。

这些避不开的现实，是绕不过去的坎儿，是搭建团队必须搞定的基础，我们想要把 B2B 生鲜的线上线下场景通过端产品关联起来，想要通过前端团队的用户侧输出从而让这些产品落地，就必须面对这些现实挑战，而应对这些挑战，首先必须搞清楚有哪些挑战，搞清楚挑战以后，我们就会认识到，首当其冲的事情，是去搭建 B2B 生鲜公司的前端技术栈和人才梯队，现在我们进入到本文的重点。

三、如何应对井喷的挑战

1. 前端梯队如何搭建

创业公司的技术团队，本质上就是人和事，用合适的人搞定特定的事，人才的瓶颈就是这家公司产品落地速度和上线质量的瓶颈，因此人是第一位的，对于前端团队来说，如何一步步形成有综合战斗力的团队，取决于搭建什么层次的前端梯队，如果所有人一视同仁，培养同样的能力栈，发挥同样的兴趣向，跟进同样的业务线，那么这个梯队的扁平就会带来致命的团队瓶颈：能力可复制但不能互补，能力可递进但很难跨越，不能互补和很难跨越会导致团队内的技术路线过于单一，技术思维趋于固化，至于技术储备的丰富性和技术沟通带来的碰撞就更有限，最终导致人做事越来越机械化，甚至失去最初的技术初心。

那么小菜前端到底如何搭建，还是要从公司的人员、业务和技术现状出发，由于端的碎片化和技术框架的不稳定性，就必须在质量保障上投入巨大的人力保证产品可用，而人才能力局限性和数量的匮乏，就跟产品的质量保证成为了天然的矛盾，不可协调，代码撺太快，线上天天都是 Bug，代码撺太慢，产品节奏跟不上，至于跟工程师天天宣讲要小心小心再小心，能起到的作用也不大，因为工程师本身的能力也是参差不齐的，所以就必须把团队先拆成两部分，一部分做基建支持，一部分做业务支持，基建支持的同学研发整个团队的工具脚手架、抽象和打磨团队的基础通用组件、长期维护项目的通用架构，这些投入都会反哺到业务支持的同学，业务的同学可以放心大胆的基于基建的成果做上层业务开发，稳定的工程基础有了保障，上层的业务代码做质量保障难度就大大降低了。

除了分出来人做基建，做业务，还需要有核心的技术骨干，做技术前瞻性的研究，为团队 3 个月后，半年后，甚至 1 年后的技术方向，做必要的调研、测试和实验性开发，因为对于刀耕火种的早期技术团队，从原始人到迈向外太空跨空间作战，这中间还差着很多个关键的技术迭代节点，这些关键的技术迭代节点，一部分是靠外招技术专家和资深的工程师来输血发力，还有一大部分是需要靠团队内部长期的积累沉淀，也就是人才内部培养。

我们总结一下：

• 基建的同学负责输出工具系统、基础组件、流程规范，保证内部效率最大化和质量的有效保障
• 架构的同学负责攻克技术底层难点，调研先进技术，升级团队技术架构，沉淀技术方案，锁定和推进团队未来技术方向
• 业务的同学负责产品跟进，高频使用基建产品，并通过反馈来优化团队的技术基础设施，同时基于业务来抽象更多的基建需求

基建、架构、业务这三个角色并不是相互独立，而是互有重合各有侧重，一个业务的同学，可能也同时在负责基建的事情，一个基建的同学，可能也同时在参与架构的设计，在小菜就有同学以架构和基建为主，业务也时不时的参与开发，架构和基建必须依托于业务场景来做，不能脱离了场景，不然会输出畸形的难以落地的技术方案。

上面是人员的分工，还有三个重要的保障，这里不做引申，只列举一下：

• 团队人员的兴趣栈、能力栈和业务要尽量匹配
• 团队人员的阶段性目标、长期规划要跟进公司的职业晋升路线和能力模型
• 团队要有持续性的内部技术互动分享和对外的技术理念、方法方案分享

小菜的前端是大前端，对人的要求是：一专多精多能，至少在某个领域内朝着专家方向走，同时要慢慢精通多项技能，最后是具备多个特定技术栈的开发能力，比如 ReactNative，在小菜就是一个必须具备的开发能力，不要求每一个同学都成为 RN 专家或者精通，但要具备业务开发的能力，通俗点描述，就是能用 RN 开发业务产品。

最后一点，就是资源流转，架构的同学，基建的同学和业务的同学的梯次关系是从下到上，越下越接近技术本质，越上越接近业务结果，越向下需要越好的技术实力，越向上需要越好的业务理解能力，这两个能力都是核心能力，需要让团队成员沿着梯队关系慢慢流动起来，业务中技术能力好的同学可以有机会沉下来做做基建，长期埋头基建的同学可以有机会上去做做业务，业务理解不错技术沉淀又好的同学可以继续沉下去参与架构，这样团队内部的同学都可以有多样性的技术场景和业务场景，一旦有同学请假、陷在别的业务不能抽调，马上就有同学可以补位进来开发，不会影响到产品上线节点。

关于团队如何搭建，目前小菜是走到了这个算是 v1.0 的阶段，未来还有更多挑战，也会带来更多的基于公司现状的新调整，无论如何变迁，方法论我们先沉下来：

• 人才梯队要有层次：基础架构、基建和业务上层等
• 人才成长要有规划：兴趣栈、能力栈和公司关系
• 人才能力要有扩展：单人能力和互补后的团队能力

以人为过程，以事为结果，人事之间要有动态的机制形成互惠互补的关系，只有这样，团队才会初心不变，激情常在。

2. 如何做技术选型

技术选型是一个行业老话题了，方法论也有很多，在小菜我们遵循的是：技术方向性预研大踏步，业务基建型开发小碎步，前者尽可能激进，后者尽可能保守，比如 数据报表系统，我们激进的采用 GraphQL 来解决 SQL => 页面 Dom 的链路问题，在宋小福 App 上面，我们就求稳的采用 v0.48 的 ReactNative 版本，而不是用当时较新的 v50+ 版本。

在做技术选型之前，还有一些比较重要的基础性问题需要搞定，那就是团队技术动作的一致性，这个一致主要包含两点：

• 代码规范共用一套
• 仓库合作方式共用一套

这两点如果不一致，会给技术选型后的落地带来内耗成本，千万不可大意。

再回到技术选型本身，抛开激进保守的大踏步和小碎步，我们需要回到技术本质和工程师的本质来看待如何选的命题，技术的本质是效率，工程师的本质是兴趣，如果这一套技术选型不能带来效率，如果工程师普遍不感兴趣，那么通常这一个选型我们不会采纳，我觉得这一个主观一些的标准，大家可以参考，但这里面也要权衡好历史包袱、维护成本，上手难度等这些客观现实，如果一个新技术会带来革命性的效率提升，那么即使有上手难度和维护成本，我们也会果断入坑，比如 GraphQL 对于数据报表对于解放前后端有大幅度的提升，我们会果断入坑大力推行，如果一个技术对于团队是锦上添花，那么我们会慎重选用，比如 TypeScript，可以给工程稳定性带来了较大的保障，但我们只选择在热更新这种 RN SDK 和 Server 端的去集成，而不是一下子推广到整个团队项目中铺开用，这里面就会考虑到实际得到的好处，以及历史包袱和上手难度，反复权衡后并没有带来更大的价值，所以这两类场景的推行和不大力推行，就又不会太依赖于工程师的喜好兴趣。

那么我们技术选型后的结果是如何呢？

文章最开始的那张图，里面就是我们的技术栈，这里再做一下总结：

• 工具类：强依赖 Node，多而杂的其他技术，如：MongoDB/Redis/MySQL/Shell/Python
• 业务类：强依赖 React/ReactNative，适度集成其他技术，如： Redux/GraphQL/Apollo
• 框架类：除了 React 全家桶会谨慎选择，Node 端框架则相对宽松：Koa/Thinkjs/Eggjs

这些相对求稳，不求稳的部分，如小程序开发，我们会使用 mpvue，也会用原生，还会集成进去 GraphQL，同时一些涉及到数据爬取和视频图像识别，我们也会集成 Python/C++/TenserFLow 等等，不过这些往往是前瞻性的技术尝试，会让团队的同学适当分配精力持续研究。

3. RN 的 App 工程如何架构

小菜的主要产品类型，尤其是对外的产品，主要是 RN App，而且数量较多，那么 RN 项目的合理架构就变得尤其重要，我们这里探讨下小菜前端在 RN App 上面的沉淀，涉及到原生层面的技术细节太多，这里暂不做讨论。

首先，我们在构建 RN App 工程时需要关注这几个关键要素：

• 配置管理
• 静态文件管理
• 网络请求
• 组件管理
• 路由管理
• 数据缓存
• App 的热更新
• 数据搜集

__配置管理__是指可以灵活合理的管理 App 的内部环境，主要包括：

• App 本身的一些配置
• 所使用三方插件的配置

我们在构建工程时尽量将所有的配置抽象统一放置在一个地方，这样便于查找和修改，但是由于大多数配置都统一放在同一个地方，那么就难免有部分文件要使用某个配置时其引用路径比较长，比如：

import { pluginAConfig } from '../../../../../config'

当然，Networking 的功能不止于此，还有很多其他有趣的功能可以发掘，可以直接用它来包装自己的网络请求工具，还支持 abort ，可以参考 源码 来具体把玩。

使用 RN 开发 App 本身效率就比较高，如果想要继续进阶就要考虑组件化开发，一旦涉及到组件化开发，就不可避免地会涉及到组件管理的问题，这里的__组件管理__比较宽泛，它实际上应该指的是：

• 组件规范
• 组件类型划分
• 组件开发标准

组件规范指的是 UI 设计规范，我们可以与设计同学交流规定好一套特定的规范，然后将通用的样式属性（如主题颜色，按钮轮廓，返回按键，Tab 基础样式等）定义出来，便于所有的组件开发者在开发时使用，而不是开发者各自为政在开发时重复写样式文件，这里推荐一个比较好用的用于样式定义的三方插件 react-native-extended-stylesheet ，我们可以使用这个插件定义我们的通用属性：

// mystyle
import { PixelRatio, Dimensions } from 'react-native'
import EStyleSheet from 'react-native-extended-stylesheet'

const { width, height } = Dimensions.get('window')

const globals = {
  /** build color **/
  $Primary: '#aa66ff',
  $Secondary: '#77aa33',
  $slimLine: 1 / PixelRatio.get(),
  /** dimensions **/
  $windowWidth: width,
  $windowHeight: height
}

EStyleSheet.build(globals)

module.exports = {
  ...EStyleSheet,
  create: styleObject => EStyleSheet.create(styleObject),
  build: (obj) => {
    if (!obj) {
      return
    }
    EStyleSheet.build(_.assign(obj, globals))
  }
}

// view.js
import MyStyleSheet from 'mystyle'

const s = MyStyleSheet.create({
  container: {
    backgroundColor: '$Secondary',
    width: '$windowWidth'
  }
})

render....