前端工程化治理之路 • Mintnoii

规范是实施成本很低，但收益却很大的一个环节。网上有很多教程，不过大多都是局限于前端的一些规范，这是远远不够的。在实际的开发过程中，我们往往需要与后端，测试，产品一起协作，不能仅限于前端的代码规范。

大概包括这几个方面：

其中我认为比较重要的点，是前端项目的目录结构和接口的命名规范，做好这两点在后期的维护上会节省很多成本。另外协作规范大概率是最难落地的，因为有些时候很多事不是靠个人能去影响或改变的，只能”尽人事，听天命“。

PS: 底层工具的迁移，涉及的范围非常广，因此上线的风险是非常高的。一定要协调好产品，测试，确定上线的时间，提前做好回滚方案和测试方案。

升级打包工具，一般来说都可以带来非常好的效果。绩效可以写：发布流水线，一下子从 20 分钟，缩短到了 8 分钟。平均每个月为开发者节约 80 hour。🤪

因为吃过 webpack4 的苦，所以选择了 vite 启动速度确实快，目前用下来也还不错。后面发布的 rspack 使用 rust 来实现，在这种计算密集的场景下，性能和 node不是一个级别的，即使代码增多，打包时间所受的影响也较为轻微。后续有机会可以尝试。

包管理器从原有的 yarn2.x 升级到了 pnpm。pnpm 的好处不用多讲，总之就是快，而且切换成本低。

改造完成后，我们的线上发布时间在缓存不命中的情况下，也缩短到了4分钟。并给公司的发布流水线加上了服务器缓存，在缓存命中的情况下，包的安装时间只有3秒。

编译工具，包管理的升级，最终使我们的单次发布时间，从15-20分钟，一次性降低到 3-5 分钟左右，开发体验也大大提升。尤其是在测试阶段发现问题时，修复时间大大缩短，不会影响到最终的上线时间。

我们的业务有多个系统，由于是服务同一个业务，因此有很多数据类型，组件，接口都是可以复用的。但我们现有的系统代码，是分散在不同的仓库中的。如果要想复用，往往就是从其他地方直接复制过来，改改就用了。这一方面会有潜在的质量问题，一方面也违反 DRY 的工程原则，难以治理。

使用 monorepo 就可以很好的解决跨系统的组件复用问题。我们采用了 pnpm workspace 方案，新增可以中间依赖的包，存放这些可复用的资源。一年下来，沉淀了有 25+ 个组件，开发提效约 25%。

工作中通常都需要我们根据 antd 这样的社区 UI 组件建设业务组件。而 B 端业务，大部分都是增删改查，因此我们针对通用场景做了标准化组件建设。在做组件时，我们着重做了以下一些事情：

抽取高频组件，并遵循交互规范。没有交互规范的，则拉产品和设计，对齐出一版规范来。
统一化配置。比如 Form、Table、Description 这样的组件，都需要配置所显示的 label，对应的数据字段名，以及显示成什么样子。我们统一使用{ props:'name', label:'姓名', type:'input' } 这样的配置字段，这样可以复用配置字段。
内置一些常用组件。比如使用 { type:select } ，就表示渲染成一个 select，这与 Xrender 非常相似。

如果组件配置实现了很好的一致性，那么就可以很方便的做一些模版填充。因此可以考虑开发一个内置代码模版的 VScode 的插件，比如复杂的 CRUD，编辑表单，编辑页面等。

当用户选中一些 TS 的类型时，它可以读取这个类型中包含的字段，生成配置代码和 mock 数据，填充到内置的模版当中。填充好的代码是直接可以运行的，只需要调整一下适配的字段，真实请求的接口即可。

普遍场景下，开发者在几分钟内就可以完成一个 CRUD 页面的开发。达到了低代码一样的效果，但又避免了低代码带来的种种问题。

todo: 有点鸡肋，难落地

DDD 是后端比较流行的概念，其涉及的内容较多。作为前端，可以借鉴其中一部分的思想。

工程化的治理工作，无论是原创，还是直接采用社区主流的方案都无所谓。但是要注意，整体治理的逻辑，需要是一环套一环，有逻辑、成体系化的，比如有了组件，才有了插件，而因为替换的页面多，才会有静态代码分析的必要。