开源协同下的前端量化管理

作为公线前端技术支撑职能团队（为不同的业务产品部门提供前端技术开发支撑），为了更高效地服务我们的业务产品，部门采用FT的服务模式（为产品业务部门配备专门开发人员组成的虚拟小组）很好解决了人员调配效率问题，在如此背景下也给组内进行的量化管理工作带来的一些挑战：

1 、FT间的业务差异大，如何保证不同FT前端开发间协同性。

2 、业务部门对接不同的开发团队，如何提升自己在业务部门心中的专业口碑。

3 、业务部门各类创新型产品（如定制巴士需要在各城市快速铺开）对开发的效率有了新的要求，如何提升开发效率。

4 、前端技术栈的快速迭代背景下，如何更好融入到各个兄弟部门开源协同大浪潮中。

针对以上挑战，量化管理负责小组主要从 流程量化、开发效率、技术协同  3大方面去落地展开，最终我们希望的结果是团队能够在标准的可量化流程下，在实际项目开发中不断沉淀健壮流程下每个节点的方案实现标准，做到每个节点涉及的一些可复用的场景我们都能够有一套成熟的高质量的方案提供引用和参考，用一张比较抽象的简图描述一下我们的愿景：

一、流程量化

先来看一下我们对流程量化方面的一些建设思考，我们对量化流程的核心诉求是：一个可循环正向驱动团队经验积累和能力成长的稳固性较高的流程。所以我们的流程主要有两个特性，一个是流程一定是高度从业务特性剥离出来的，因为如果和业务特性耦合的流程，通用性不强，缺乏稳固性，不利于团队的积累；第二是这个流程需要有一个很好的闭环效果，以往我们的项目结项基本就是一个终结点，对团队成长的积累更多靠项目开发者个人的主动性去积累总结分享输出对团队有帮助的文档，仅此而已，所以我们的闭环效果一定要扭转开发负责人的结项即终结的思维，推动项目开发负责人形成项目总结输出即是服务于下一个类似项目开发的参考标准的习惯。

1.1 我们以项目管理的维度进行流程节点划分

我们将前端项目流程切分为 需求分析、方案设计、开发、联调、体验、测试、发布、总结输出 8个梯度。根据我们这边实际项目开发的一些工作细节（只做概论性总结，不深入讲解）进行整合归纳到8个不同的梯度中，为了起到流程的正向循环促进我们加入 项目总结文档 （一个以项目类型为维度进行经验收集管理的在线文档） ， 每个项目在总结输出阶段开发负责人需要将项目遇到的一些业务无关通用性问题以及业务相关的通用方案，以及踩过的坑收集到项目总结文档中，提供给其他项目需求分析以及方案设计甚至开发阶段一个可借鉴的经验借鉴入口，用个简图概述一下：

下面简述一下8个梯度量化的一些关键性步骤。

1.1.1 需求分析： 【技术风险预估】、【abtest接入可行性分析】 【技术风险预估】 是我们这个流程实现可循环的一个很关键点，我们在每个项目总结输出中开发负责人都会将项目遇到的一些业务无关通用性问题以及业务相关的通用经验归档到我们的 项目总结文档 中，开发人员在分析需求阶段可对应总结文档里面的相关经验去发现需求是否存在不可实现的需求，做到在需求分析阶段尽早和产品方沟通调整

【abtest接入可行性分析】 是我们部门提出的“数据驱动产品增长进而推动业务增长”的核心目标来推动落地的一个项目（这里简单安利一下我们abtest项目，利用百分比分流算法实现的一个可控流量用户行为数据分析平台，我们后续会有专门的文章来分享这块），我们要求FT各开发负责人在需求分析阶段时（尤其是针对优化需求），需要在每周5的abtest评估会上做出这个需求abtest数据验证的可行性分析，并给出数据收集计划。

1.1.2 方案设计： 【代码构架】

【 代码构架 】是我们前端项目开发必须慎重考虑的一个环节，主要从目录范式、通用单元函数库、通用样式库、通用组件库、代码运行时环境几个方面去全盘思考，鉴于这个可复用度高，所以我们将组内做的一些项目进行整合梳理出一个非业务相关通用的代码构架，规范了h5&小程序&node（基于egg）项目的通用项目模板（规范目录范式以及lint、git钩子等npm运行时环境，放在git上统一建仓维护）以及将通用的组件库（h5的vue组件库fit-ui、小程序的组件库fit-mini-ui）、单元函数库、egg功能插件整理出来托管到tnpm做开源协同。

1.1.3 开发： 【通用方案选型】、【监控体系】、【代码规范校验】

【通用方案选型】 项目总结文档中有归纳不同项目类型下特定场景下的一些成熟的处理方案提供直接引用或者借鉴，减少重复造轮子

【监控体系】 针对测速、错误实时监控等方案的统一管理

【代码规范校验】 开发阶段需要及时统一校验代码的规范，将不符合规范的代码尽早在开发阶段发现

1.1.4 联调： 【cgi数据代理】、【用例自检】

【cgi数据代理】 作为代理接口数据mock的存档，为后续项目的维护提供便利

【用例自检】 开发需要根据测试的用例评审表建个开发自己的自测表存档，依据自测表跑通每个流程，保证产品体验前的功能用例自测全覆盖，以邮件（我们规定了统一的自测邮件模板）告知项目相关人自测结果。

1.1.5 体验： 【视觉还原】、【产品功能体验】       

【视觉还原】 跟设计师对还原前，开发人员需要用组内自研的还原工具比对后，截图存档后，才能发起视觉还原

【产品功能体验】 提供一个产品可以体验全流程的环境

1.1.6 测试： 【单元测试】、【提测流程】

【单元测试】 开发提测前的单元测试验证（这个流程还在讨论中，目前团队还是在摸索TDD模式）

【提测流程】 req流程提测

1.1.7 发布： 【ci|cd】

【ci|cd】 基于蓝盾流水线的持续集成方案，实现codereview、远程代码规范检查、远程构建、UAT验收、正式环境发布几个关键性步骤的自动化（在后面会详细讲解实现方案）

1.1.8 总结输出： 【资料归档】、【经验输出】 【资料归档】 我们的项目标准模板中有一个documents目录用于存档前面几个关键阶段输出的一些文档，有项目信息表（记录项目相关人、需求tapd地址、cgi接口文档链接、测速监控链接、错误监控链接等）、自测用例表、视觉稿、接口mock文件、单元测试报告

【经验输出】 由项目负责人拉结项会，议题主要是讨论当前项目有哪些重难点问题需要沉淀到项目总结文档里的，有更新项目总结文档的需要在会后邮件周知全组成员

1.2  依据流程各个环节做标准化方案的梳理和统一（限于篇幅，重点分享一下模板和CI这块）

1.2.1  项目开发模板设计

为了统一大家的一致的开发习惯，同时考虑项目的通用性以及对业务不能造成侵入性的因数，所以从项目资源维度的目录结构进行重新优化，同时内置初始化项目必须要引用的一些通用性单元函数库（比如测速speed.js、mta上报mta.js、日志上报log.js等），最后集成一些规范检查（lint）、git钩子等npm包运行环境的配置。下面简单描述一下具体落地方案。

h5项目因为我们团队采用的vue栈，用的vue-cli本身模板，这里不多说，小程序这块重点说一下，因为官方对模板这块的粒度定义偏大，落地到每个项目中开发人员自由度太高，目录结构较为混乱，所以我们主要从资源分层、数据管理、以及配置化去规范项目模板：

a、小程序项目业务数据在各个项目管理比较混乱，所以我们参考mvc框架，抽出数据层独立管理，内部按cgi、cache、cloud精细化数据管理维度，同时针对前端业务实体创建单例数据模型维度modal来简化不同页面共享数据状态的复杂度问题，用一张定制巴士小程序项目的数据管理datas层简图来描述一下：

b、业务项目的配置的复杂性我们通过统一配置化管理的方式将所有各个维度的配置收拢到config目录管理

最后上一张我们小程序模板的落地简图：

1.2.2 CI 持续集成方案

Ci这块我们选的是蓝盾devops流水线进行的，我这里还是以小程序的流水线以及里面的相关插件来简单介绍一下我们这边的场景方案。

鉴于整个bg的技术团队都在搞开源协同，我们这里主要是采用VB创新产品部主推的流水线来做，研发流程通过4条流水线串联起来

1、新项目初始化多端切换，来回操作

2、初始化项目创建流程长，流程规范要求增加开发成本

所以我们开发了符合我们工作流的一个脚手架工具（@tencent/fit-pro-cli），主要是将我们我们流程量化阶段梳理的模板、组件库、单元函数库、以及一些相关的规范进行整合，因为我们的工具本质上是一个命令行工具，考虑开发人员使用上的便利性，所以我们将项目开发浓缩为3个主命令入口，每个主入口命令后续通过交互式问答的方式引导开发人员一步步去完成每个主功能入口的项目开发，用个简图描述一下我们初始化项目前后的一个流程对比效果：

这里有必要和大家分享一下脚手架工具fpc pull主命令在小程序下实现组件库|单元函数库的按需拉取，为什么要在小程序下实现按需拉取：

1、组件库|单元单元库全量拉取造成没用代码的浪费，没有像我们在h5下webpack的依赖分析机制，必然会造成资源的浪费

2、小程序npm构建机制也只支持单包全量引用

3、如何做到在引用库的时候能够和API强关联起来

带着这些问题，我们fpc pull主要做了什么呢？

1、tnpm全量下拉到本地做物理隔离

2、非全量拉取时自动打开API文档

3、自动匹配出组件库|单元函数库的所有组件|单元函数并下拉让开发者自动选填后动态copy到项目的指定目录

三、技术协同

技术协同是我们整个量化管理当前阶段开源协同重心之一，整个协同的工作节奏是在kpxu(徐凯鹏)大神组织下的FIT大前端技术协同的框架（通过统一大前端知识体系框架再加上各个专业协同小组一起配合实现FIT大前端实的开源协同）下进行的，对于我们组内的量化管理的技术协同来说主要考虑两个方面：

1、如何很好对接上FIT的开源协同又能保证现有组内的流程和框架的稳固性。因为FIT开源协同从大方向以及一些框架层面上进行协同，内部每个组肯定会有自己用的很成熟的一些方案性的通用方案以及一些符合组内自己的一些成熟组件库。

2、组内内部的协同机制如何设计。组内沉淀的一些不适合对外开源，但符合组内业务的一些通用经验沉淀方案如何在组内更好的协同。

基于上面两个问题为出发点，我们优化组内脚手架工具的fpc pull的主命令内部机制，针对我们组内日常一些可以直接在代码里面静态引入就可以用的一些经验和梳理的一些库通过单元函数库、组件库维度来管理，针对没法通过静态引入的方式需要额外做配置改动或其他一些需要开发者做额外手动操作的一些方案通过插件的方式来管理；考虑组件库、单元函数库、插件（都是统一放到tnpm上管理）集成的便利以及对脚手架核心代码的侵入性，所以这里我们统一提供一个GIT公共仓库提供给组件库、单元函数库、插件的开发者们按照我们的一些关键信息登记规范录入即可完成集成，然后我们的脚手架在fpc pull拉取组件库、单元函数库、插件的时候就可以统一从GIT公共仓库去读取配置完成项目中的集成操作，老规矩还是放张脑图来简单描述一下：

这里重点说一下我们的插件机制。插件本身就是一个可执行的命令工具，命令入口规定init，提供给脚手架调用  ，同时脚手架会给init传入项目的两个信息（后续会根据项目开发需求，可以放开更多的信息给插件使用），一个是项目类型的信息，一个项目的目录路径：

【图片截图取自插件示例源码】

插件拿到这两个信息，要做什么就自己去根据插件的功能去实现即可。插件开发好后，作者可以将一些关键信息（插件的运行的环境h5|小程序|通用、插件tnpm包名、最新版本号、插件运行的入口脚本路径、功能描述）到我们的GIT仓库统一登记后，使用者即可通过脚手架命令运行fpc  pull选择插件的时候拉取到并运行，看一下我们实现的拉取示例插件效果截图：

我们的脚手架插件不仅可以针对项目中的通用方案去实现动态配置，还可以针对脚手架本身的功能提供对外的扩展，满足自己对脚手架本身功能的定制化需求。

结语：

终于到了结尾部分，非常感谢大家的耐心看完，因为量化管理涉及的内部外部各个部分协调的复杂性，一些具体细节很难全面展开，后续我们会将内部涉及的相关议题拿出来分享（或文章或ppt都可能），最后来个简单的总结吧：量化管理本质目的是为了更好在组内实现开源协同的落地，我们从流程上做了量化、效率上去开发了相关工具，同时为了扩展集成设计了插件化机制，对外更好的建立专业服务口碑，对内形成更好的协同机制。

当然每个组去推行开源协同的落地方案是不一样的，不过总体上无外乎我上面列出的3个方面，内部的实现方案和细节组内实现目前还有很多需要磨合的地方肯定还有很多有待改善的地方

腾讯政务云副总裁王景田谈To B销售： 团队力量是关键

前端智能漫谈 – 写给前端的AI白皮

【企鹅智库】3.96亿网民“新蓝海”：下沉市场消费&娱乐白皮书