前端工程化衡量准则

小编说：前端工程化这个概念在近两年被广泛地提及和讨论，究其原因，是前端工程师所负责的客户端功能逻辑在不断复杂化。本文介绍了前端工程化的衡量准则以及3个阶段。

如果说互联网时代是前端工程师的舞台可能有些夸大其词，但前端工程师绝对撑起了互联网应用开发的“半壁江山”。传统网站、手机应用、桌面应用、微信小程序等，前端工程师已经不是几年前被谑称的“切图仔”了。以往的“写demo，套模板”模式已经严重拖累了前端开发以及整体团队的开发效率。在这样的时代背景下，前端工程化便应运而生了。

虽然前端工程化是最近几年才兴起的一个方向，但工程化并不是一个新词。前端工程师普遍不熟悉的其他开发领域很早就具备了高度的工程化，比如Web服务器端开发。在前端业务逻辑比较简单的年代，前端资源通常作为服务器端资源的一种“附属品”，Web开发者没有意识到且也没有必要为前端制定专门的工程化方案。前端需求和逻辑的不断加重是催生前端工程化的环境因素，前端相关技术、规范和工具的发展是前端工程化得以实施的必要前提。

前端工程化的衡量准则

前端工程化的主要目标是解放生产力、提高生产效率。通过制定一系列的规范，借助工具和框架解决前端开发以及前后端协作开发过程中的痛点和难点问题。

前后端分离是前端工程化方案的指导方针，这三者也就成为衡量前端工程化方案是否合格的重要因素。具体的衡量标准就是我们常说的3个字：快、准、稳。

1．从开发角度衡量工程化主要体现在“快”。

开发速度是Web产品迭代最迫切提升，也是催生开发人员与产品经理、项目经理以及测试人员之间矛盾的主要因素，自然也是衡量前端工程化方案最直观、最明显的标准。工程化方案的核心目标之一就是在保证质量的前提下，尽可能提高产品的开发速度。

2．从测试角度衡量工程化主要体现在“快”和“准”。

测试的“快”体现在前端工程师和服务器端工程师并行开发完成之后的集成测试阶段。我们从测试角度分析前后端分离时提到了完备且合理的单元测试通过后，集成测试阶段是不应该存在逻辑性错误的。但人不是机器，不可能考虑得面面俱到。从这个角度考虑，工程化要解决的就是尽量减少低级的逻辑错误，降低集成测试阶段消耗的时间成本。

测试的“准”体现在集成测试阶段对问题的准确定位。工程化不仅仅是冷冰冰的工具和平台，同时也需要严格的分工制度。通过明确责任人，对测试出现的问题进行快速准确的定位。

3．从部署角度衡量工程化主要体现在“稳”。

部署是一个完整迭代周期的最终阶段。经历了漫长的开发和测试，团队中的所有成员都希望自己的产品能够第一时间完美无误地出现在用户面前。部署并不是简单地把文件“放到”线上就可以了，还需要考虑用户客户端的缓存是否影响了新版本的展现、考虑测试用例没有覆盖100%情况下的危机处理、考虑不同地区开放不同版本等。如果你想将Web产品稳稳地呈现给用户，部署环节必须把好最后也是最关键的一关。

前端工程化的3个阶段

1．本地工具链——工程化不等同于工具化

你也许会有这样的念头：所谓的前端工程化不就是把一系列工具进行整合吗？工程化的核心难道就是工具化？

虽然对前端工程化的论述中反复提到了“工具”这个词，但工程化的核心并非工具。前端工程化是以规范工作流程为手段，以工具为实现媒介，其最终目的是为了提高研发效率以及保证Web产品的线上质量。如果给前端工程化一个明确定义的话，较恰当的定义如下：前端工程化是一系列工具和规范的组合，规范为蓝本，工具为实现。其中规范又包括：

项目文件的组织结构，比如使用目录名称区分源文件和目标文件。

源代码的开发范式，比如使用既定的模块化方案。

工具的使用规范，比如工程化自身的配置规范。

各阶段环境的依赖，比如部署功能的实现需要目标服务器提供SSH权限。

工具的作用是将规范具化为具体功能并且在一定程度上将开发者限定在既有规范内。前端工程化的初级阶段便是将各类工具的功能进行整合，为业务开发人员提供统一规范的工具栈。我们不妨将此阶段的前端工程化称为本地工具链形态。此形态下的所有工程化功能模块，包括构建、本地服务器、部署等，均在本地环境下工作。

本地工具链形态的工程化方案解决的问题，降低了业务开发人员学习、使用工具的成本。这个方案将复杂的功能需求全部交给工具链内部解决，你可以将这个形态的方案想象成一只拥有高度内部复杂度的“八爪鱼”，其伸出的触手是内部功能开放给业务开发人员使用的接口。

工具链的统一，另一个好处是巩固了流程的规范性，开发者使用统一的工具链、遵循统一的规范进行业务代码的编写，利于多人协作与程序的维护。

2．管理平台——进一步淡化差异、加深规范

本地工具链形态的工程化虽然解决了前端开发以及前后端协作开发中的部分痛点问题，但由于所有的功能模块均在本地环境工作，因此必然会受到环境差异性的影响，比如操作系统类型、版本、内核等。这些因素会在一定程度上影响构建产出代码的一致性。

除环境因素的影响，本地工具链形态的工程化还存在安全性隐患。举个例子，部署功能模块负责将构建产出的文件部署到测试或者线上服务器，部署过程中必然涉及权限问题。对安全性要求不高的测试环境也就罢了，但如果人人都可以向生产环境部署文件则必然存在很大的安全隐患。所以，权限必须严格控制，这就造成本地工具链的部署模块的可用性大大降低。

讲到这里，前端工程化的下一进化形态便豁然开朗了：集中管理的云平台。管理平台形态的工程化做到了以下几点。

淡化环境差异性，保证构建产出的一致性。

权限集中管理，提高安全性。

项目版本集中管理，便于危机处理，比如版本回滚等。

管理平台形态将各个功能模块的执行环境集中化，从各模块实现角度来讲与本地工具链基本一致。

3．持续集成——前端工程化的目标是融入整体

即使进化到管理平台形态，前端工程化方案所解决问题的本质仍然只是将前端工程师与服务器端工程师的工作解耦。这虽然提高了两方的工作效率，但其各自的工作流却是孤立的。前端有了构建和部署，后端也有了相应的阶段，两方的工作流是分离的，最终的融合工作仍然难以避免烦琐的人工操作。举个例子，如果需要生产环境版本回滚，前后端工程师分别对自己所维护的代码进行操作，并且必须保证回滚操作的同步性，这期间难以避免人工上的沟通。

不论前端工程化的功能如何完备，规范如何严谨，需要谨记的是，前端工程化必然是整体Web工作流中间的一个子集方案。前端工程化最终的完美形态，必然与整体工作流结合，作为持续集成方案中的一环。谨记这条原则可以在探索完美方案过程中少走弯路。