2020 吾辈在公司推动的前端技术演进

本文最后更新于:2021年3月14日 下午

上古时期

吾辈来的时候已然不多,但部分 mobile 嵌入的静态页面仍然是这种形式

后端模板(JSP/FreeMarker)+ 前端静态 HTML 页面。那是个前端开发非常卑微的时代,除了还原 UI 和兼容性之外,所有业务逻辑、路由跳转、状态管理、部署维护都由后端包办完成。前端能做的事情非常有限,UI 还原、CSS 样式以及浏览器兼容性(例如传统前端需要掌握的精确到 1px 的兼容到 IE6 的高保真切图技巧)是所需的关键技能点,或许还要负责 UI 相关的任务。但这其中,许多更偏向于「手艺人」的工作,而非工程师的技术价值体现,更重要的是,它无法被沉淀为技术人的长期价值

参考: 前端为什么会越来越复杂?
CSS 不是正交的,所以很麻烦,参考: CSS 为什么这么难学?

问题

  • 难以应对大规模的项目开发,几乎没有工程化可言
  • 前后端耦合导致修改、发布困难(就我们公司有个 gw 项目就是反例)
  • 前端能做的事情非常有限,几近是后端的附属(App 有趣的一点就是极大的增强了客户端的能力,许多独立 App 开发者的工具类产品可能对后端的依赖极少)

跨入现代前端: vue + webpack

  • 框架: vue
  • 项目组织: git 分支 + 目录

在吾辈进来的时候基本是这样的

1614382963380

无论如何,前后端分离都已然是大势所趋,公司的项目也不例外,也从 jq 升级为了 vue。vue 是一个及其新手友好的框架,官方文档在前端开源框架中无出其右,所以选择它对招聘确实有一定的帮助(准入门槛低)。

但这里确实存在一些问题,主要如下

  • vue 和 ts 结合的不好,所有前端项目,不是已经用了 ts,就是在走向 ts 的路上(去年 vue3 选择使用 ts 重写 v3)
    • 这是一个设计失误,因为 vue 作者更相信另一个 facebook 的静态类型脚本语言 flow.js,但它最终失败了
  • vue 不是一个创新者,更像是一个现有技术的整合者,更新相比于 react v17/angular v11 慢得多(v3)
  • vue 和 ant design 结合的不好,因为蚂蚁金服使用 react 实现,vue 版本并非官方实现(关于这个 UI 框架的选择其实令吾辈有些困惑)
  • 项目组织方面使用 git 分支 + 目录的形式可能是模仿了后端,但由于目录之间并非模块的形式加上 git 没有规范可言导致没有利用本地模块的优势反而只有劣势
  • 有些项目使用原生 webpack 进行配置打包,而这实际上非常难以维护,参考: webpack 为什么这么难用?

典型项目: 前端旧项目

静态类型: 引入 typescript

  • 语言: typescript
  • 项目组织: 分散的 git 项目

由于使用目录+分支管理的项目组织非常麻烦,所以后面的一些项目采用了每个业务创建一个 git 项目,然后最终将之打包整合到官网(其实就是不同的子路由),独立每个项目的开发和部署。而后希望通过 ts 的静态类型增强前端开发的效率及开发体验(主要是 IDE 在提示、重构和导航方面的支持),所以将之引入了进来,吾辈有自信可以解决任何遇到的 ts 问题。

1614383048466

但老实说,问题仍然没有完全解决

  • ts 和 vue 2 结合的不好,甚至 vue 3 中 ts 也没能解决模板层面的问题,参考: web-types 讨论
  • 分散的 git 项目之间如果存在相同代码,比较难以共享(但因为有 npm 私服所以还不太明显)
  • 组件粒度较粗,比较小的组件难以抽取

典型项目: 新管理后台

替换框架为 react

事实上,引入 react 没有 ts 那么安全,因为这次吾辈不能说吾辈有自信可以解决任何遇到的 react 问题,因为吾辈也没有实际生产环境的经验。但吾辈仍然引入了,有以下几个考量

  • 更好的结合 ts 使用
  • 直接使用官方维护的 ant design for react 版本
  • 相比于 vue 好得多的 IDE 支持
  • 更好的开发大型项目(报告系统)
  • 尝试变化,使用最新的技术

但这仍然并非终点,在报告系统项目中,单个前端项目的代码量首次达到了 2w+ 行(至今已到 4w+),分割模块势在必行,这里就提到了需要使用到 lerna 了。

典型项目: 公开图库

引入 lerna 以使用 monorepo

  • 项目组织: monorepo

Java 后端的项目天然是 monorepo(因为 maven 的原因),而前端在很长时间内都没有类似的工具,直到吾辈遇到了 lerna。这点某位离职的同事有曾提及,但直到几个月后报告系统第一版基本结束时进行重构才真正实用。
使用它吾辈改进了以下几点问题

  • 使用 monorepo 更好的组织模块,保证项目在超过 4w 行代码、20 个模块时仍然保持可维护性
  • 更简单的共享和复用代码,只要抽离一个模块即可在所有模块直接引用它了
  • 更加容易统一整个项目的技术栈,引入一个依赖的不同版本几乎不可能出现了
  • 更加容易容易统一项目的配置,保证整个项目的代码风格都是一致的(例如 eslint/prettier)

1614383172095

典型项目: 旧版报告系统

引入 gh-pages 简化打包

事实上,生产环境的发布一直非常麻烦,即便建宏已经实现了两版的发布系统,但目前使用体验仍然不算好(gw 项目必须要用),但前后端分离的项目却不尽然。后来在一个偶然的情况下,吾辈发现了一种更高效的方式: 使用 gh-pages 发布前端项目,同时喜获冰淇淋一个。

当然,由于后来主要在开发 electron 客户端,web 项目在生产环境的发布变得较少,但这件事仍然证明只要将现有的工具整合起来,仍然可能极大的提高生产力

1614383397001

典型项目-大屏看板

rushstack: 标准化的前端 monorepo

虽然 lerna 可以分割模块,但它并没有所谓的最佳实践,事实上,吾辈在微软的 monorepo 工具 rush 的相关项目 rushstack 中找到了一种最佳实践,在形式上有许多参考价值(虽然由于大而全且包含许多问题的原因导致没有 lerna 使用广泛),最新的两个生产项目均已重构成这种形式的 monorepo 项目,稍晚一些会将它们合并,便于之后它们的整合。

1614431686700

在 rushstack 的介绍中有这么一段话非常有趣:
灵活性有其缺点。Node.js 工具因其令人困惑的选项而臭名昭著:选择您的编译器、linter 工具、打包工具、包管理器、任务引擎、单元测试工具、测试断言库等。一旦决定(下了赌注),整合所有这些组件就变成了自己的软件项目。随着规模的扩大,这些成本可能会迅速增加!
核心就是前端定制需求过多,要求工具链非常灵活,进而导致无法标准化(和现在的报告系统业务面临的问题多么相似。。。)

典型项目 miis

架构

统一和规范

  • 定义统一的业务目录的结构,形成约定俗成
  • 通过更高层的 cli 抽象强制统一 lib 的项目结构,例如入口文件一定是 lib/src/index.ts,出口一定是 dist/index.js,而打包出来的一定默认支持 esm/commonjs
  • 使用 prettier+git hooks 统一项目中的代码风格
  • 通过 syncpack 统一多个模块之间的依赖版本
  • 通过多个模块中的 npm script,例如启动 web 项目的开发环境是 start,启动 electron 开发环境则是 dev:win/mac,打包项目是 build,而 libs 的模块打包发布是 pub,打包 electron 项目是 pkg:*

分层和解耦

  • 通过 monorepo 分割 electron 项目不同的进程,将之作为单独的 nodejs 项目和 react 项目管理和发布
  • 通过使用 api class 的形式,将与后端的连接封装在单独的逻辑层,定义参数、返回值的类型,业务层直接引用相关的单例对象调用方法即可

吾辈也好奇现代前端框架强绑定、重 UI 层的现在,如何更好的分离 UI 与业务逻辑

优化

  • 使用 lerna 的 --include-dependencies --stream 参数尽可能按照依赖顺序并发运行命令,例如打包所有模块
  • 为了减少安装依赖上的麻烦,尝试过 nrm/yrm 改源,npmrc 配置镜像,但最终还是要求所有前端必须能够使用 SSR+透明代理工具,否则无法启动项目
  • 在公司 blog 上分享一些自己的心得和感触
  • 通过使用 docsify 提升文档维护者的体验,使用 VSCode 编辑文档,然后使用 git 提交便自动部署了
  • 引入 storybook 为通用组件编写交互式文档

其他

  • 公司前端文档: 公司的前端项目在线文档,使用 git + markdown 增强开发者编辑体验,希望更多人在更好的维护它
  • common-util: 前端工具库,近期使用 monorepo 将之彻底重构
    至少优化了以下几项
    • 清理不需要的功能,减少了 60% 的代码
    • 使用 monorepo 增强项目的可维护性
    • 支持 nodejs 引入
    • 使用 monorepo 分割打包减小在项目中的引入成本 – babel 的 567 三个版本转变的惨剧历历在目
    • 找到对用户更友好的使用方式 class vs function – 面向对象 vs 函数式
  • web-logger: 前端日志,已在报告系统及之后后所有的前端项目中实用,目前还未支持 nodejs