我们知道有一个词叫做主观能动性,表示没有条件创造条件也可以上,这个词的主体就是人,聊完移动端设备现状和社区现状后,我们来聊聊人的问题。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 的内部环境,主要包括:
我们在构建工程时尽量将所有的配置抽象统一放置在一个地方,这样便于查找和修改,但是由于大多数配置都统一放在同一个地方,那么就难免有部分文件要使用某个配置时其引用路径比较长,比如: