谈及工程化，大部分团队或许都经历过从无到有、从有到优的实践，在此浅谈我们在前端的一些工程化探索。

一、前世今生

在早期IT行业，Web系统的表现层严格遵循HTML标准，但HTML具有标记语言的局限性，为提高编码效率，业内出现了从Java、PHP、Python等高级语言到HTML模板的动态转译框架[1]，这促使产生了前后端分离的职责分工：一些人编写模板、样式、脚本，另一些人编写业务逻辑。高级语言使用一些复杂特性操纵表现层，即使在今天，大多数系统的技术图谱中，表现层技术都只能占据薄薄的一个尖端，冰山之下则是庞大的、复杂的服务端技术。最近十多年，由于芯片、网络、存储的速度大幅提高，直接推动了Web相关标准的快速演进，一个典型证据是：早期百度搜索需要加载的资源不到10KB，如今已经达到920KB[2]。支撑这接近100倍资源增长的，是ECMAScript、JSON、HTML5/CSS3的标准化。而在标准之外，仅为了实现JavaScript的模块化，即高级语言的import、include语法，国内外就有不下20种方案[3]！为了管理这些表现层的技术，以及在日益复杂的技术栈中解脱出来，以Facebook、淘宝为代表的年轻公司，开始了前端工程化的探索，并创造了一系列衍生技术，这些技术有些被纳入标准，有些被作为最佳实践，得到了业界广泛的追随。

二、最佳实践

在动手操作以前，我们必须认识到：脱离自身真实的场景，就无法衡量某种实践是否“最佳”。我们并非是要复制那些头部公司的工程化方案，而是要挖掘并解决项目开发中急需解决的问题、感到折磨和无力的痛点，工程化这个方向恰好是最关键的切入点，也是我们能够控制的因素中最容易做出改变的、更能引起质变的因素。
我们有哪些痛点？归纳为以下：
一是不可控因素导致的人员水平未形成梯队，我们深度依赖外部人力资源[4]，大家的工作目标不完全一致，导致前期沟通成本、后期维护成本等隐性成本巨大。这些看不见的、不在账面上的成本往往被忽视。
二是工作方法陷入资源池模式，以人力维度进行资源调度。长此以往，项目需求无休止的袭来，人力资源看似得到充分利用，但实际上程序员的创造性被压制，业绩上限也就只能线性增长，而创造性工作[5]带来的增长可能是指数级的，即便是最微小的创新，也能在线性增长时带来更大的斜率。
这两个问题看起来不像是工程化问题，但其他的表层问题基本都由前两点引起，如：
技术栈虽然统一，但互相觉得对方的代码不敢改、难复用，缺少架构设计，代码质量方差较大，涉及编码规范、代码风格、技术评审；
内部框架学习成本高，文档有疏漏、不完整、API和实现不一致，熟悉开源框架，反而在使用内部框架时产生心智负担，涉及文档规范、软件分发机制、技术分享；
重复造轮子，外向程序员可能会在群里吼一句：XXX功能你们有人做过吗？多数内向程序员会用最短的时间，以最快的速度，写个轮子出来。因为自己写个轮子甚至比用别人的轮子要快很多且更放心，涉及组件库、公共仓库、资源管理平台；
重开发、轻运营，项目做完就交差，某一天突然被拉进一个群，名为“XXX缺陷修复沟通群”，在代码堆中翻来翻去终于找到问题，发现提交的人已经不在了，涉及backup机制、异常监控、owner意识；
这些问题就像是工程化问题了。

三、实践历程

一旦想清楚问题究竟是什么，找到答案就只是时间问题了。以下我从技术角度，用问答的形式描述工程化落地的一些实践和思考。
关于编码规范
Q：建立编码规范几乎是人人都会做的事情，但如何落实？你怎么保证别人的代码符合你的规范？他愿意遵守吗？他有没有措施可以绕过或欺骗你的规则？
A：编码规范无非是一个PDF或Confluence资源，没有任何约束力；Code Review的沟通成本太高。我们做的方案包括把规范具化到每一个项目的配置文件中，最终目标是结合IDE插件，可以在编码时就实时产生约束；现在已经实现了在Git提交前，检查增量代码的规范性，不符合规范的代码会抛出异常停止提交，经过这种强约束介入，可以大幅减少人工Code Review的时间。
Q：已有的项目怎么集成编码规范的配置文件呢？就算集成了，怎么保证配置不被篡改呢？
A：既然有人会篡改，比如把ESLint的规则全部注释掉，那么就说明这个规范本身有问题。我们提供了一个命令行工具，在仓库根目录执行，可以把一份公共的、由全体开发人员共同维护的配置文件加载到项目中，完成初始化。随着规范的演进，这个配置文件也可以通过命令行工具进行更新。
关于文档规范
Q：文档先于代码。但是随着版本迭代，文档逐渐跟不上代码变化的速度了，写代码5分钟，更新文档要10分钟，怎么高效维护文档？
A：首先我们拒绝Word、PDF这些静态的、无法保持更新的文档工具，其次也不会使用Confluence这种在线协同文档，你一定会花费大量的时间来调整文档样式。最适合技术文档的工具是Markdown，重视内容，也有不错的可读性，更重要的是，它支持（绝大多数）HTML语法，这意味着你的文档不是一堆干巴巴的功能描述，而是一个动态的、可以体验的、甚至可以在线调试的DEMO。有很多开源文档工具，我们选择了VuePress[6]，它包含以上所有优点，并且原生支持Vue组件。你的库发布新版本了，VuePress构建文档时也会更新依赖，你的DEMO也就自动更新了，因此只要编写Markdown的API描述就可以了。
Q：内部框架如何持续更新？如何保证项目使用合适的版本？
A：文档规范很难像编码规范采取类似的硬性措施，因为写文档、写框架更多的是出于程序员自发的技术热情，但这少数人的技术热情可以带动整体的技术氛围，通过技术交流、分享等方式，可以影响更多人参与其中，这比规范的文档更有效。对于使用者来说，NPM版本号应该使用“~”前缀来确保依赖自动升级。我们的项目在上线之前，都会通过package-lock.json[7]对所有依赖进行版本锁定，保证集成测试环境和生产环境的依赖版本一致。
关于公共资源
Q：有经验的程序员都会写一些公共方法、通用类，放到公共目录下或发布为依赖库，但为什么还会重复造轮子呢？
A：前端代码往往是和业务需求紧密结合的，一个代码工程就是一个业务系统，所有代码都是为了这个业务系统而专门编写的。所以你会看到每个工程都有网络库配置、UI库配置，且配置有细微的不同，提取公共部分作为依赖库会缺乏灵活性，没有哪个公共库可以支撑未来的需求变化，索性复制一套已有的配置再删改，但人工删改容易出错。这就体现了Code Snippet的作用，我们的目标是搭建一个资源管理后台，其中一个模块可以维护常用代码片段，通过评审发布的代码片段需要有详细的使用说明、注释。这样就算是造轮子，也是按照一个模具来造的，可能只是“轮毂”不一样，可维护性更好。
Q：如何保证组件库的质量？我想优化别人写的组件怎么做？我怎么知道某个功能有没有人实现过？
A：能够抽象到公共组件库中的功能，应当至少有两个以上项目使用到，否则没有意义。由于有多个项目正在使用，组件的代码质量自然就得到了验证和保证。对于公共函数，例如深拷贝、大数转换、树的遍历，还需要写单元测试。每个组件库除了有规范的文档外，还要登记到资源管理后台，并维护每个具体业务组件的版本号、开发人员，资源信息做到公开可检索。
关于项目维护
Q：项目如何做到长期维护？如何降低维护成本？
A：根据代码托管平台的统计，大多数项目每迭代一段时间就到了不得不整体重构的地步，甚至有些著名项目会因为难以重构而停止维护，这其中并不都是因为代码写的烂，而是后来的人对先前的业务逻辑不了解。我们的内部项目也如此，程序员不可能一直维护一个项目，当第三方依赖更新、被混入恶意代码、出现偶发Bug，就要付出成本去维护，我们能做的只有将维护成本减到最低：backup机制。类似于离职时的工作交接，保证任何一个模块任意时刻都有至少两个人懂具体逻辑。我们有很多小项目都是由单人独立负责的，这种情况可以通过代码Review来促进其他人对这个项目的了解，可以采取轮换方式，定期的刻意互换项目来做，短期对个体而言付出一些学习成本，但长期对整体而言是更稳健的。
Q：很多项目在生产环境的问题，其他环境难以调试，只能借用户的账号上去调试？
A：我们在逐步引入一个统一的开源监控插件，它可以采集每个页面的行为日志，基于组件树信息提供用户操作的回放，这样就避免用户描述复现步骤，再去根据报错的函数调用栈推测问题了。同时监控后台可以列出各个项目的性能指标、执行情况、报错数量，让每个人了解所负责的项目究竟在线上是什么样的，这些指标在业界平均水平是多少[8]，都可以量化出来。

四、结语
前端工程化还有很多高级的话题，如低代码、智能化，我们仅仅思考和改善了一些目前最迫切的痛点，最重要的是，我们试图找到自己的节奏，让项目需求融入到我们的步伐中。

参考链接：
[1]. 浅谈JSP：https://zhuanlan.zhihu.com/p/42343690
[2]. 收录过去的网站：http://www.wayback.com/
[3]. JavaScript的模块：https://www.ruanyifeng.com/blog/2012/10/javascript_module.html
[4]. 银行业IT服务外包：https://wenku.baidu.com/view/8222d3e8541810a6f524ccbff121dd36a32dc47e.html
[5].《黑客与画家》：https://book.douban.com/subject/6021440/
[6]. https://vuepress.vuejs.org/zh/
[7]. https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json/
[8]. https://developer.mozilla.org/zh-CN/docs/Web/Performance