生鲜 B2B 技术平台的前端团队该如何搭建

此文写于 1 年前，转载至此，大家可以加 Scott 微信: codingdream 成为朋友圈的朋友，聊南聊北，哈哈哈。

---

![图片描述][1]
线下越重，线上需要越轻，这个轻指的是轻便轻巧和简洁易用，通过前面几章小菜技术与产品历史介绍，我们了解到 B2B 生鲜领域在线下是如此之重，那么在交易场景线上化的过程中，端的移动化就势在必行，试想一下，让菜市场摊位老板人手一台笔记本点开网页选购支付，让采购销售抱着电脑去拜访客户，一边聊蔬菜行情，一边打开笔记本进行记录，有没有一种回到世纪初的感觉。

产品的移动化，这将是我们展开这篇文章的背景，我们会先了解小菜的产品托管在哪些端上，然后感受这些端带来的挑战，最后是我们面对这些挑战所采取的策略，以及整个小菜前端团队历练后的技术成长和沉淀，和我们对于自己的一个评估和对未来的展望，本文将采用最通俗易懂的方式陈述，会略有繁琐，但力求对技术新人也足够友好。

一、小菜大前端的端有哪些

小菜早期围绕着蔬菜销地以客户集单批发的模式摸爬滚打几年，从上游的蔬菜供应商到下游批发市场的摊位老板，在这个长长的链路中，我们诞生了这样几款线上产品来服务于不同的人群和场景，之前文章中也有介绍，这里再汇总一下，共 7 款 App：

• 宋小菜 服务于销地批发老板的下单工具
• 宋小福 服务于小菜内部销售团队的 CRM 销售管理与客户管理工具
• 宋小仓 连接司机-物流-采购-销售的蔬菜在途位置监控工具
• 采秘 服务于小菜内部采购团队的蔬菜品类采购工具
• 麦大蔬 服务于上游蔬菜供应商的大宗农产品交易平台
• 宋大仓 服务于上游囤货配资的进出库管理平台
• 行情宝 服务于产销两地的行情采集和预测工具

前 6 款 App 都是基于 ReactNative 开发的 iOS/Android App，最后一个是微信小程序，它们涵盖了公司几乎所有的协同场景和工作流，其他涉及审核、数据观测和过程管理的部分，则会进入到我们 PC 端产品中，也就是：

• ERP 后台管理系统

生鲜的 toB 场景，角色众多，链路冗长，这种延伸到产地农民，延伸到小 B 交易的管理系统一定会角色杂，权限多，操作重，业务复杂度所带来的页面复杂度不是一般的小系统可比拟。

到目前为止，我们已经看到小菜的 7 个移动端 App，以及一个复杂的后台管理系统，这些都跟前端工程师息息相关，除了这些，还有 2 个重要的内部产品，就是：

• 大表哥 数据报表系统
• 大瓜子 市调模板配置系统

其中大表哥（谐音：搭 Excel 表格）由前端工程师独立研发和维护的数据报表系统，单拎出来这个系统，是因为在 B2B 公司，尤其涉及到供应链的长链路场景中，真实业务数据的及时反馈对于每一个执行团队都至关重要，没有这些数据抓手，就失去了多维度数据观测，都很难快速的做出正确的运营决策和业务调整，甚至很难发现业务中出现的漏洞和问题，比如不正常的非自助下单（也就是销售帮忙下单）的比例。

关于报表系统后文还有介绍，我们再为前端增加一个服务的产品场景，就是微信生态内产品，比如公众号或者小程序，它的技术栈和运行环境跟原生 App 和 PC 都不同，虽然小程序可以带来更多的业务可能性，也会对前端带来更大的挑战。

我们把这些端合并一下，小菜前端要服务的端或场景：

• 移动端（iOS/Android App/小程序）
• PC 端（ERP）
• 工具端（大表哥数据报表）

端上全部开花，这也应了我之前在掘金 JTalk 上小菜对于长链路流通交易分享的一个观点：链路足够长，每个节点上都可以长出产品。那这些端产品都是与业务有强关联的，还有更多技术基建的和服务于团队内的产品，比如：

• 大伯伯（谐音打包包） 实现 App 选仓库选分支选环境配置的自主打包与推包系统
• 大表姐（来自饥饿游戏，寓意开工没有回头箭） 实现 6 款 App 解包差分后下发热更新包的发布系统
• 姑奶奶 线上异常汇集分析与与 Bug 定级指派系统
• 大舅子 向下调用微服务接口向上提供 GraphQL 查询能力的数据聚合服务
• RGB 用户使用 App 的 PV/UV，以及业务数据监控相关的可视化平台
• 110 解决端异常收集与报警需求
• 堂哥工作台 团队记录资源分配与 redmine 同步的自动化周报系统
• ITms 解决内部 App 安装测试的配置生成和预装服务
• …

这些是服务于团队内部的工具链，全部由小菜前端自行维护。到这里我们发现，在小菜这样一家创业公司内，前端要服务的端和场景的确较多，但这些产品和工具的背后，整个前端组也就 10 个人而已（我们当然也求才若渴），但是人虽少，效率不能自我妥协，所以我们能服务到这些端，也正是基于端的多样性和数量，我们称自己：宋小菜大前端。

先上小菜端上若干产品和工具的技术栈图，帮助大家理解我们的技术理念：

二、多端带来的挑战

1. 【物理现状】移动端的碎片化

古典互联网时代，因为要兼容 IE678 而痛苦不堪，Hack 黑魔法经验基本代表前端水平，如今互联网早已移动化，我们理想中的移动端开发，看上去是可以大胆使用新语法特性，只需要做好尺寸兼容就好了，但事实并非如此，不仅在移动端的浏览器不是如此，在移动端开发 RN App 也是如此，这是我们某一款 App 一段时间内，所收集上来的手机厂商分布：

可以发现 Android 的碎片化非常严重，每一个厂商下面有不同时期推出的不同型号的手机，这些手机有着不同版本的操作系统，不同的分辨率和用电策略，不同的后台进程管理方式和用户权限，要让一款 App 在哪怕头部 40% 的手机上兼容，都是一件艰难的事情，这个客观物理现状叠加下面的社区现状，App 质量保证这件事情会变得雪上加霜。

2. 【社区现状】技术框架的不稳定性

回到本文的开头，我们在长链路的 B2B 生鲜场景中，为了更快更轻，开发出 7 款 App，而且将来随着业务场景的拓展会诞生更多独立 App 甚至是集大成的 App，所以技术选型不太可能选择原生的 Java/Object-C 开发，尤其对于创业公司，6 款 App 得需要多少名原生开发工程师才能搞定，高频繁重的业务变化又怎样靠堆人来保证？

想清楚这些，一开始我们就调研 ReactNative，并最终全部从原生切换到了 RN，通过跑过来的这 3 年来看，使用 RN 为公司节约了大量的人力成本同时，也尽可能的满足到几乎所有的需要快速迭代的业务场景，又快又轻，成为宋小菜大前端团队做事的一个典型特征。

但换一个角度看，就是带来的问题，又快又轻的背后是 RN 版本的飞速迭代，截止到目前，也就是 2018 年 6 月份，RN 还没有推出一个官方的正式的长期维护的稳定版本，什么意思？就是 RN 目前依然处在不稳定的研发周期内，我们依然站在刀尖起舞，用不稳定的 RN 版本试图开发稳定的应用，三年走过来，我们在 RN 的框架里，多少次面对旧版本局限性和新版本不稳定性都进退不得，旧版本的 Bug 可能会在新版本中修复，新版本引进则会来新版本自己的问题。

除了 RN 自身版本，还有第二个问题，围绕着 RN 有很多业界优秀的组件，但这些社区组件甚至官方组件，都不一定能及时跟进最新的 RN 版本，同时还能兼容到较老的 RN 版本，所以 RN 升级导致的组件不兼容性，会引发你 Fork 修改组件的冲动，但这样会带来额外的开发成本和版本维护成本，取舍会成为版本升降的终极问题。

在国内开发，还有第三个问题，就是中文文档缺乏，社区资源匮乏，参考文献陈旧，可拿来主义的开源工程方案甚至社区线上线下会议分享都很缺乏，一个不小心就会踩坑，这就是 RN 社区的现状，我们在刀尖浪花上独步，App 选型背后的技术栈稳定性则成为悬在头上的一把铡刀，你不知道什么时候会咔嚓一声。

3. 【人才现状】人员能力的长短不齐

我们知道有一个词叫做主观能动性，表示没有条件创造条件也可以上，这个词的主体就是人，聊完移动端设备现状和社区现状后，我们来聊聊人的问题。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. 前端梯队如何搭建

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