对前端质量保障的思考.docxVIP

对前端质量保障的思考 我们时时在踩坑，有时也忍不住埋怨前人给我们留下了无数的坑，可回头想想，自己是不是也在挖坑等别人踩... 上次听 赵海平 的讲座，他提到 Facebook 没有测试人员，以前和现在都没有，以后也不打算有。还提到上线之后就开发者坐在系统前等着，只要有bug，系统能够在五分钟之内检测到，并提供快捷方式修复。我惊叹的是他们能够在五分钟之内监控到所有的问题，实时回馈并及时修复。 当然在探讨质量保障这个话题前，我们需要明确几个关键点：编码前、提交代码、测试、上线、回滚、上线后。针对这几个点，下面我谈一谈我的看法。 一、编码前 来阿里之前在百度实习过三个月，实习期间印象最深的交流是参与编码规范讨论，当时我还呼呼的整理了两份文档：前端编码规范之JavaScript,前端编码规范之CSS。后来也看到团队在各种工具上添加控制和提示，如 Sublime Text 添加 jslint 配置，项目目录下添加 .jslint 配置，打包工具提示代码的不规范，强制修复等等。 上面提到的代码规范主要是代码展现层面的规范，他可以让团队写出来的代码就跟一个模子刻出来似的，结构、命名、函数体大小等等很接近，看着很舒服。举几个例子说明他的重要性。 1. 统一使用 UTF8 编码 我平时开发都是使用的 UTF8 编码。有次从仓库拉下来发现很多文件都是 GBK 编码，修改时一个文件忘记转换编码，提交发现 锟斤拷 出来了。 2. TAB 缩进 我比较喜欢使用四个空格作为 TAB 缩进。一次多人开发的时，发现同事的代码是两个空格的缩进，结果，我改成了四个空格提交之后，又被改回来两个空格，然后我接着改回去… 3. 加不加分号 以前写过一篇文章，谈了下自己对分号的看法：Javascript分号，加还是不加？，我的回答是加但非必须。 代码的规范，对程序本身的意义并不是很大，他不会作用在程序的逻辑上，作用点在于团队合作。一个项目可能是多人开发，也可能是今天我开发，明天托付给你。如果两个人在编码习惯上的差异很大，就会偏头痛…有一点需要特别提出来，就是写注释！某次排查一个线上问题，找到了问题所在的文件，但是文件中的逻辑实在是太过复杂，四五百行代码仅三行注释，眼睛都看花了。其实只要在大段的代码前加几句注释，说明本段代码的大意，在排查定位问题的时候就可以忽略一部分代码块，可以为修复线上bug争取不少时间。 二、提交代码 这部分特指工具。可以说过了工具这一道关卡，代码基本就获得自由，bug 也就开始横飞了。目前工具可以为我们做的事情： 1. 检测 现在并没有做 jslint 之类的配置，所以代码的展示是没怎么规范的。编码应该统一为 UTF-8 格式，如果不是这种格式，工具应该有所提示。代码块过长提示，一个函数不应该写到几百上千行，拆分代码刚开始是辛苦，一旦后续复用的时候，就会很爽很爽了（当然，刚开始编码的时候就应该考虑一个函数的颗粒度控制）。 更重要的是对语法的检测，我们可能把 document 拼写成了 doucment，甚至使用 for in 来遍历一个数组，这种问题时而出现，工具是否考虑帮助我们处理掉一些简单的愚蠢的错误。 2. 压缩 压缩代码的时候，我踩过坑：gulp打包压缩css遇到的坑，我相信很多人都认识 grunt 和 gulp，但是一定鲜有人自己配置过这些东西，并投入到项目中。 代码的压缩，一方面可以减少线上流量，一方面也是出于安全的考虑。压缩后的代码线上报错很难定位到准确的位置，有些问题只能在用户的电脑上复现，“代理到本地这个法子”远程操作的时候是不靠谱的。压缩不仅仅应该把代码缩短，还要考虑线上排查问题的难度。 在压缩的时候可以考虑添加空行，将网页错误定位范围缩减到单个文件。也可以使用 sourceMap 之类的辅助方式。在这篇文章中有过一些讨论。 3. 合并 很多事情，别人不考虑，工具就得考虑。 这里有一个思考，HTTP2.0 支持多路复用，一个连接可以进行多次 HTTP 的传输，那以后的 sprite 图、文件的合并等是不是也应该重新考虑了。文件的全部合并真的是最省资源的方式么？是否可以考虑更多的合并方案？ 三、测试 赵海平 说，技术实践中的三件套：功能 + 测试 + 监控。很多大公司的工程师，深谙功能开发之道，测试方面也能达到 60 分的水平，但是程序的监控上，做的很差，包括 Facebook 的程序员。三件套，对一个优秀的工程师来说，缺一不可。 这里要说的是程序开发三板斧的第二板，测试。 我们很自然地联想到了QA，阿里有一大波的测试人员。写完代码提测，好像剩下的就只是测试同学找BUG，我们等着修BUG。前端的测试跟后端还不太一样，逻辑可以测，但是 UI 效果、交互效果不好测，只能靠几双眼睛盯着看，几个鼠标不停地点点点。。。 虽说逻辑可以通过