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

  • 彭超

2013 年 9 月 9 日

话题:JavaScriptDevOps语言 & 开发架构文化 & 方法

在第三十九期前端开发主题的百度技术沙龙现场,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:我们的采访今天就到这,感谢你的前端工具,多谢致富同学。

JavaScriptDevOps语言 & 开发架构文化 & 方法