【云途干货】大话前端自动化构建之 壹看板也曾“年幼”

行云流水2016

【云途君有话说】每一个成功男人的背后都有一个（也许几个）默默支持（啰嗦鸡婆）的女人；每一款极致体验的产品背后，都有一个（或者一群）孜孜专业（闷骚疯狂）的技术男。继之前“云途壹看板”算法工程师撰写了《推荐系统---使用logistic的原因和不足》之后，又一位前端工程师步入了“IT伪宅男”的行列，以一篇结合专业、深入浅出的文章告诉我们：技术宅男的小情怀一旦帅炸，必同老房子着火一样不可救药！

请点击此处输入图片描述

以下，正文开始……

如果把云途壹看板比作正在蓬勃发育的活力生命体，那么它必将经历曾经、现在、以及未来的成长轨迹，也总会经历从粗糙到成熟的蜕变过程。

本文以前端开发中样式文件加载的一点问题，和大家聊一聊云途壹看板在自动化过程中的那些事。

（图片来自网络）

先解释下名词，啥叫自动化构建？维基百科里是这样说的：

自动化构建（英语：Build automation），又称构建自动化、组建自动化，将软件设计师的每日工作，以自动化技术或脚本语言方式，自动完成的工具与技术。其中主要包括了：以编译器将源代码编译成二进制码（Binary code）、将二进制码打包成软件包、运行单元测试、部署软件（Software deployment）、产生文件与Release notes。

简单来说，就是让计算机自己工作，并输出最终满足业务需求的东东！我们今天要聊的就是其中关于软件部署相关的一小块内容。

圣经里里面有位耶稣大爷曾经说过，“ 你们或以为树好，果子也好。树坏，果子也坏。因为看果子，就可以知道树” 【太12:33】。

（图片来自网络）

啥意思呢？ 就是看结果说话。拿云途壹看板产品介绍页面为例：

小时候它长这样：

经过构建，现在长成这样：

哪里长得不一样呢？图片有点袖珍，且容我细细道来。

为了方便进行比较，本例中仅罗列了CSS文件请求列表，两个版本之间仅有样式部分有所差异，并且浏览器都是第一次从硬盘直接读取CSS样式文件（避免缓存带来的差异）。

首先是文件请求数的差异

从图中可以看到，前后两者之间在文件请求数上，相差了整整6个CSS文件请求。

前端攻城狮们都知道，网站请求数过多将会对网站的性能产生影响。虽然这一点并不是绝对的，但对于CSS文件的加载这一点还是比较重要的。（比如对于JS的优化方案，由于云途壹看板属于应用型网站，所以更多的是考虑应用的可用性，从而牺牲了请求带来的性能消耗）

其次是页面总加载时间的变化（加载大小的差异）

构建前与构建后，在总文件大小上分别是 187.7KB和164KB，而最终的页面加载时间差异更大，分别是 12.69s和2.42s。

为什么仅通过对样式文件的一个简单优化，两者之间就会产生这样大的差异呢？

首先自动化构建工具中引入了CSS压缩功能，把所有样式文件整理至一个文件当中（不考虑新的样式文件中引入的新代码，否则压缩率将更高），其次是多个文件请求转化成单个请求带来的性能提高也是一个重要点。不要小看这一点点的优化，对于大型网站来说可以节省的带宽可不是一点点能够描述的。

一点看不到的差异

在传统的前端开发中，如果对样式文件（JS文件）经过压缩后，对于我们调试和修改代码将带来一定的困难。

针对这一点，云途壹看板在构建代码时我们加入SourceMap的支持，对于目前主流浏览器（如Chrome)，通过SourceMap可以快速定位我们开发代码的具体位置。这样，我们可以通过使用“重命名”插件，方便地维护压缩和未压缩的两套代码，并且快速部署到项目的相关目录中。

也许，大家会说：“纳尼？这么简单的事，地球人全知道！！！“

（图片来自网络）

诚然，这点“小料”对于大部分的攻城狮来说并不新鲜，But，这并不影响我们通过这个例子，了解到自动化构建能够做的一些事情：

• LESS编绎
• 文件合并/压缩
• SourceMap的应用
  
  

除此之外，仅针对前端开发，自动化构建工具还可以做很多事情。比如：

• 版本控制
• JS检查、压缩及编绎ES6代码
• 文件重命名
• 图片URL转化
• 单元测试等等
  
  

那么，为什么要引入自动化构建流程（工具）？

回答这个问题， 那就要聊聊以前前端的开发方式，姑且叫它“老式开发方式”。

在老式开发方式中，我们一般直接使用CSS语法对样式进行管理。随着各种插件和开发库的引入，样式文件也会随之增多，各插件样式代码之间的加载顺序有可能会间接影响最终的浏览器输出结果。为此，常规的做法是把第三方的样式文件放在项目样式文件之前，并且在项目文件中针对第三方的样式进行重新定义等等。

这样的开发方式，在对站点进行整体的规划时将非常麻烦。例如项目中为了应用公司的UI规范，统一全站的字体时，不得不在很多的位置编写相同的代码。随着项目的推进，它的维护成本将越来越高。

针对这种问题，可以尝试通过引入SASS或者LESS工具，像写脚本语言一样对样式进行变量、函数的定义，以及合理规划多个样式文件之间的结构以方便导入。届时，就不可避免的引入相应的编译工具，而为了简化重复的劳动，使用自动化构建工具配置它们将是不错的选择。

同样，针对JS文件、图片文件、代码版本管理等也会有相应的工具和自动化的方式，自动化构建流程的引入将大大减少我们的劳动量和提升开发的效率。

然后，自动化构建工具都有哪些？该怎么选择？

当前，市面上有许多类型的自动化构建工具。其中比较知名的有：Gulp、Grunt、NPM + Webpack。

这三款产品都是基于Node.js的，都有不同的优缺点。我们今天不谈论各款工具之间的区别，仅罗列一些需要考虑的点，来辅助大家的选择合适的工具。

在开发云途壹看板这个项目（产品）时，我们主要考虑这样几个问题：

• 构建工具的成熟程度以及社区的支持程度（是否有足够的文章拿来啃）；
• 脚本是否容易维护，方便地编写相应的业务逻辑（是否容易理解和学习）；
• 是否有丰富的插件来满足想要达到的目的（少写点代码，以使用为主，研究为辅）
  
  

通过以上的几点考虑，云途壹看板最终选择了gulp作为构建工具，解决了JS的模块化构建、CSS样式文件的管理以及资源文件的管理和项目部署，随着项目的推进也在不断优化构建流程。

除此以外，可能还需要考虑一些其它的问题。比如针对重要依赖插件的更新情况；构建性能的要求等等。

每一个团队、开发的项目都不太一样，针对具体情况选择最优的方案将是最好的选择。

最后，自动化构建是万能的吗？

（图片来自网络）

也许，真正的逼格永远是用最合理选择，产生了最佳的效果…… 就像世间永远没有绝对一样，万能这样的事情谁敢随便说？它已经不属于地球的范畴。

自动化构建流程的目的是为了把重复工作一次性配置，多次重复执行，从而带来的开发效率的提升，也将避免一些人为误操作带来的风险。这样就可以让开发人员从琐细的工作中解放出来，专注于项目功能、业务逻辑的实现。若“为了逼格而逼格”，未免有些得不偿失。

当然，云途壹看板的开发同样也经历了从屌丝到高逼格的转变，正是因为这样对细节的不断追求，所以相信它的每一点小小的打磨和进步，都将带给大家越来越好的体验。

更多大数据技术干货，请点击“云途壹看板”