我们总是在踩坑，有时候忍不住抱怨前辈给我们留下了无数的坑，但是回头想想，我们是不是在挖坑等着别人来踩on...上次听赵海平讲课，他提到Facebook没有测试人员，以前没有，现在也没有，未来也不打算有。还提到，上线后，开发者坐在系统前等待。只要有bug，系统就能在五分钟内检测到，并提供修复的捷径。令我惊叹的是，他们能在五分钟内监控到所有问题，实时反馈并及时修复。当然，在讨论质量保证这个话题之前，我们需要明确几个关键点：编码前、提交代码、测试、上线、回滚、上线后。针对这几点，下面我谈谈我的看法。1.Coding来阿里之前在百度实习了三个月。实习期间印象最深的一次交流是参与编码标准的讨论。当时还整理了两个文档：JavaScript前端编码标准，CSS前端编码标准。.后来也看到团队给各种工具添加了控件和提示，比如给SublimeText添加jslint配置，给项目目录添加.jslint配置，非标准代码打包工具提示，强制修复等等。上面所说的代码规范，主要是代码显示层次的规范。它可以让团队编写的代码看起来像一个模具。结构、命名、函数体大小等都非常接近，看起来很舒服。举几个例子来说明它的重要性。1.统一使用UTF8编码我平时开发都是使用UTF8编码。有一次从仓库里拉下来，发现很多文件都是GBK编码的。修改文件的时候忘记转换编码了，提交的时候发现复制出来了。2.TAB缩进我比较喜欢用四个空格作为TAB缩进。多人开发时，发现同事的代码缩进了两个空格。结果我改成四个空格提交了，结果又改回两个空格，然后我又改回来了...3.加不加分号之前写过一篇文章，说说我对分号的看法:Javascript分号，加还是不加？，我的回答是加分但没必要。代码的规范对程序本身意义不大。不会影响程序的逻辑，但作用在于团队合作。一个项目可能由多人开发，也可能今天由我开发，明天交给你。如果两个人的编码习惯截然不同，你就会偏头痛……需要特别提到的一件事是写注释！有一次在网上查了一个问题，找到了问题所在的文件，但是文件里面的逻辑太复杂了。四五百行代码只有三行注释，看得我眼花缭乱。其实只要在一大段代码前加几条注释说明这一段代码的大致思路，在排查和定位问题的时候就可以忽略一些代码块，就可以争取到很多时间用于在线错误修复。2.提交代码这部分是指工具。可以说，工具级别之后，代码基本是免费的，bug开始横飞。该工具目前能为我们做什么：1.检测目前没有jslint等配置，所以代码的展示不是很规范。编码应该统一为UTF-8格式，如果不是，工具应该给出提示。代码块太长提醒大家，一个函数不应该写成几百行或几千行。拆分代码一开始很难，但是一旦后面复用，就非常爽了（当然，刚开始编码的时候应该考虑对一个函数进行粒度控制）。更重要的是语法检测。我们可以将document拼写为doucment，甚至可以使用forin来遍历数组。这种问题时有发生。该工具是否考虑帮助我们处理一些简单的愚蠢错误。2、压缩压缩代码时踩坑：gulp打包压缩css遇到的坑，相信很多人都知道grunt和gulp，但是肯定很少有人自己配置好这些东西，放到项目中。代码压缩一方面可以减少在线流量，另一方面也是出于安全考虑。压缩代码在线错误的确切位置很难定位，有些问题只能在用户电脑上重现。“本地方法的代理”对于远程操作来说是不可靠的。压缩不仅要缩短代码，还要考虑在线排错的难度。压缩的时候可以考虑加入空行，将网页错误定位的范围缩小到单个文件。也可以使用像sourceMap这样的辅助方法。这篇文章中有一些讨论。3.合并很多东西。别人不考虑，工具就得考虑。这里提一个思路，HTTP2.0支持多路复用，一个连接可以进行多次HTTP传输。之后，我们是否也应该重新考虑精灵图和文件合并。合并所有文件真的是最节省资源的方式吗？是否可以考虑更多的合并选项？3、测试赵海平说，技术实践中的三件套：功能+测试+监控。很多大公司的工程师深谙功能开发之道，测试能达到60分的水平，但在程序监控方面做得很差，包括Facebook的程序员。三件套对于一个优秀的工程师来说是必不可少的。这里要说的是程序开发、测试三板中的第二板。我们很自然地想到QA，阿里有大量的测试人员。写完代码测试好了，好像就剩下测试同学找BUG了，就等着修BUG了。前端测试和后端不一样。逻辑可以测试，但是UI效果和交互效果不好测试。你只能靠几双眼睛盯着它，几只鼠标不停地点击。..虽然可以通过写测试用例来测试逻辑，但是会写测试用例的人并不多。记得在学习AOP编程的时候，在ajax中加入了一些mock函数，可以在页面上模拟请求测试效果（比如jquery-mockjax）。写测试用例确实可以解决很多问题，但是如何培养写测试用例的习惯，如何更方便的测试我们的测试用例，又是一个值得思考的话题。自动化工具的缺点之一是很难在特定环境中捕获错误。据统计，不管你的代码有多健壮，1000个用户，总会有一个用户因为浏览器安装插件、网络问题等导致代码报错。比如我们在做灰度的时候testing,用户名以a-m开头的用户打灰度时出现的错误等。这些错误是自动化测试工具无法发现的。因此，我们需要灵活运用错误日志统计，才能让你深入用户，获得最原始的错误信息。4、现在上线涉及前端上线，有很多地方（公司有很多发布系统）：TMS发布aone2，发布gitlab，发布awp，发布等。gitlab发布严格区分测试，预发布和线上环境通过域名，操作边界清晰，出错的概率还是很低的（这需要开发者对git命令的操作非常熟练），如果在几次resetrevertstash后开始出错，概率问题会增加。每次打tag之前，我都会非常仔细的diff一下代码，看看这次发布和上次发布有什么变化，确认这些变化之后再pushtag。aone2的release并不是人人都用的。靠谱，因为有三种发布方式：全网发布，半小时完成小淘宝环境灰度发布，两小时完成三发布，小流量在线，一天同时完成还提供一个非常方便的回滚机制。只要有应用的权限，随时可以回滚代码，效率极高。我认为TMS的发布是最有问题的。首先，前端和运营都有发布权限，运营喜欢“忽悠”。有的页面（比如JSON输出）没有提供页面预览，填完后操作不会去页面查看效果，所以有问题。.TMS每次修改只发布一个文件，CDN发布一个文件非常快。点击发布的那一刻，整个同步就基本完成了。但是当一个节点同步失败时，TMS并没有给出提示，这是第二个隐患。第三点，TMS没有灰阶。对于一些重要的发布，如果你没有灰度，你需要非常谨慎。虽然说错了可以及时回滚，但是如果看不到隐藏的错误就惨了。.5.回滚谁也不能保证自己写的东西不会出问题，因为有太多我们想不到的环境因素。以为这是Nginx灰度系统的问题，在发布灰度的时候文件没有同步成功，导致整个灰度环境出错。因此，一定要为你的程序想一个快速回滚的解决方案。特别是做ABTest的时候，新版本的效果不好，需要回滚到之前的状态。这种事情经常发生。回滚需要注意两点：要快。必须保证之前的状态没有错误。只要能保证每一个上线发布的版本都是稳定版，那么回滚就是零风险的事情。六、监控程序开发三轴第三板，监控。前端不太重视测试，更不用说监控了。没有监控，只能活在恐惧中。事实上，我们每天都使用自动化工具来测试和用肉眼查看我们的页面。这些都是监控，但是我们做的太少，没法深入用户监控！7.总结看到老大在群里贴了几条研发相关的红线：禁止未经测试就发布代码；禁止未经在线验证的代码发布；禁止在没有相应回滚计划的情况下发布核心应用。毫无疑问，这些必须严格遵守。规范首先会抑制坏习惯，然后被理解，最后被消化吸收。前端质量保证之路任重而道远！
