某科学的前端工程化

本文根据演讲 PPT 口胡输出而成，如有雷同纯属巧合。

开篇，我们先来引入一个问题：什么是前端工程化。

对于我来说，前端工程化大致分为下面的几个内容：

• 代码规范化：eslint
• 流程规范化：git flow / Code Review
• 测试规范化：写不写，怎么写
• 组件与模块：项目与模块治理
• 基础设施：CI / CD
• ……

接下来，我们就开始讲讲，为什么我们要前端工程化，为什么我们要引入这些东西，到底解决了什么问题，我们又该怎么做呢？

Level 1 石器时代

人与动物的区别，是会使用工具。
——马克思

在前端开发刚开始啥都没有，我们经常会说一句话，jQuery 一把梭，而现在，我们引入了各种形形色色的工具：

• eslint
• stylelint
• webpack
• typescript
• 前端框架

他们确实一定程度上解决了我们说的第一点，比如，大家再也不是放飞自我的写代码了，至少有了一个圈，大家在这个圈内，放飞自我的水平就有限，工具帮助了我们更快更好的开发，甚至还能 auto fix。基本上，这是一个强约束，如果你不遵照这个模式去做，你的代码甚至跑不起来。

当然，技术也是在不断发展的，这里顺便延伸出了另一个话题：我们是否要引入新技术。

对于我们来说，要引入一个新技术，主要要考虑以下三点：

• 技术学习的成本
• 周边设施的支持
• 招聘的成本

假设我们想要使用 Rust，那么接下来我们可能需要考虑，我的同事们都会使用 Rust 吗？公司的配套基础设施可以用吗，是不是需要重新研发一套。之后维护代码要怎么办，甚至说，如果我离职了，那么接下来能找到接盘的人吗？如果我们的项目规模大了，要怎么招人——这是热衷技术的新手程序员很容易忽略的一点，大部分热爱技术的新社畜往往会觉得：新技术真香，为什么不用而忽略了边际成本，最终得到了「公司不鼓励技术」的结论。其实所有技术的引入都应该是为了解决公司的问题的。

Level 2 汉穆拉比法典

汉穆拉比法典是历史上第一部系统的法典。

不以规矩，不能成方圆
——孟子

有了工具的强约束，确实能让我们减少放飞自我的可能，但是——API 多了，茴字都能有四种写法呢，怎么样让你的代码整齐划一呢？

首先，就得有一个正常的分支管理策略，在实践中我们发现，分支管理对于开发体验的影响是巨大的，在不好的分支管理下，会引发更多事故；而良好的分支管理对于开发体验还是发版、回滚带来的收益都是巨大的。

下图是一个非常常见的 git flow：

当然，关于 git flow，网上已经有很多文章去讲这些内容了，这里不做赘述，毕竟这篇文章的标题并不是叫 git flow 管理心得，只是笼统的介绍一下，大致用一句话总结就是：从 feature 分支到 develop，要上线时合到 master，hotfix 从 master 切出来。

再来说说一个很多人都会因为时间去忽略的问题：Code Review 的重要性。很多时候，我们会因为「时间不够，急着上线」或者是「代码太多，看不过来」的原因去忽略 Code Review。实际上，编写可维护的代码的秘诀之一就是 Code Review。

提到 Code Review，其实也是一个很大的话题，即使是 Google，也用了很大的篇幅才说清楚了他们的实践，这里大概只说一下我们 Code Review 代码的标准：

• 代码正确的运作
• 代码足够精简
• 有适当的单元测试
• 代码有足够的可读性

代码正确的运作是最低标准；而代码足够精简可以避免冗余的逻辑，代码可读性可以减少维护成本。但在实践中，除了 Code Review 的标准外，我们还提出了一些提交代码必须要注意的事项等等，来辅助我们更好的进行 Code Review。这一点之后有机会再介绍。

Level 3 但愿人没事

名人名言实在编不出来了——敖天羽。

在代码质量，分支管理之后，我们还得更细一步的进行 repo 的管理，这里不仅仅涉及了老生常谈的一点：选择 mono repo 还是 multi repo，更重要的是，我们要保证数据安全，在现实生活中，我们并不能假设每个员工都是可信的，无论是有意还是无意，在市场上已经有过许多起把内部代码「开源」的信息安全事件了，因为 repo 的管理也是非常重要的一点。

在 repo 管理中，我们同样需要遵守「最小权限原则」，只给必要的人仓库权限，尽管在很多人眼里，仿佛是一种公司不够开放的表现，但比起「安全」，开放只是一个名号，而信息安全则是宝贵的资产。

说了这么多代码治理上的内容，终于我们绕回「前端」，接下来，我们要考虑的问题是——组件化。实际上也有很多人问，组件化到底要怎么做。

这里我们绕回两个问题：

1. 需不需要可复用
2. 是不是可复用

开发新手容易陷入一个误区，那就是尽可能的把组件都设计成看上去仿佛可以复用的，又或者是完全不考虑复用性这种两极分化之中；而即使是封装了，也分成了，表面看上去封装了，但实际上完全和没封装一样，过于简化，和由于过度封装，导致定制性不足，非常难用，甚至是不能用，只能自己另起炉灶。

因此，这两个问题的权衡也是非常难的，在每次的业务中，我们也要时常问自己这两个问题，有的时候，甚至可以拉上需求方来一起讨论，在他们可预期的范围内，这个业务大概是怎么样的规模，这是一个特殊的需求，还是未来可能会长期存在；如果给出了含糊其次的说明，那么说明业务方自己也没想明白，现在即使抽象了意义也不大，可以把抽象留在第二次出现这个需求的时候。

真的要说起来，这可能又是一篇长文才能说明白的问题，目前来看，大家时刻记得这两个问题，可以避免一些问题了。

Level 4 流水线生产

上面的问题全部解决了之后，接下来我们的前端开发基本上达到了流水线的阶段，接下来我们要考虑的就是，怎么样这个流水线产能更高。

这里就涉及到了一个更深入的话题：基础设施的重要性。

从实际体验中，每个开发一定都感受过，好用的基础设施和难用的基础设施对于开发人的别急成本有着明显的差别。

我们这里主要讲三点比较常用到的基础设施：

1. 配置中心，之前我有一篇文章讲到过配置中心对于前端的价值，配置中心常用的总结下来可能有以下三点：

   1. 线上开关
   2. 文案修改
   3. 通过配置生成的内容

2. 发布系统，说到开发的话，自然绕不开上线流程，而上线流程，又必然会扯到我们老生常谈的 CICD 了，好用的发布系统万里挑一，而难用的发布系统各有各的难用，在这里我想说的是关于怎么样的发布系统是一个好用的发布系统，大家在实际设计一个发布系统的时候也能参考这样几点去进行一个发布系统的设计与开发：

   1. 编译足够快
   2. 上线足够方便
   3. 回滚足够高效
   4. 新项目无需复杂的配置

3. 页面生成器，要说前端的话，最常被前端谈论的果然还要数页面生成器，这里总结下来一共有以下两种，页面生成器总的来说也是前端一大提效工具和 KPI，在开发的时候可以围绕以下两个问题上手切入：

   1. 营销、活动页面的生成
   2. 中后台表格、表单的生成

总结

这里的总结似乎没什么好说的，毕竟我们只是大致走马观花的看了一下整个前端工程化可以做哪些事情，怎么做比较好，严格的来说，这里的每一个点都能产出一些东西，如果是文章的话也至少可以用一篇或者一个系列去写这些东西，但是总的来说，还是希望大家能多考虑一下以下两句话：

• 完善的流程和设施帮助你更好的搬砖
• 搬砖只是全部流程中的很小一步

参考

• 使用配置进行你的开发
• 谷歌工程实践文档
• 不要使用 Mono Repo