前端工程化全链路总结（选型，规范，测试，部署，监控，优化，重构）

工程化思想：

目的——提高开发效率，确保项目可扩展、可维护

宗旨——提高团队协作能力，提高开发效率，降低维护成本

如果说计算机科学要解决的是系统的某个具体问题，或者更通俗点说是面向编码的，那么工程化要解决的是如何提高整个系统生产效率。所以，与其说软件工程是一门科学，不如说它更偏向于管理学和方法论。 

前端工程化开发流程：

1. 技术选型
2. 统一规范
3. 测试
4. 部署
5. 监控
6. 性能优化
7. 重构

 

上图是一个比较成熟的前后端协作体系。自Node.js问世以来，前端圈子一直传播着一个词：颠覆。前端工程师要借助Node.js颠覆以往的web开发模式，简单说就是用Node.js取代php、ruby、python等语言搭建web server，在这个颠覆运动中，JavaScript是前端工程师的信心源泉。我们不讨论Node.js与php们的对比，只在可行性这个角度来讲，大前端这个方向吸引越来越多的前端工程师。

随着Node.js的流行开始普及大前端的概念，大前端也可以理解为全栈工程师，全栈的概念与编程语言没有相关性，核心的竞争力是对整个web产品从前到后的理解和掌握。

那么在大前端模式下，构建流程如下图：

大前端体系下，前端开发人员掌握着Node.js搭建的web server层。与上文提到的常规前端开发体系下相比，省略了mock server的角色，但是构建在大前端体系下的作用并没有发生改变。也就是说，不论是大前端还是“小”前端，构建阶段在两种模式下的作用完全一致，构建的作用就是对静态资源以及模板进行处理，换句话说：构建的核心是资源管理。 

目前用大前端的公司还是少，大部分采用前后端分离的方式进行开发，下面根据常见的顺序梳理一下前端开发的流程：

1、技术选型

我们的技术选型是antd4.x + react16 + redux4 + webpack4 + react-router5基础框架

前端架构设计：层次设计

对于前端来说，技术选型挺简单的。就是做选择题，三大框架中选一个。个人认为可以依据以下两个特点来选：

1. 选你或团队最熟的，保证在遇到棘手的问题时有人能填坑。
2. 选市场占有率高的。换句话说，就是选好招人的。

第二点对于小公司来说，特别重要。本来小公司就不好招人，要是还选一个市场占有率不高的框架（例如 Angular），简历你都看不到几个...

目前vue和react用的比较多，我们公司统一技术栈，用的react。

这一步需要设计出构建框架， 包括静态资源的构建。

静态资源包括js、css、图片等文件，目前随着一些新规范和css预编译器的普及，通常开发阶段的静态资源是：

1. es6/7规范的文件；
2. less/sass等文件（具体看团队技术选型）；
3. [可选]独立的小图标，在构建阶段使用工具处理成spirit图片。

构建阶段在处理这些静态文件时，基本的功能应包括：

1. es6/7转译，比如babel；
2. 将less/sass编译成css；
3. spirit图片生成；

以上提到的几个功能可以说是为了弥补浏览器自身功能的缺陷，也可以理解为面向语言本身的，我们可以将这些功能统称为预编译。

除了语言本身，静态资源的构建处理还需要考虑web应用的性能因素。比如开发阶段使用组件化开发模式，每个组件有独立的js/css/图片等文件，如果不做处理每个文件独立上线的话，无疑会增加http请求的数量，从而影响web应用的性能表现。针对诸如此类的问题，构建阶段需要包括以下功能：

1. 依赖打包。分析文件依赖关系，将同步依赖的的文件打包在一起，减少http请求数量；
2. 资源嵌入。比如小于10KB的图片编译为base64格式嵌入文档，减少一次http请求；
3. 文件压缩。减小文件体积；
4. hash指纹。通过给文件名加入hash指纹，以应对浏览器缓存引起的静态资源更新问题；
5. 代码审查。避免上线文件的低级错误；

 

2、统一规范

我们还需要考虑开发和部署，从开发角度，要解决的问题包括：

1. 提高开发生产效率；
2. 降低维护难度。

这两个问题的解决方案有两点：

1. 制定开发规范，提高团队协作能力；
2. 分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。

不管有多少人共同参与同一项目，一定要确保每一行代码都像是同一个人编写的。

开发规范的目的是统一团队成员的编码规范，便于团队协作和代码维护。开发规范没有统一的标准，每个团队可以建立自己的一套规范体系。

代码规范

先来看看统一代码规范的好处：

• 规范的代码可以促进团队合作
• 规范的代码可以降低维护成本
• 规范的代码有助于 code review（代码审查）
• 养成代码规范的习惯，有助于程序员自身的成长

当团队的成员都严格按照代码规范来写代码时，可以保证每个人的代码看起来都像是一个人写的，看别人的代码就像是在看自己的代码。更重要的是我们能够认识到规范的重要性，并坚持规范的开发习惯。

如何制订代码规范

建议找一份好的代码规范，在此基础上结合团队的需求作个性化修改。下面列举一些 star 较多的 js 代码规范：

• airbnb (101k star 英文版)，airbnb-中文版
• standard (24.5k star) 中文版
• 百度前端编码规范 3.9k

css 代码规范也有不少，例如：

• styleguide 2.3k
• spec 3.9k

可使用 eslint 可以检查代码符不符合团队制订的规范。

模块还是组件

 

很多人会混淆模块化开发和组件化开发。但是严格来讲，组件（component）和模块（module）应该是两个不同的概念。两者的区别主要在颗粒度方面。

简单讲，module侧重的是对属性的封装，重心是在设计和开发阶段，不关注runtime的逻辑。module是一个白盒；而component是一个可以独立部署的软件单元，面向的是runtime，侧重于产品的功能性。component是一个黑盒，内部的逻辑是不可见的。

用通俗的话讲，模块可以理解为零件，比如轮胎上的螺丝钉；而组件则是轮胎，是具备某项完整功能的一个整体。具体到前端领域，一个button是一个模块，一个包括多个button的nav是一个组件。

模块和组件的争论由来已久，甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此，使用过bower的同行知道bower安装的第三方依赖目录是bower_component；而npm安装的目录是node_modules。也没必要为了这个争得头破血流，一个团队只要统一思想，保证开发效率就可以了。至于是命名为module还是component都无所谓。

我比较倾向于组件黑盒、模块白盒这种思想。

git 规范

git 规范包括两点：分支管理规范、git commit 规范。

分支管理规范

一般项目分主分支（master）和其他分支。我们公司主要是master，develop分支，在develop上开发打包，也没定期合master。

当有团队成员要开发新功能或改 BUG 时，就从 master 分支开一个新的分支，开发完了再合并回 master 分支。我们这边其实没有严格执行。如果改一个 BUG，也可以从 master 分支开一个新分支，并用 BUG 号命名。

如有必要可以这样干。

git commit 规范

我们commit好像就提了一下，没有规范格式。

其他公司有格式要求：

分为三个部分(使用空行分割):

1. 标题行: 必填, 描述主要修改类型和内容
2. 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
3. 页脚注释: 可以写注释，BUG 号链接

type: commit 的类型

• feat: 新功能、新特性
• fix: 修改 bug
• perf: 更改代码，以提高性能
• refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
• docs: 文档修改
• style: 代码格式修改, 注意不是 css 修改（例如分号修改）
• test: 测试用例新增、修改

其实这样挺好的，提交更清晰明了，以后工作中可以改进。

项目规范

主要是项目文件的组织方式和命名方式。

文件夹首字母小写，驼峰式命名，取名尽量语义化，让人能一眼知道，这个文件夹是干嘛的。

UI 规范

UI 规范需要前端、UI、产品沟通，互相商量，最后制定下来，建议使用统一的 UI 组件库。

制定 UI 规范的好处：

• 统一页面 UI 标准，节省 UI 设计时间
• 提高前端开发效率
  
  

3、测试

测试是前端工程化建设必不可少的一部分，它的作用就是找出 bug，越早发现 bug，所需要付出的成本就越低。并且，它更重要的作用是在将来，而不是当下。

设想一下半年后，你的项目要加一个新功能。在加完新功能后，你不确定有没有影响到原有的功能，需要测试一下。由于时间过去太久，你对项目的代码已经不了解了。在这种情况下，如果没有写测试，你就得手动一遍一遍的去试。我们系统就是这样，早上小倩还说，测试像补漏，这里补了那里漏了。

而如果写了测试，你只需要跑一遍测试代码就 OK 了，省时省力。主要是我们的版本太多了，也挺不容易的。

写测试还可以让你修改代码时没有心理负担，不用一直想着改这里有没有问题？会不会引起 BUG？而写了测试就没有这种担心了。

在前端用得最多的就是单元测试。

单元测试

单元测试就是对一个函数、一个组件、一个类做的测试，它针对的粒度比较小。它应该怎么写呢？

1. 根据正确性写测试，即正确的输入应该有正常的结果。
2. 根据异常写测试，即错误的输入应该是错误的结果。

TDD 测试驱动开发

TDD 就是根据需求提前把测试代码写好，然后根据测试代码实现功能。

TDD 的初衷是好的，但如果你的需求经常变，那就不是一件好事了。很有可能你天天都在改测试代码，业务代码反而没怎么动。

哈哈哈，我们系统就是这样，好像测试组写的自动化没怎么用。

 

4、部署

在没有学会自动部署前，我是这样部署项目的：

1. 推送代码git push。
2. 构建项目npm run build。
3. 将打包好的文件放到静态服务器。

一次两次还行，如果天天都这样，就会把很多时间浪费在重复的操作上。所以我们要学会自动部署，彻底解放双手。自动部署（又叫持续部署 Continuous Deployment，英文缩写 CD）一般有两种触发方式：

1. 轮询。
2. 监听webhook事件。

我们公司用的好像是jekens，每次都是测试和露露弄的，我没怎么搞过，之前公司我用的云效流水线，很方便，jekens本质应该跟那个差不多。（持续集成，持续交付）

 

 

5、监控

监控，又分性能监控和错误监控，它的作用是预警和追踪定位问题。

性能监控

性能监控一般利用window.performance来进行数据采集。

Performance 接口可以获取到当前页面中与性能相关的信息，它是 High Resolution Time API 的一部分，同时也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。

我们系统有监控虚拟机性能，但是对系统本身的监控，可以利用普罗米修斯等第三方服务进行监控，当然前端webpack也有监控分析插件。

监控是为了更好的优化系统，可以从以下几个维度进行分析：

1 重定向耗时
2 DOM 渲染耗时
3 页面加载耗时
4 页面卸载耗时
5 请求耗时
6 获取性能信息时当前时间

通过以下代码实现：

// 收集性能信息
const getPerformance = () => {
    if (!window.performance) return
    const timing = window.performance.timing
    const performance = {
        // 重定向耗时
        redirect: timing.redirectEnd - timing.redirectStart,
        // 白屏时间
        whiteScreen: whiteScreen,
        // DOM 渲染耗时
        dom: timing.domComplete - timing.domLoading,
        // 页面加载耗时
        load: timing.loadEventEnd - timing.navigationStart,
        // 页面卸载耗时
        unload: timing.unloadEventEnd - timing.unloadEventStart,
        // 请求耗时
        request: timing.responseEnd - timing.requestStart,
        // 获取性能信息时当前时间
        time: new Date().getTime(),
    }

    return performance
}

// 获取资源信息
const getResources = () => {
    if (!window.performance) return
    const data = window.performance.getEntriesByType('resource')
    const resource = {
        xmlhttprequest: [],
        css: [],
        other: [],
        script: [],
        img: [],
        link: [],
        fetch: [],
        // 获取资源信息时当前时间
        time: new Date().getTime(),
    }

    data.forEach(item => {
        const arry = resource[item.initiatorType]
        arry && arry.push({
            // 资源的名称
            name: item.name,
            // 资源加载耗时
            duration: item.duration.toFixed(2),
            // 资源大小
            size: item.transferSize,
            // 资源所用协议
            protocol: item.nextHopProtocol,
        })
    })

    return resource
}

另外我们可以给系统安装小脚本来监控用户的动向，也可以用类似百度的，360，或者网站地图等等插件。

用户信息收集

navigator

使用window.navigator可以收集到用户的设备信息，操作系统，浏览器信息...

UV（Unique visitor）

是指通过互联网访问、浏览这个网页的自然人。访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。一天内同个访客多次访问仅计算一个UV。
在用户访问网站时，可以生成一个随机字符串+时间日期，保存在本地。在网页发生请求时（如果超过当天24小时，则重新生成），把这些参数传到后端，后端利用这些信息生成 UV 统计报告。

PV（Page View）

即页面浏览量或点击量，用户每1次对网站中的每个网页访问均被记录1个PV。用户对同一页面的多次访问，访问量累计，用以衡量网站用户访问的网页数量。

页面停留时间

传统网站
用户在进入 A 页面时，通过后台请求把用户进入页面的时间捎上。过了 10 分钟，用户进入 B 页面，这时后台可以通过接口捎带的参数可以判断出用户在 A 页面停留了 10 分钟。

SPA
可以利用 router 来获取用户停留时间，拿 Vue 举例，通过router.beforeEach``destroyed这两个钩子函数来获取用户停留该路由组件的时间。

浏览深度

通过document.documentElement.scrollTop属性以及屏幕高度，可以判断用户是否浏览完网站内容。

页面跳转来源

通过document.referrer属性，可以知道用户是从哪个网站跳转而来。

小结

通过分析用户数据，我们可以了解到用户的浏览习惯、爱好等等信息，用户画像。移动端和pc断，内网系统要求都不一样，toB和toC的也不一样，有针对性的监控。

5、性能优化

性能优化主要分为两类：

1. 加载时优化
2. 运行时优化

例如压缩文件、使用 CDN 就属于加载时优化；减少 DOM 操作，使用事件委托属于运行时优化。在解决问题之前，必须先找出问题，否则无从下手。所以在做性能优化之前，最好先调查一下网站的加载性能和运行性能。

关于性能优化实战，可以看这一篇文章关于系统优化的思考，与网站优化实战

6、重构

《重构2》一书中对重构进行了定义：

所谓重构（refactoring）是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减小整理过程中引入错误的概率。本质上说，重构就是在代码写好之后改进它的设计。

重构和性能优化有相同点，也有不同点。

相同的地方是它们都在不改变程序功能的情况下修改代码；不同的地方是重构为了让代码变得更加易读、理解，性能优化则是为了让程序运行得更快。

重构可以一边写代码一边重构，也可以在程序写完后，拿出一段时间专门去做重构。没有说哪个方式更好，视个人情况而定。

我在职期间，参与重构了移动云和自服务，主要目的是统一技术栈，统一UI规范，简化逻辑，但是这些都是前端重构，后端没重构，还是有改进的空间。

重构的原则

1. 事不过三，三则重构。即不能重复写同样的代码，在这种情况下要去重构。
2. 如果一段代码让人很难看懂，那就该考虑重构了。（云管里面很多）
3. 如果已经理解了代码，但是非常繁琐或者不够好，也可以重构。
4. 过长的函数，需要重构。
5. 一个函数最好对应一个功能，如果一个函数被塞入多个功能，那就要对它进行重构了。

 

总结

以上，就是前端工程化流程。每个公司大同小异，只是规则不同，要求不同，用的工具有差别。

如何打磨？就从上面6个步骤进行精进，可以做的也很多了。

软件工程方面延伸，可以读读《人月神话》。

下图是我整理的关于前端工程化的思维导图。