1、大前端新趋势专场侯凡 2021年08月01日本期议题：构建可信的大前端工程体系个人介绍华为云 CloudBU PAAS服务部CTO办公室前端技术架构、前端业务交付责任人2010年加入华为参与过多个华为内部工具的前端设计与交付工作目前带领团队负责华为云DevCloud、CloudDragon的整体前端业务交付以及前端架构演进与设计工作负责DevCloud、CloudDragon整体产品体验设计工作前端开源项目DEVUI负责人ECMA TC39成员http:/devui.design侯凡背景1前端技术发展快、更新快交付团队如何应对技术快速更新带来的升级风险开源、可靠性、安全、合规产品功能越来越复杂

2、，迭代速度慢体验要求越来越高，人人都是产品经理产品功能工程越来越大，构建越来越慢业务需求增多，代码质量工作投入降低开发效率团队成员多，沟通效率低团队版本交付节奏不一致，协调难团队协作背景2大前端工程体系可信构建可信的大前端工程体系 关键字大前端是前端领域在广度和深度的进一步延伸前端体验服务向前走向前走向里走Desinger&DeveloperSketch to CodeLow/NoCodeBFFNodeJSServerless多端语言框架编译打包前端工程体系：前端应用越来越复杂，体验要求越来越高DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev

3、）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。更小、更频繁的变更意味着更少的风险让开发人员更多地控制生产环境更多地以应用程序为中心来理解基础设施定义简洁明了的流程尽可能地自动化促成开发与运营的协作提高效率、降低成本DevOps三步工作法流动：建立从左至右快速的、平滑的、能像客户交付价值的工作流反馈：建立从右到做的，贯穿于整个价值流的快速、频繁、高质量的反馈信息流持续学习与改进：建立

4、持续学习与改进的文化，持续提升个人技能与产品竞争力9安全性（Security）：产品有良好的抗攻击能力，保护业务和数据的机密性、完整性和可用性。韧性（Resilience）：系统受攻击时保持有定义的运行状态（包括降级），遭遇攻击后快速恢复并持续演进的能力。隐私性（Privacy）：遵从隐私保护既是法律法规的要求，也是价值观的体现。用户应该能够适当地控制他们的数据的使用方式。信息的使用政策应该是对用户透明的。用户应该根据自己的需要来控制何时接收以及是否接收信息。用户的隐私数据要有完善的保护能力和机制。安全性（Safety）：系统失效导致的危害不存在不可接受的风险，不会伤害自然人生命或危及自然人健

5、康，不管是直接还是通过损害环境或财产间接造成的。可靠性和可用性（Reliability&Availability）：产品能在生命周期内长期保障业务无故障运行，具备快速恢复和自我管理的能力，提供可预期的、一致的服务。Trustworthiness 可信任可追溯 来源可信 E2E 追溯客体的历史、应用情况或所处位置可度量 要想改进它，就要度量它 研发过程数字化 牵引指标体系可改进 规范与约束 目标牵引 可量化 团队文化参考度量指标业务含义描述前置时间 Lead Time前置时间是供应链管理中的一个术语，也被应用于敏捷与devops中，指用户提出需求到发布上线的时间。前置时间的缩短除了开发效率外，还

6、要着重审视设计阶段的效率需求修改频次需求修改频次，可以记录前端产品需求被修改的次数，从而反应产品经理与设计师在产品设计的规范程度与协作效率需求规范度提交的需求是否满足约定的规范。比如，复杂特性需要有详细的高保真标注图、杜绝一句话需求、杜绝描述不清楚的需求。在收到不满足规范要求的需求，开发人员有权打回需求，以避免后续的开发成本浪费。而规范度遵循度差的团队，应该审视相应角色的协作是否存在优化点设计：基于统一的需求规范与设计规范，通过专业工具进行管理，降低沟通成本，提升需求设计效率参考度量指标业务含义描述迭代人均交付需求数在单位迭代内，每个开发人员能完成的人均需求数。由于团队划分需求颗粒度习惯是延续

7、的，可能存在个别迭代不同开发人员需求颗粒度不一致的情况，但放在一个较长的时间段内相关误差基本可控。所以平均迭代交付需求数越高，且呈上升趋势的团队，可以理解为团队交付效率高。迭代人均问题数单位迭代内产生的现网问题数越多，也代表其交付版本质量较差。而如果该指标长期未成收敛趋势，那么也需要同步审视相应的质量保障体系是否存在优化空间。开发：基于脚手架和统一的开发物料，提升整体开发效率与质量工具或自动化手段：参考度量指标业务含义描述代码检查遵从度良好的代码规范和基础的静态检查能够避免很多低级问题。而遵从度的指标，要求开发人员必须满足我们的代码检查要求，比如，严重问题清零，或者问题100%清零等指标自动化

8、用例覆盖率开发人员应该编写对应的测试用例，并基于本次代码提交的影响范围，运行相关自动化用例，以确保新功能和历史功能的质量。尤其对于大型的前端业务系统，必须建立自动化用例体系保障长时间积累的大量特性得到质量保障。在此阶段，自动化用例覆盖率越高，越能保障版本的质量自动化用例成功率用例执行的成功率。频繁失败的测试用例，要么反应业务功能的不完善，要么反应测试用例的不严谨，从而影响版本质量的验收，应尽力避免设计：基于统一的需求规范与设计规范，通过专业工具进行管理，降低沟通成本，提升需求设计效率参考度量指标业务含义描述门禁通过率静态检查、单元测试、E2E测试、人工验收测试将会覆盖到版本的不同环境阶段，门禁

9、必须100%通过后，才能流入到生产环境。而门禁通过率代表版本的质量情况构建时长&成功率构建时长：随着业务代码不断年增加，项目深度不断延伸，构建时长也会不断增长。关注构建时长的指标，会让我们关注到版本本身规模增长和代码健康度是否在合理的范围内构建成功率：也将表现出当前项目的健康度，规范、高效、本地验证充足的交付团队，构建成功率会非常高部署频率&时长&成功率部署频率：理想情况下，部署频率要么保持稳定，要么保持稳定增长，部署频率的任何突然波动都可能表明现有工作流程中存在瓶颈部署时长：部署时长越短，意味着我们可以更频繁的进行部署部署成功率：部署失败率过高，代表我们的版本或运维存在瓶颈设计：基于统一的需

10、求规范与设计规范，通过专业工具进行管理，降低沟通成本，提升需求设计效率参考度量指标业务含义描述MTTR平均修复时间（Mean time to repair，MTTR），是描述产品由故障状态转为工作状态时修理时间的平均值设计：基于统一的需求规范与设计规范，通过专业工具进行管理，降低沟通成本，提升需求设计效率测试右移在线拨测需求设计UI开发开发自检代码提交UI门禁编译构建部署测试功能拨测前端监控版本看板设计稿版本管理设计物料复用设计规范需求规范国际化规范主体化规范前端模板工程CLI套件脚手架组件库通用前端解决方案Mock API本地tslint/eslint规范本地门禁代码提交规范代码检查codecheckGit hook代码提及规范门禁静态检查门禁流水线引用包检查配置文件组件库版本引用非合规资源非法引用检查组件库规范扫描标准的构建脚本构建门禁发布包管理（二方包、三方包）发布门禁DI值安全扫描需求完成率标准化部署参数标准文件标准部署方案标准配置方案自动化UI测试用例L0核心功能全量测试灰度测试UI拨测关键页面覆盖告警Furion监控稳定性性能体验异常版本可视化看板人力需求交付吞吐质量情况体验分数早会审视DEVUI前端工程体系度量改进月度前端体验报告月度前端工程报告做工具的主人THANKS