前言

近年来，随着浏览器性能的提升与移动互联网浪潮的汹涌而来，Web前端开发进入了高歌猛进，日新月异的时代。这是最好的时代，我们永远在前行，这也是最坏的时代，无数的前端开发框架、技术体系争妍斗艳，让开发者们陷入困惑，乃至于无所适从。

Web前端开发可以追溯于1991年蒂姆·伯纳斯-李公开提及HTML描述，而后1999年W3C发布HTML4标准，这个阶段主要是BS架构，没有所谓的前端开发概念，网页只不过是后端工程师的顺手之作，服务端渲染是主要的数据传递方式。接下来的几年间随着互联网的发展与REST等架构标准的提出，前后端分离与富客户端的概念日渐为人认同，我们需要在语言与基础的API上进行扩充，这个阶段出现了以jQuery为代表的一系列前端辅助工具。2009年以来，智能手机开发普及，移动端大浪潮势不可挡，SPA单页应用的设计理念也大行其道，相关联的前端模块化、组件化、响应式开发、混合式开发等等技术需求甚为迫切。这个阶段催生了Angular 1、Ionic等一系列优秀的框架以及AMD、CMD、UMD与RequireJS、SeaJS等模块标准与加载工具，前端工程师也成为了专门的开发领域，拥有独立于后端的技术体系与架构模式。

而近两年间随着Web应用复杂度的提升、团队人员的扩充、用户对于页面交互友好与性能优化的需求，我们需要更加优秀灵活的开发框架来协助我们更好的完成前端开发。这个阶段涌现出了很多关注点相对集中、设计理念更为优秀的框架，譬如 React 、 VueJS 、 Angular2 等组件框架允许我们以声明式编程来替代以DOM操作为核心的命令式编程，加快了组件的开发速度，并且增强了组件的可复用性与可组合性。而遵循函数式编程的 Redux 与借鉴了响应式编程理念的 MobX 都是非常不错的状态管理辅助框架，辅助开发者将业务逻辑与视图渲染剥离，更为合理地划分项目结构，更好地贯彻单一职责原则与提升代码的可维护性。在项目构建工具上，以 Grunt 、 Gulp 为代表的任务运行管理与以 Webpack 、 Rollup 、 JSPM 为代表的项目打包工具各领风骚，帮助开发者更好的搭建前端构建流程，自动化地进行预处理、异步加载、Polyfill、压缩等操作。而以NPM/Yarn为代表的依赖管理工具一直以来保证了代码发布与共享的便捷，为前端社区的繁荣奠定了重要基石。

纷扰

分久必合，合久必分啊，无论是前端开发中各个模块的分割还是所谓的前后端分离，都不能形式化的单纯按照语言或者模块来划分，还是需要兼顾功能，合理划分。

任何一个编程生态都会经历三个阶段：

• 第一个是原始时期，由于需要在语言与基础的API上进行扩充，这个阶段会催生大量的Tools。
• 第二个阶段，随着做的东西的复杂化，需要更多的组织，会引入大量的设计模式啊，架构模式的概念，这个阶段会催生大量的Frameworks。
• 第三个阶段，随着需求的进一步复杂与团队的扩充，就进入了工程化的阶段，各类分层MVC，MVP，MVVM之类，可视化开发，自动化测试，团队协同系统。这个阶段会出现大量的小而美的Library。

本文的主旨希望能够尽可能地脱离工具的束缚，回归到前端工程化的本身，回归到语言的本身，无论React、AngularJS、VueJS，它们更多的意义是辅助开发，为不同的项目选择合适的工具，而不是执念于工具本身。总结而言，目前前端工具化已经进入到了非常繁荣的时代，随之而来很多前端开发者也甚为苦恼，疲于学习。工具的变革会非常迅速，很多优秀的工具可能都只是历史长河中的一朵浪花，而蕴藏其中的工程化思维则会恒久长存。无论你现在使用的是React还是Vue还是Angular 2或者其他优秀的框架，都不应该妨碍我们去了解尝试其他。

工具化

我们学习的速度已经跟不上新框架新概念涌现的速度，用于学习上的成本远大于实际开发项目的成本。我们不一定要去用最新最优秀的工具，但是我们有了更多的选择余地，相信这一点对于大部分非处女座人士而言都是喜讯。

工具化是有意义的。工具的存在是为了帮助我们应对复杂度，在技术选型的时候我们面临的抽象问题就是应用的复杂度与所使用的工具复杂度的对比。工具的复杂度是可以理解为是我们为了处理问题内在复杂度所做的投资。为什么叫投资？那是因为如果投的太少，就起不到规模的效应，不会有合理的回报。这就像创业公司拿风投，投多少是很重要的问题。如果要解决的问题本身是非常复杂的，那么你用一个过于简陋的工具应付它，就会遇到工具太弱而使得生产力受影响的问题。反之，是如果所要解决的问题并不复杂，但你却用了很复杂的框架，那么就相当于杀鸡用牛刀，会遇到工具复杂度所带来的副作用，不仅会失去工具本身所带来优势，还会增加各种问题，例如培训成本、上手成本，以及实际开发效率等。

所谓GUI应用程序架构，就是对于富客户端的代码组织/职责划分。纵览这十年内的架构模式变迁，大概可以分为MV与Unidirectional两大类，而Clean Architecture则是以严格的层次划分独辟蹊径。从MVC到MVP的变迁完成了对于View与Model的解耦合，改进了职责分配与可测试性。而从MVP到MVVM，添加了View与ViewModel之间的数据绑定，使得View完全的无状态化。最后，整个从MV到Unidirectional的变迁即是采用了消息队列式的数据流驱动的架构，并且以Redux为代表的方案将原本MV*中碎片化的状态管理变为了统一的状态管理，保证了状态的有序性与可回溯性。 具体到前端的衍化中，在Angular 1兴起的时代实际上就已经开始了从直接操作Dom节点转向以状态/数据流为中心的变化，jQuery 代表着传统的以 DOM 为中心的开发模式，但现在复杂页面开发流行的是以 React 为代表的以数据/状态为中心的开发模式。应用复杂后，直接操作 DOM 意味着手动维护状态，当状态复杂后，变得不可控。React 以状态为中心，自动帮我们渲染出 DOM，同时通过高效的 DOM Diff 算法，也能保证性能。

工具化的不足：抽象漏洞定理

抽象漏洞定理是Joel在2002年提出的，所有不证自明的抽象都是有漏洞的。抽象泄漏是指任何试图减少或隐藏复杂性的抽象，其实并不能完全屏蔽细节，试图被隐藏的复杂细节总是可能会泄漏出来。抽象漏洞法则说明：任何时候一个可以提高效率的抽象工具，虽然节约了我们工作的时间，但是，节约不了我们的学习时间。我们在上一章节讨论过工具化的引入实际上以承受工具复杂度为代价消弭内在复杂度，而工具化滥用的结局即是工具复杂度与内在复杂度的失衡。

谈到这里我们就会明白，不同的项目具备不同的内在复杂度，一刀切的方式评论工具的好坏与适用简直耍流氓，而且我们不能忽略项目开发人员的素质、客户或者产品经理的素质对于项目内在复杂度的影响。对于典型的小型活动页，譬如某个微信H5宣传页，往往注重于交互动画与加载速度，逻辑复杂度相对较低，此时Vue这样渐进式的复杂度较低的库就大显身手。而对于复杂的Web应用，特别是需要考虑多端适配的Web应用，尽量使用React这样相对规范严格的库。

React？Vue？Angular 2？

React，Vue，Angular 2都是非常优秀的库与框架，它们在不同的应用场景下各自具有其优势。Vue最大的优势在于其渐进式的思想与更为友好的学习曲线，Angular 2最大的优势其兼容并包形成了完整的开箱即用的All-in-one框架，而这两点优势在某些情况下反而也是其劣势，也是部分人选用React的理由。很多对于技术选型的争论乃至于谩骂，不一定是工具的问题，而是工具的使用者并不能正确认识自己或者换位思考他人所处的应用场景，最终吵的驴唇不对马嘴。

小而美的视图层

React 与 VueJS 都是所谓小而美的视图层Library，而不是Angular 2这样兼容并包的Frameworks。任何一个编程生态都会经历三个阶段，第一个是原始时期，由于需要在语言与基础的API上进行扩充，这个阶段会催生大量的Tools。第二个阶段，随着做的东西的复杂化，需要更多的组织，会引入大量的设计模式啊，架构模式的概念，这个阶段会催生大量的Frameworks。第三个阶段，随着需求的进一步复杂与团队的扩充，就进入了工程化的阶段，各类分层MVC，MVP，MVVM之类，可视化开发，自动化测试，团队协同系统。这个阶段会出现大量的小而美的Library。
React 并没有提供很多复杂的概念与繁琐的API，而是以最少化为目标，专注于提供清晰简洁而抽象的视图层解决方案，同时对于复杂的应用场景提供了灵活的扩展方案，典型的譬如根据不同的应用需求引入MobX/Redux这样的状态管理工具。React在保证较好的扩展性、对于进阶研究学习所需要的基础知识完备度以及整个应用分层可测试性方面更胜一筹。不过很多人对React的意见在于其陡峭的学习曲线与较高的上手门槛，特别是JSX以及大量的ES6语法的引入使得很多的传统的习惯了jQuery语法的前端开发者感觉学习成本可能会大于开发成本。与之相比Vue则是典型的所谓渐进式库，即可以按需渐进地引入各种依赖，学习相关地语法知识。比较直观的感受是我们可以在项目初期直接从CDN中下载Vue库，使用熟悉的脚本方式插入到HTML中，然后直接在script标签中使用Vue来渲染数据。随着时间的推移与项目复杂度的增加，我们可以逐步引入路由、状态管理、HTTP请求抽象以及可以在最后引入整体打包工具。这种渐进式的特点允许我们可以根据项目的复杂度而自由搭配不同的解决方案，譬如在典型的活动页中，使用Vue能够兼具开发速度与高性能的优势。不过这种自由也是有利有弊，所谓磨刀不误砍材工，React相对较严格的规范对团队内部的代码样式风格的统一、代码质量保障等会有很好的加成。
一言蔽之，Vue会更容易被纯粹的前端开发者的接受，毕竟从直接以HTML布局与jQuery进行数据操作切换到指令式的支持双向数据绑定的Vue代价会更小一点，特别是对现有代码库的改造需求更少，重构代价更低。而React及其相对严格的规范可能会更容易被后端转来的开发者接受，可能在初学的时候会被一大堆概念弄混，但是熟练之后这种严谨的组件类与成员变量/方法的操作会更顺手一点。便如Dan Abramov所述，Facebook推出React的初衷是为了能够在他们数以百计的跨平台子产品持续的迭代中保证组件的一致性与可复用性。

函数式思维：抽象与直观

近年来随着应用业务逻辑的日益复杂与并发编程的大规模应用，函数式编程在前后端都大放异彩。软件开发领域有一句名言：可变的状态是万恶之源，函数式编程即是避免使用共享状态而避免了面向对象编程中的一些常见痛处。函数式编程不可避免地会使得业务逻辑支离破碎，反而会降低整个代码的可维护性与开发效率。与React相比，Vue则是非常直观的代码架构，每个Vue组件都包含一个script标签，这里我们可以显式地声明依赖，声明操作数据的方法以及定义从其他组件继承而来的属性。而每个组件还包含了一个template标签，等价于React中的render函数，可以直接以属性方式绑定数据。最后，每个组件还包含了style标签而保证了可以直接隔离组件样式。我们可以先来看一个典型的Vue组件，非常直观易懂，而两相比较之下也有助于理解React的设计思想。

在现代浏览器中，对于JavaScript的计算速度远快于对DOM进行操作，特别是在涉及到重绘与重渲染的情况下。并且以JavaScript对象代替与平台强相关的DOM，也保证了多平台的支持，譬如在ReactNative的协助下我们很方便地可以将一套代码运行于iOS、Android等多平台。总结而言，JSX本质上还是JavaScript，因此我们在保留了JavaScript函数本身在组合、语法检查、调试方面优势的同时又能得到类似于HTML这样声明式用法的便利与较好的可读性。

前后端分离与全栈:技术与人

前后端分离与全栈并不是什么新鲜的名词，都曾引领一时风骚。Web前后端分离优势显著，对于整个产品的开发速度与可信赖性有着很大的作用。全栈工程师对于程序员自身的提升有很大意义，对于项目的初期速度有一定增速。如果划分合理的话能够促进整个项目的全局开发速度与可信赖性，但是如果划分不合理的话只会导致项目接口混乱，一团乱麻。

我们常说的前后端分离会包含以下两个层面：

• 将原本由服务端负责的数据渲染工作交由前端进行，并且规定前端与服务端之间只能通过标准化协议进行通信。
• 组织架构上的分离，由早期的服务端开发人员顺手去写个界面转变为完整的前端团队构建工程化的前端架构。

前后端分离本质上是前端与后端适用不同的技术选型与项目架构，不过二者很多思想上也是可以融会贯通，譬如无论是响应式编程还是函数式编程等等思想在前后端皆有体现。而全栈则无论从技术还是组织架构的划分上似乎又回到了按照需求分割的状态。不过呢，我们必须要面对现实，很大程度的工程师并没有能力做到全栈，这一点不在于具体的代码技术，而是对于前后端各自的理解，对于系统业务逻辑的理解。如果我们分配给一个完整的业务块，同时，那么最终得到的是无数个碎片化相互独立的系统。

相辅相成的客户端渲染与服务端渲染

最初的网页是数据、模板与样式的混合，即以经典的APS.NET、PHP与JSP为例，是由服务端的模板提供一系列的标签完成从业务逻辑代码到页面的流动。所以，前端只是用来展示数据，所谓附庸之徒。而随着Ajax技术的流行，将WebAPP也视作CS架构，抽象来说，会认为CS是客户端与服务器之间的双向通信，而BS是客户端与服务端之间的单向通信。换言之，网页端本身也变成了有状态。从初始打开这个网页到最终关闭，网页本身也有了一套自己的状态，而拥有这种变化的状态的基础就是AJAX，即从单向通信变成了双向通信。

而近两年来随着React的流行服务端渲染的概念重回人们的视线。需要强调的是，我们现在称之为服务端渲染的技术并非传统的以JSP、PHP为代表的服务端模板数据填充，更准确的服务端渲染作用的描述是对于客户端应用的预启动与预加载。我们千方百计将客户端代码拉回到服务端运行并不是为了替换现有的API服务器，并且在服务端运行过的代码同样需要在客户端重新运行。

引入服务端渲染带来的优势主要在于以下三个方面：

• 对浏览器兼容性的提升，目前React、Angular、Vue等现代Web框架纷纷放弃了对于旧版本浏览器的支持，引入服务端渲染之后至少对于使用旧版本浏览器的用户能够提供更加友好的首屏展示，虽然后续功能依然不能使用。

• 对搜索引擎更加友好，客户端渲染意味着整体的渲染用脚本完成，这一点对于爬虫并不友好。虽然现代爬虫往往也会通过内置自动化浏览器等方式支持脚本执行，但是这样无形会加重很多爬虫服务器的负载，因此Google这样的大型搜索引擎在进行网页索引的时候还是依赖于文档本身。如果你希望提升在搜索引擎上的排行，让你的网站更方便地被搜索到，那么支持服务端渲染是个不错的选择。

• 整体加载速度与用户体验优化，在首屏渲染的时候，服务端渲染的性能是远快于客户端渲染的。不过在后续的页面响应更新与子视图渲染时，受限于网络带宽与重渲染的范畴，服务端渲染是会弱于客户端渲染。另外在服务端渲染的同时，我们也会在服务端抓取部分应用数据附加到文档中，在目前HTTP/1.1仍为主流的情况下可以减少客户端的请求连接数与时延，让用户更快地接触到所需要的应用数据。

总结而言，服务端渲染与客户端渲染是相辅相成的，在React等框架的协助下我们也可以很方便地为开发阶段的纯客户端渲染应用添加服务端渲染支持。

项目中的全栈工程师:技术全栈，需求隔离，合理分配

全栈工程师对于个人发展有很大的意义，对于实际的项目开发，特别是中小创公司中以进度为第一指挥棒的项目而言更具有非常积极的意义。但是全栈往往意味着一定的Tradeoff，步子太大，容易扯着蛋。任何技术架构和流程的调整，最好都不要去违背康威定律，即设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。有些全栈的结果就是强行按照功能来分配任务，即最简单的来说可能把登录注册这一块从数据库设计、服务端接口到前端界面全部分配给一个人或者一个小组完成。然后这个具体的执行者，因为其总体负责从上到下的全部逻辑，在很多应该规范化的地方，特别是接口定义上就会为了求取速度而忽略了必要的规范。最终导致整个系统支离破碎成一个又一个的孤岛，不同功能块之间表述相同意义的变量命名都能发生冲突，各种奇形怪状的id、uuid、{resource}_id令人眼花缭乱。

现代经济发展的一个重要特征就是社会分工日益精细明确，想要成为无所不知的通才不过南柯一梦。在自己的小团队中应该提倡职位轮替，一般某个项目周期完成后会调换部分前后端工程师的位置，一方面是为了避免繁杂的事务性开发让大家过于疲惫。另一方面也是希望每个人都了解对方的工作，这样以后出Bug的时候就能换位思考，毕竟团队内部矛盾，特别是各个小组之间的矛盾一直是项目管理中头疼的问题。

工程化

所谓工程化，即是面向某个产品需求的技术架构与项目组织，工程化的根本目标即是以尽可能快的速度实现可信赖的产品。尽可能短的时间包括开发速度、部署速度与重构速度，而可信赖又在于产品的可测试性、可变性以及Bug的重现与定位。

• 开发速度：开发速度是最为直观、明显的工程化衡量指标，也是其他部门与程序员、程序员之间的核心矛盾。绝大部分优秀的工程化方案首要解决的就是开发速度，我们在追寻局部速度最快的同时不能忽略整体最优，初期单纯的追求速度而带来的技术负债会为以后阶段造成不可弥补的损害。
• 部署速度：程序员在日常工作中，最常对测试或者产品经理说的一句话就是，我本地改好了，还没有推送到线上测试环境呢。在DevOps概念深入人心，各种CI工具流行的今天，自动化编译与部署帮我们省去了很多的麻烦。但是部署速度仍然是不可忽视的重要衡量指标，特别是以NPM为代表的难以捉摸的包管理工具与不知道什么时候会抽个风的服务器都会对我们的编译部署过程造成很大的威胁，往往项目依赖数目的增多、结构划分的混乱也会加大部署速度的不可控性。
• 重构速度：听产品经理说我们的需求又要变了，听技术Leader说最近又出了新的技术栈，甩现在的十万八千里。
• 可测试性：现在很多团队都会提倡测试驱动开发，这对于提升代码质量有非常重要的意义。而工程方案的选项也会对代码的可测试性造成很大的影响，可能没有无法测试的代码，但是我们要尽量减少代码的测试代价，鼓励程序员能够更加积极地主动地写测试代码。
• 可变性：程序员说：这个需求没法改啊！
• Bug的重现与定位：没有不出Bug的程序，特别是在初期需求不明确的情况下，Bug的出现是必然而无法避免的，优秀的工程化方案应该考虑如何能更快速地辅助程序员定位Bug。

无论是前后端分离，还是后端流行的MicroService或者是前端的MicroFrontend，其核心都是牺牲局部开发速度换来更快地全局开发速度与系统的可信赖性的提高。而区分初级程序员与中级程序员的区别可能在于前者仅会实现，仅知其然而不知其所以然，他们唯一的衡量标准就是开发速度，即功能实现速度或者代码量等等，不一而足。中级程序员则可以对自己负责范围内的代码同时兼顾开发速度与代码质量，会在开发过程中通过不断地Review来不断地合并分割，从而在坚持SRP原则的基础上达成尽可能少的代码量。另一方面，区分单纯地Coder与TeamLeader之间的区别在于前者更注重局部最优，这个局部即可能指项目中的前后端中的某个具体模块，也可能指时间维度上的最近一段的开发目标。而TeamLeader则更需要运筹帷幄，统筹全局。不仅仅要完成老板交付的任务，还需要为产品上可能的修改迭代预留接口或者提前为可扩展打好基础，磨刀不误砍材工。总结而言，当我们探究工程化的具体实现方案时，在技术架构上，我们会关注于：

• 功能的模块化与界面的组件化
• 统一的开发规范与代码样式风格，能够在遵循SRP单一职责原则的前提下以最少的代码实现所需要的功能，即保证合理的关注点分离。
• 代码的可测试性
• 方便共享的代码库与依赖管理工具
• 持续集成与部署
• 项目的线上质量保障

前端的工程化需求

当我们落地到前端时，在历年的实践中感受到以下几个突出的问题：

• 前后端业务逻辑衔接：在前后端分离的情况下，前后端是各成体系与团队，那么前后端的沟通也就成了项目开发中的主要矛盾之一。前端在开发的时候往往是根据界面来划分模块，命名变量，而后端是习惯根据抽象的业务逻辑来划分模块，根据数据库定义来命名变量。最简单而是最常见的问题譬如二者可能对于同意义的变量命名不同，并且考虑到业务需求的经常变更，后台接口也会发生频繁变动。此时就需要前端能够建立专门的接口层对上屏蔽这种变化，保证界面层的稳定性。
• 多业务系统的组件复用：当我们面临新的开发需求，或者具有多个业务系统时，我们希望能够尽量复用已有代码，不仅是为了提高开发效率，还是为了能够保证公司内部应用风格的一致性。
• 多平台适配与代码复用：在移动化浪潮面前，我们的应用不仅需要考虑到PC端的支持，还需要考虑微信小程序、微信内H5、WAP、ReactNative、Weex、Cordova等等平台内的支持。这里我们希望能够尽量的复用代码来保证开发速度与重构速度，这里需要强调的是，移动端和PC端本身是不同的设计风格，不建议过多的考虑所谓的响应式开发来复用界面组件，更多的应该是着眼于逻辑代码的复用，虽然这样不可避免的会影响效率。鱼与熊掌，不可兼得，这一点需要因地制宜，也是不能一概而论。

质量保障

前端开发完成并不意味着万事大吉，我们目前所谓的Bug往往有如下三类：

• 开发人员的粗心大意造成的Bug：此类型Bug不可避免，但是可控性高，并且前端目前配置专门的辅助单元测试人员，此类型Bug最多在开发初期大规模出现，随着项目的完善会逐步减少。
• 需求变动造成的Bug：此类型Bug不可避免，可控性一般，不过该类型Bug在正式环境下影响不大，最多影响程序员个人情绪。
• 接口变动造成的Bug：此类型Bug不可避免，理论可控性较高。在上周修复的Bug中，此类型Bug所占比重最大，建议未来后端发布的时候也要根据版本划分Release或者MileStone，同时在正式上线后设置一定的灰度替代期，即至少保持一段时间的双版本兼容性。