前端开发流程与工程化 | 字节青训营

靛青
441 阅读6分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天

跨职能研发流程汇总

image.png

  • 整体上遵循:需求分析 => 方案设计 => 开发 => 测试 => 验收 => 发布流程
  • 这只是主流程，并不适用于所有场景(例如: Hotfix、npm 发包)，重在理解各职能分工
    • 产品：决定做什么、验收方案、验证方案有效性;
    • 研发：开发、自测、承担部分运维职能等;
    • 测试：质量检测把关;
  • 实际场景中可能出现无数状况(风险管理):
    • 需求变更;
    • 上下游依赖发生问题(比如需求延期);
    • 疫情、天灾、人祸等不可抗力因素...
前端工程化
初始化项目

假如是新项目，那么你需要做很多技术选型:

  • 代码仓库组织形式
    • monorepo 指包含多个不同项目的单一代码仓库，并且内部子项目具有明确定义的关系
    • polyrepo 指每个应用或库分别拥有各自的代码仓库，不会和其他代码仓库合并 image.png
  • 决定采用设计技术栈(React or Vue? Node or Java? AntD or ArcoDesign? CSR or SSR?)，要做许多技术决策;
  • 搭建工程化环境: 构建工具、Lint 工作流(ESLint/StyleLint/Prettier/Lint-Staged/huscky)、UT 工具(单元测试)、CI/CD等（整个过程是在开发过程中不断优化的）
    • CI、CD 其实是三个概念，包含了一个 CI 和两个 CD 。
    • CI（Continuous Integration）持续集成
      • 持续频繁的（每天多次）将本地代码“集成”到主干分支，并保证主干分支可用
      • 目的：快速反馈问题让产品可以快速迭代，同时还能保持高质量；通过自动化手段提高集成速度，将问题前置；防止本地代码大幅偏离主干
      • 工具：Jenkins、GitlabCI、CircleCI、GithubActions
    • CD（Continuous Delivery）持续交付
      • 持续集成的下一步，持续频繁地将软件的新版本交付到类生产环境（类似于预发），交付给测试、产品验收。
      • 相比持续集成，持续交付除了交付到类生产环境之外，还会执行一些集成测试、API测试等等，确保交付的产物可以直接交付部署。
    • CD（Continuous Deployment）持续部署
      • 持续交付的下一步，“自动”将代码部署到生产环境
      • 目的：代码在任何时刻都是可部署的，可以进入生产阶段。持续部署和持续交付触发方式的区别是，持续部署是自动完成的，持续交付是手动完成的
  • 资源部署: 物理服务器、云服务器、faas、CDN(托管静态资源)等

工欲善其事，必先利其器!这些逻辑，通常会被沉淀为脚手架工具(vue-cIi/CRA 等)，下次更迅速创建项目。

功能开发

分支模型(规范)：

  1. feature based development基于特性（更常用）
    1. 从master主分支拉出最新的develop开发分支
    2. 成员再根据功能从develop拉出自己的分支，做完测试后合并到develop开发分支
    3. 开发分支做测试也没问题后，再推到release发布分支，
    4. 发布的部分在release分支测试没问题之后才推到master主分支，发版结束 image.png
  2. Trunk based development基于主干（被monorepo带火）

所有人围绕主干开发，要开发直接从主干拉分支，做完迅速合并回主干，主干有完善的测试和CI/CD，马上就能完成集成，要发布的时候从主干拉出一个新分支来发布，有变更就再从主干拉新分支发布 image.png 开发:

  • 工具效率
    • IDE 效率: 设计适当的配置 & 插件环境，有助于减少手动操作次数，提升团队研发效率
    • 单测效率: 按需单测? 单测覆盖率?
    • 构建效率: 按需构建?构建逻辑优化?构建缓存?
  • 确保不犯错
    • 接入 Typescript，ESLint、StyleLint、CommitLint、lint-staged、pretier等，解决代码风格和类型安全问题，
    • UT(jest/vitest 等) 确保代码运行效果
    • 这两类工具都有一定上手成本，但能做到吹毛求疵，确保不会发生小错误，保证长期可维护!
  • 安全性:
    • 如何避免混入有问题的 npm 模块?
    • 如何确保产物不出现敏感信息(如 github token)?
集成&测试
  • Code Review，重在准入规则: 经过谁、多少人的 approve 后，可以合入代码;
  • 配合 CR，通常还可以设置许多自动检测的准入条件(所谓的 CI):
    • 构建命令必须成功;
    • Lint 必须通过;
    • 单测必须通过，单测覆盖率不能降低，且整体覆盖率必须大于阈值(或增量代码的覆盖率大于阈值)
    • E2E 测试必须通过;
    • 性能 diff 检查;（变化过多如超过1M就有问题）
    • 各类代码安全检查;
  • 班车式发版不可行，到某一刻再集成容易出现问题，比如代码冲突，造成上线来不及
上线发布
  • 小流量部署：设置一个单独的发布环境，请求流量命中某些规则(例如带有特定 header) 时，转发流量到此环境;用于开发预览、功能测试(for 测试同学)等，本质上是一个集成联调环境:
  • 灰度部署：同样是设置单独的发布环境，请求流量命中某些规则(例如特定的用户组、特定的地理区域等，或者按机房部署)时，转发流量到灰度环境，主要用于上线前的功能验证、实验（分组映射到不同环境）
  • 秒级回滚：即使上线，也应该提供一套稳定的方法，能秒级瞬间回滚到上一个版本 image.png
线上监控

监控目标：性能、异常、业务指标

结论

那么，什么是前端工程化呢?它不是一堆工具无意义的堆叠，而是围绕团队技术栈、项目复杂度、开发流程等要素所设计 & 搭建出来的，旨在提升整体开发效率 & 质量的方法论与工具的结合。至少应该涵盖：

  • 需求准入准出: 定义什么事情能做，做到什么程度算完工，开发完成上线后，持续观测需求情况(技术层面+业务层面)——对结果负责:
  • 从左到右的研发规范、规则:定义一件事情怎么做，且应该尽可能自动化，用工具来确保规则被严格执行——对过程负责，

前端主要工作:

  • 参与需求评审，理解要做什么事情，做出技术评估
  • 技术方案设计
  • 需求开发
  • 自测联调
  • 发布上线
  • 持续观测数据
avatar
文章
阅读
粉丝