前端开发工具和代码质量管理：人人网前端技术架构师王致富访谈

在第三十九期前端开发主题的百度技术沙龙现场，InfoQ 编辑有幸采访到了人人网前端技术架构师王致富，谈到了人人网在前端开发工具和代码质量管理，以及处理历史遗留框架上的经验。

以下是采访内容。

InfoQ：请您首先做个自我介绍吧。

王致富：我叫王致富，来自人人网的前端技术部，现在主要负责人人网的前端基础架构。研究生从中国科学院软件研究所毕业，毕业之后，就直接去了人人网，后面就一直在那边做前端基础架构的事情。

InfoQ：能不能介绍一下你现在的工作内容？

王致富：我现在主要负责两块，一块是前端基础库的维护；另外一块是前端开发平台的维护。这两部分主要为了两个目标，一个是前端开发效率的提升；另外是前端代码质量的把控。

InfoQ：那其实是做开发工具和做代码的质量管理。做这个的出发点是什么？

王致富：做基础服务，主要的出发点肯定是所有开发人员的共同诉求。我在做每一件事情的时候，都先会对目前工具的状况做一个大概的了解，把前端同学在日常开发交流过程中遇到的问题做归纳总结。如果某个问题确实是大家的普遍诉求，我就会结合目前的状况，和自己所了解的技术，把这个问题解决。

InfoQ：能否举个典型的例子，说明这个工具，解决了什么样的问题？

王致富：我觉得在开发效率方面，实际上有这样的瓶颈：前端同学对于我们现有的前端基础库使用，入门比较难。因为人人网从成立到现在总共有六七年的时间，在这么长时间里，不少的人参与过基础架构的一些事情，每个人在参与架构工作时，处在不同的时代和技术背景下，开发出来的框架差异非常大。比如最开始散养式编码，接下来通过命名空间方式来组织代码，到后来通过模块化的方式来组织代码，很多做法在当时无可厚非，但是最后到了今天，API 五花八门，使用起来就有问题了。加上这些 API 和业内大家所熟悉的框架（jQuery 等）又有一定的出入，文档又不够齐全，给我们的开发人员造成了很高的学习成本。

在这种情况之下，我们就希望有一种方案，能够让我们的框架跟业内的一些先进框架做衔接，当然，这个衔接不能给我们的系统造成太多的额外负担。在这种目标之下，我们采用了一种“四两拨千斤”的方式，把我们原来的一些散养式、命名空间式、或者其他方式组织起来的代码，通过一千多行代码的 API 转化，转化成 jQuery 的 API。这样做以后，开发人员在写代码时，完全用 jQuery 的方式来写。当他们遇到问题的时候，可以上 jQuery 官方的文档上去查，这样的话我也省去不少写文档的时间。如果他们发现了我们的框架 API 跟 jQuery 有出入，就可以快速的沟通和反映，我会马上把这个问题修复，修复完了之后，通过单元测试，就直接提交，开发人员更新以后就可以直接使用新版代码。整个快速开发、快速迭代，以及他们快速学习、快速使用的过程，对于我们提升开发效率是有很大帮助的。

InfoQ：从开发工具角度来讲，这也是很多互联网公司开发框架上所走的弯路，非常有借鉴意义。那么在代码的质量控制上，你有什么愿意分享的地方吗？

王致富：代码的质量控制，首先，我们人人前端部门制订了非常多的编码规范，包括 JavaScript 编码规范和 CSS 编码规范等。JavaScript 编码规范我们制定的比较全，业内也有非常多的 JavaScript 检查工具，能够做 JavaScript 代码规范的检查，我们也用了一些业内的先进的工具，如 JSLint。但是当我们制订了比较全的 CSS 代码规范，并试图在业内去搜集 CSS 编码规范相关的检查工具的时候，就发现了非常多的问题——目前的 CSS 检查工具并不能够很好的完成我们 CSS 编码规范里面的规则检查。目前业内比较火的 CSS 编码规范检查工具叫 CSSLint，这个工具是用 Nodejs 写的，它检查了非常多的 CSS 代码问题，但是它本身也存在缺陷，比如：我们的 CSS 编码规范分两种，一种是代码风格规范；另外一种是代码取值规范，而在代码风格规范方面，CSSLint 完全没有体现。而它提供的 CSS 取值规范，本身也不够完善，而且跟我们制定的 CSS 编码规范也有出入。最初我们想基于 CSSLint，为 CSSLint 开发插件来完成我们的 CSS 规范检查，但是它提供的插件编写方式，决定了插件开发起来有一定难度。在 CSSLint 里，插件编写完全是基于事件来做的，插件必须做大量的 JS 事件监听，在不同的事件处理函数里面去做检查处理，非常不直观，代码非常绕。所以最终，我们自己做了一个 CSS 编码规范的检查工具。这个检查工具首先做 CSS 解析，把 CSS 解析成我们需要的树型结构，然后再针对语法树，直观的编写插件，每一个插件，针对一项具体代码书写规则做检查。检查完了以后，把结果进行汇总就行了。这个工具叫 CSSCheckStyle。

InfoQ：真是个直观的好名字。能讲讲这个工具的具体实现吗？

王致富：其实当时起名是借鉴了 Java 的代码风格检查工具 CheckStyle。

这个工具最初做的时候，主要目标是用来做 CSS 代码规范的检查。但是我发现如果能够做某种代码问题的检查，在大多数情况下，我就已经知道这个问题应该怎么修复。所以工具实现了对代码做一定的修复和优化的功能。

这个工具的代码组织方式，像一个流水线加工车间，里面会坐着非常多的工人，每个工人都是我雇佣的“插件”，每个插件在整个生产过程当中，扮演着自己的角色。当代码从车间进来的时候，首先在入口做 CSS 解析，解析完了之后再扔到车间的生产线上。每个工人都对这代码做检查，或者是修复。当代码经过了车间的所有工人，从这个车间出去的时候，就是符合规范的完整代码了。这是整个处理流程，会涉及到插件式的代码组织方式。目前这个方式的的效果就是：当我编写或修改了插件，放到固定的地方，插件就能立即生效，实现了很好的“热插拔”效果。设计这种开发方式，也是为了长久考虑。因为这个工具做的是一种开发语言的解析、检查、修复，整个任务不是一次就能够完成的，需要准备持久战，而插件的热插拔方式，很好的支持了增量迭代开发，所以当时就采用了插件式的开发方式。

当做到修复和优化，又有个问题摆在眼前，那就是压缩。目前，在不同浏览器下，我们的网站加载的是相同的 CSS 文件，而这一个 CSS 里面包含了各种各样的浏览器兼容性不一的代码。例如背景色、圆角、框阴影等等。而实际上，对于不同的浏览器，有的代码是根本就没有必要加载的。比如说在 bootstrap 的 100 多 K 的 CSS 文件里，大概只有 30K 被 IE6 支持，其他 70 多 K 都是不支持的，所以可以专门针对 IE6 做 CSS 的压缩和优化，生成一个 30K 的只给 IE6 用的文件，其他浏览器同理。这也是我这个工具下一步的工作计划。最终我想完成的效果是：这个工具能区分浏览器，压缩出不同的 CSS，然后不同的浏览器访问同一个网站，加载不同的 CSS 文件，这种优化可以减少加载内容，加快页面加载速度，同时产生了一个好的副作用，那就是用户流量的节省。PC 用户可能并不是特别关心，因为他们不关心流量，但是对于手机用户，它的节省流量的效果就非常明显了，毕竟，流量也是钱哪。

InfoQ：那你们有统计过这个工具和这个压缩工具在使用之后，性能有多少提升？

王致富：：我这个工具有个官网，地址是 http://www.csscheckstyle.com/，这个网站上面所有的代码都是经过了这一系列优化处理的。对于性能数据，现在还没有具体数据出来，但是从代码字节数、代码本身性能等方面，我觉得，经过这一系列优化处理，即便在没有量化数据的情况下，基于共识，也能够确定：它确实能给网站带来一定的性能提升。

InfoQ：这个工具已经开源发布了是吗？

王致富：：对，这个工具目前在 GitHub 开源了，地址是 https://github.com/wangjeaf/CSSCheckStyle。目前已经有很多开发者关注了这个工具，也有很多人已经把这个工具拉进自己的空间开始做改进了。但是这个工具是用 Python 写的，对于前端的同学来说，可能有一定的入门门槛，所以我收到的 pull request 挺少的。下一步我会把这个工具做成 Nodejs 的，大家就会更容易接受了。

InfoQ：我们的采访今天就到这，感谢你的前端工具，多谢致富同学。