对前端质量保障的思考

简介:

我们时时在踩坑,有时也忍不住埋怨前人给我们留下了无数的坑,可回头想想,自己是不是也在挖坑等别人踩...

上次听 赵海平 的讲座,他提到 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 效果、交互效果不好测,只能靠几双眼睛盯着看,几个鼠标不停地点点点。。。

虽说逻辑可以通过写测试用例进行测试,会去写测试用例的人却不多。我记得当时学习 AOP 编程的时候,给 ajax 添加了一些 mock 功能,可以在页面上模拟请求测试效果(如jquery-mockjax)。
编写测试用例确实可以解决很多的问题,但是如何培养编写测试用例的习惯,如何更加便利的测试我们的测试用例,这又是一个值得思考的话题。

自动化工具一大缺点是很难捕获到特定环境下的错误。据统计,不管你的代码写得多健壮,在一千个用户下,总有那么一个用户,因为浏览器安装了插件、网络问题等导致代码报错,再比如我们在做灰度测试的时候,让用户名首字母为 a-m 的用户命中灰度时出现的错误等等,这些错误自动化测试工具是无法发现的。

所以我们要把 错误日志统计 灵活地使用起来,他能够使你深入用户,拿到最原始的错误信息。

四、上线

现在涉及到前端上线的,有多个地方(公司有很多发布系统):

  • TMS发布
  • aone2发布
  • gitlab发布
  • awp发布
  • etc.

gitlab发布通过域名严格区分测试、预发和线上环境,操作界限明确,出错的概率还是很低的(这要求开发者对 git 命令的操作十分熟练),如果几次 reset revert stash 之后便开始犯蒙,那出问题的概率就增大了。每次打下 tag 之前,我都会很仔细地 diff 下代码,看看本次发布和上次发布之间做了哪些修改,确认这些修改点再 push tag。

aone2的发布,并不是每个人都用过,它的靠谱在于有三种发布方式:

  • 全网发布,半小时完成
  • 小淘宝环境灰度发布,两小时完成
  • 分三次发布,小流量上线,一天完成

同时也提供了十分方便的回滚机制,只要拥有应用的权限,可以随时回滚代码,效率极高。

TMS 的发布,我觉得是问题最多的。首先,前端和运营都会拥有发布权限,运营喜欢“瞎搞”,部分页面(如JSON输出)并没有提供页面预览,运营填完之后也不会跑到页面查看效果,于是就出问题了。。TMS发布每次修改只发布一个文件,CDN 发布一个文件的速度是很快的,当你点击发布的那个瞬间,整个同步就基本完成了。可是,当某个节点同步出错,TMS 并没有给出提示,这是第二个隐患。第三个点,TMS坑爹的没有灰度,对一些重要的发布,没有灰度就需要十分十分的谨慎,虽说出错可以及时回滚,但万一没有看到隐性的错误,那就悲惨了。

五、回滚

没人可以保证自己写的东西绝对不出问题,因为有太多的环境因素是我们想也想不到的,比如最近某类控件在小淘宝环境下全挂了,试问,前端怎么会想到这是Nginx 的灰度系统出问题了,在灰度发布的时候文件没有同步成功,导致整个灰度环境出错。

所以,一定要给你的程序想一套快速回滚方案。尤其是在做 ABTest 的时候,新版的效果不好需要回滚到之前的状态,这种事情经常有。

回滚需要注意两点:

  1. 要快。
  2. 上一个状态要保证无错误。

只要我们能够保证发到线上的每一个版本都是稳定版,那回滚就是 0 风险的事情。

六、监控

程序开发三板斧的第三板,监控。前端对测试就不太重视,更不用提监控了。没有监控就只能提心吊胆的过日子。

其实我们使用自动化工具测试、每天用肉眼顶着自己的页面看,这些都属于监控,但是深入到用户的监控,我们做的太少!

七、小结

看到老大在群里发了几条研发相关的红线:

1、禁止代码未经测试发布;
2、禁止代码发布后不进行线上验证;
3、禁止核心应用发布没有对应的回滚方案。

毫无疑问,这些都是必须严格遵守的。规范会先把坏习惯压住,进而被理解,最后被消化吸收。

前端质量保障之路,任重而道远!






本文转自Barret Lee博客园博客,原文链接:http://www.cnblogs.com/hustskyking/p/Thinking-in-FE-Quality.html,如需转载请自行联系原作者

目录
相关文章
|
5月前
|
前端开发 JavaScript 测试技术
探索现代前端工程化工具与流程:提升开发效率和项目质量
探索现代前端工程化工具与流程:提升开发效率和项目质量
探索现代前端工程化工具与流程:提升开发效率和项目质量
|
监控 前端开发 JavaScript
前端监控(Frontend Monitoring):保障用户体验的不可或缺工具
前端监控是维护卓越用户体验的关键,它使您能够追踪、分析和解决您的Web应用程序中的性能问题和错误。在本博客中,我们将深入探讨前端监控的重要性、监控的关键指标以及如何实施前端监控来提高您的应用程序的可用性和性能。
325 0
|
2月前
|
前端开发 Java UED
JSF遇上Material Design:一场视觉革命,如何让传统Java Web应用焕发新生?
【8月更文挑战第31天】在当前的Web开发领域,用户体验和界面美观性至关重要。Google推出的Material Design凭借其独特的动画、鲜艳的颜色和简洁的布局广受好评。将其应用于JavaServer Faces(JSF)项目,能显著提升应用的现代感和用户交互体验。本文介绍如何通过PrimeFaces等组件库在JSF应用中实现Material Design风格,包括添加依赖、使用组件及响应式布局等步骤,为用户提供美观且功能丰富的界面。
34 0
|
5月前
|
数据采集 前端开发 JavaScript
前端自动化测试:确保质量和稳定性的关键步骤
前端自动化测试:确保质量和稳定性的关键步骤
前端自动化测试:确保质量和稳定性的关键步骤
|
5月前
|
缓存 资源调度 前端开发
现代前端开发中的工程化:提升效率与质量
现代前端开发中的工程化:提升效率与质量
76 0
|
5月前
|
SQL 前端开发 安全
前端安全策略保障
前端安全策略保障
88 1
|
10月前
|
缓存 资源调度 前端开发
现代前端开发中的工程化:提升效率与质量
现代前端开发中的工程化:提升效率与质量
110 1
|
监控 前端开发 安全
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(1)
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(1)
150 0
|
监控 前端开发 JavaScript
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(2)
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(2)
113 0
|
监控 前端开发 API
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(3)
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践(3)
下一篇
无影云桌面