前端，一种GUI软件

喂喂喂，那个切图的，把页面写好就发给研发工程师套模板吧。

你好，切图仔。

不知道你的团队如何定义前端开发，据我所知，时至今日仍然有很多团队会把前端开发归类为产品或者设计岗位，

虽然身份之争多少有些无谓，但我对这种偏见还是心存芥蒂，酝酿了许久，决定写一个系列的文章，试着从工程的角度系统的介绍一下我对前端，尤其是Web前端的理解。

只要我们还把自己的工作看作为一项软件开发活动，那么我相信读过下面的内容你也一定会有所共鸣。

一、前端，是一种GUI软件

现如今前端可谓包罗万象，产品形态五花八门，涉猎极广，什么高大上的基础库/框架，拽炫酷的宣传页面，还有屌炸天的小游戏……

不过这些一两个文件的小项目并非是前端技术的主要应用场景，更具商业价值的则是复杂的Web应用，

它们功能完善，界面繁多，为用户提供了完整的产品体验，可能是新闻聚合 站，可能是在线购物平台，可能是 交 络，可能是金融信贷应用，可能是音乐互动 区，也可能是视频上传与分享平台……

从本质上讲，所有Web应用都是一种运行在 页浏览器中的软件，这些软件的图形用户界面（Graphical User Interface，简称GUI）即为前端。

如此复杂的Web应用，动辄几十上百人共同开发维护，其前端界面通常也颇具规模，工程量不亚于一般的传统GUI软件：

前端工程建设的第一项任务就是根据项目特征进行技术选型。

基本上现在没有人完全从0开始做 站，哪怕是政府项目用个jquery都很正常吧，React/Angularjs等框架横空出世，解放了不少生产力，合理的技术选型可以为项目节省许多工程量这点毋庸置疑。

第二阶段：简单构建优化

分而治之是软件工程中的重要思想，是复杂系统开发和维护的基石，这点放在前端开发中同样适用。

解决了基本开发效率运行效率问题之后，前端团队开始思考维护效率，模块化是目前前端最流行的分治手段。

很多人觉得模块化开发的工程意义是复用，我不太认可这种看法，

在我看来，模块化开发的最大价值应该是分治，是分治，分治！（重说三）。

不管你将来是否要复用某段代码，你都有充分的理由将其分治为一个模块。

JS模块化方案很多，

AMD/CommonJS/UMD/ES6 Module等，对应的框架和工具也一大堆，说起来很烦，大家自行百度吧。

CSS模块化开发基本都是在less、sass、stylus等预处理器的import/mixin特性支持下实现的。虽然这些技术由来已久，在如今这个“言必及React”的时代略显落伍，但想想业界的绝大多数团队的工程化落后程度，

放眼望去，毫不夸张的说，能达到第三阶段的前端团队已属于高端行列，基本具备了开发维护一般规模Web应用的能力。

然而，做到这些就够了么aive！

第四阶段

前端是一种技术问题较少、工程问题较多的软件开发领域。

当我们要开发一款完整的Web应用时，前端将面临更多的工程问题，比如：

大体量：多功能、多页面、多状态、多系统；

大规模：多人甚至多团队合作开发；

高性能：CDN部署、缓存控制、文件指纹、缓存复用、请求合并、按需加载、同步/异步加载、移动端首屏CSS内嵌、HTTP 2.0服务端资源推送。

这些无疑是一系列严肃的系统工程问题。前面讲的三个阶段虽然相比曾经“茹毛饮血”的时代进步不少，但用于支撑第四阶段的多人合作开发以及精细的性能优化似乎还欠缺点什么。

到底，缺什么呢/p>

三、没有银弹

读过《人月神话》的人应该都听说过，软件工程 没有银弹。

没错，前端开发同样没有银弹，可是现在是连弹都没有的年月！（刚有了BB弹，摔）

前端历来以“简单”著称，在前端开发者群体中，小而美的价值观占据着主要的话语权，甚至成为了某种信仰，想与其他人交流一下工程方面的心得，得到的回应往往都是两个字：太重。

重你妹！你的脑容量只有4K吗/p>

工程方案其实也可以小而美！只不过它的小而美不是指代码量，而是指“规则”。

找到问题的根源，用最少最简单明了的规则制定出最容易遵守最容易理解的开发规范或工具，以提升开发效率和工程质量，这同样是小而美的典范！

2011年我有幸参与到 FIS 项目中，与百度众多大中型项目的前端研发团队共同合作，不断探索实践前端开发的工程化解决方案，13年离开百度去往UC，

面对完全不同的产品形态，不同的业务场景，不同的适配终端，甚至不同的 络环境，过往的方法论仍然能够快速落地，为多个团队的不同业务场景量身定制出合理的前端解决方案。

这些经历让我明悟了一个道理：

进入第四阶段，我们只需做好两件事就能大幅提升前端开发效率，并且兼顾运行性能，那就是——组件化开发与资源管理。

第一件事：组件化开发

分治的确是非常重要的工程优化手段。在我看来，前端作为一种GUI软件，光有JS/CSS的模块化还不够，对于UI组件的分治也有着同样迫切的需求：

不同的技术选型决定了不同的组件封装和调用策略。

基于这样的工程理念，我们很容易将系统以独立的组件为单元进行分工划分：

以上5种开发概念以相对较少的规则组成了前端开发的基本工程结构，基于这些理念，我眼中的前端开发就成了这个样子：

综合上面的描述，对于一般中小规模的项目，大致可以规划出这样的源码目录结构：

上图展示了一款界面繁多功能丰富的应用，如果采用Web实现，相信也是不小的体量，

如果用户第一次访问页面就强制其加载全站静态资源再展示，相信会有很多用户因为失去耐心而流失。

根据“增量”的原则，我们应该精心规划每个页面的资源加载策略，

使得用户无论访问哪个页面都能按需加载页面所需资源，没访问过的无需加载，访问过的可以缓存复用，最终带来流畅的应用体验。

这正是Web应用“免安装”的魅力所在。

由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心，有加载相关的按需加载、延迟加载、预加载、请求合并等策略；

有缓存相关的浏览器缓存利用，缓存更新、缓存共享、非覆盖式发布等方案；

还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。

这些优化方案无不围绕着如何将增量原则做到极致而展开。

所以我觉得：

第四阶段前端开发最迫切需要做好的就是在基础架构中贯彻增量原则。

相信这种贯彻不会随着时间的推移而改变，

在可预见的未来，无论在HTTP1.x还是HTTP2.0时代，无论在ES5亦或者ES6/7时代，无论是AMD/CommonJS/UMD亦或者ES6 module时代，无论端内技术如何变迁，我们都有足够充分的理由要做好前端程序资源的增量加载。

正如前面说到的，第三阶段前端工程缺少点什么呢/p>

我觉得是在其基础架构中缺少这样一种“智能”的资源加载方案。

没有这样的方案，很难将前端应用的规模发展到第四阶段，很难实现落地前面介绍的那种组件化开发方案，也很难让多方合作高效率的完成一项大型应用的开发，并保证其最终运行性能良好。

在第四阶段，我们需要强大的工程化手段来管理”玩具般简单“的前端开发。

在我的印象中，Facebook是这方面探索的伟大先驱之一，早在2010年的Velocity China大会上，来自Facebook的David Wei博士就为业界展示了他们令人惊艳的静态 页资源管理和优化技术。

David Wei博士在当年的交流会上提到过一些关于Facebook的一些产品数据：

Facebook整站有10000+个静态资源；

每个静态资源都有可能被翻译成超过100种语言版本；

每种资源又会针对浏览器生成3种不同的版本；

要针对不同带宽的用户做5种不同的打包方法；

有3、4个不同的用户组，用于小批次体验新的产品功能；

还要考虑不同的送达方法，可以直接送达，或者通过iframe的方式提升资源并行加载的速度；

静态资源的压缩和非压缩状态可切换，用于调试和定位线上问题。

这是一个状态爆炸的问题，将所有状态乘起来，整个 站的资源组合方式会达到几百万种之多（去重之后统计大概有300万种组合方式）。

支撑这么大规模前端项目运行的底层架构正是魏博士在那次演讲中分享的Static Resource Management System(静态资源管理系统)，用以解决Facebook项目中有关前端工程的3D问题（Development，Deployment，Debugging）。

调用这些接口时，框架通过查表来查找资源的各项信息，并递归查找其依赖的资源的信息，

然后我们可以在这个过程中实现各种性能优化算法来“智能”加载资源。

根据业务场景的不同，加载框架可以在浏览器中用JS实现，也可以是后端模板引擎中用服务端语言实现，甚至二者的组合，不一而足。

恩，如你所见，虽然彻底告别了一个团队一套工具的时代，但似乎又进入了一个团队一套框架的时代。

其实还是有差别的，因为框架具有很大的灵活性，而且不那么黑盒，采用框架实现资源管理相比构建更容易调试、定位和升级变更。

深耕静态资源加载框架可以带来许多收益，而且有足够的灵活性和健壮性面向未来的技术变革，这个我们留作后话。

四、总 结

回顾一下前面提到过的前端工程三个阶段：

第一阶段：库/框架选型

第二阶段：简单构建优化

第三阶段：JS/CSS模块化开发

现在补充上第四阶段：

第四阶段：组件化开发与资源管理

由于先天缺陷，前端相比其他软件开发，在基础架构上更加迫切的需要组件化开发和资源管理，而解决资源管理的方法其实一点也不复杂：

一个通用的资源表生成工具 + 基于表的资源加载框架

近几年来各种你听到过的各种资源加载优化策略大部分都可以在这样一套基础上实现，

而这种优化对于业务来说是完全透明的，不需要重构的性能优化——这不正是我们一直所期盼的吗/p>

正如魏小亮博士所说：我们可以把优秀的人集中起来去优化加载。

如何选型技术、如何定制规范、如何分治系统、如何优化性能、如何加载资源，当你从切图开始转变为思考这些问题的时候，我想说：

你好，工程师！

摘至开课吧前端团队，阅读后颇有收获分享至此，希望对大家有所帮助~

文章知识点与官方知识档案匹配，可进一步学习相关知识Vue入门技能树首页概览23280 人正在系统学习中