前端开发—如何快速定位错误

写代码时,通常要耗费大量的时间去排查bug产生的原因,如何快速的定位bug,在很大程度上决定了你的开发效率。下面是我的一些经验分享。

提高编码质量

在一个项目足够简单时,往往不会意识到编码规范和代码质量的重要性。当项目大到需要多人协作或是接收别人的代码时,你就会意识到,编码规范的统一、项目结构的设计、代码的易读性和规范的注释是多么重要。

提高编码质量不仅仅可以帮你快速的定位到bug,更能有效的减少bug数量。糟糕的代码就像堆在一起的杂物,而高质量的代码就像是分门别类的收纳箱,在找东西时 ,哪个效率更高是显而易见的。

当然,提高编码质量不是一蹴而就的,需要有扎实的基础知识,良好的编码规范,以及日积月累的犯错经验。之后可以专门写一篇文章,来介绍如何编写高质量的代码。

阅读报错信息

如果浏览器有输出错误信息,那么根据错误信息,我们就能大致判断出错误类型以及可能出错的原因。

比如:

  • 根据如下报错信息,我们看到,代码在运行时,试图去访问某一对象的attr属性,而该对象并没有被定义。这时候,我们只要在出错的页面去检索关键词attr,输出attr所依赖的对象,就知道错误出在哪儿了
1
Uncaught TypeError: Cannot read property 'attr' of undefined
  • map是数组才有的方法,这里可以预见的是,a并不是一个数组,结果就是 a 没有达到我们预期的格式
1
Uncaught TypeError: a.map is not a function
  • js代码格式错误,通常ESLint会输出报错,检查一下引号、逗号、小括号、大括号是否写完整
1
Uncaught SyntaxError: Invalid or unexpected token
  • 有时候,即便是看懂了报错信息,也不清楚自己的代码到底出了什么问题。你可以把报错信息复制下来,去stackoverflow,segmentfault等专业问答网站去检索一下,如果找到不到合理的答案,还可以去google或百度去搜。要相信,总有人会和你遇到过类似的问题。

善用console

有时候,代码不能以期望的方式运行,但又没有输出任何有效的错误信息,我们可以使用console方法,将必要的信息打印出来。

如何使用?

比如,但我们点击提交按钮时,并没有发起提交请求。这时,我们要查看源码,找出从点击提交按钮一直到发起请求中间,都执行了哪些步骤。并将关键步骤处的关键信息输出,比如if else的判断条件、被遍历的数组和对象,以及可能中断执行的return语句。

注意事项

在使用console输出时,建议带上关键词,且不建议使用无意义的数字、字母等:

1
2
3
4
5
6
7
// good
console.log('attrValue', this.attrValue)
console.log('getModule方法的判断条件', isShow)

// bad
console.log(666, this.attrValue)
console.log(isShow)

另外,在错误排除后,建议删除不再使用的console调试代码,避免在查找其他错误时,造成不必要的干扰。

如果输出的是对象或数组,有可能得到不准确的结果

1
2
3
4
5
let obj = {
key: 1234
}
console.log(obj) // {key: 555}
obj.key = 555

打断点

Chrome的开发者工具有一个很好用的代码调试工具,就是Breakpoints(断点),与console不同的是,它会在断点处终止程序的执行,可以方便的看到代码在哪一步产生了问题。

相比在代码里写debugger打断点的方式,Chrome的调试工具即便捷,又不产生副作用,所以不推荐在代码里写debugger的方式来调试。

更多关于Chrome开发者工具的介绍与使用信息,可移步:chrome开发者工具的使用

排除法

这个方法之前明明是正常的,我并没有改动它,只是在其他地方加了一些代码,它就不正常了。

怎么办?假使页面中一共有abcd四个方法,我们逐次注释掉a, b , c , d,每注释掉一个就运行一次代码,如果在注释掉d以后,代码运行正常了,那么问题就出在d身上。

剥离法

如果页面的代码量很大,用排除法效率可能会很低,这时候我们可以试试剥离法。

同样一个方法(组件),在A页面运行没有问题,放到B页面就不行。这时候,可以建一个新的页面,里面只放这一个组件,然后运行,如果没有异常,首先可以排除,不是这个组件的问题。接下来,把B页面可能对该方法(组件)造成影响的条件,逐次添加进来,看看到底是哪个条件造成了异常。

线上故障排除

有时候线上代码出了故障,而本地又无法重现,由于线上代码不能使用console,并且上线代码都经过了压缩混淆,导致很难调试。

这时候可以试试sourceMap,在webpack的配置文件中开启sourceMap,在打包的时候会生成对应的.map文件。然后将打包过的文件整体上传到服务器,这样调试线上代码时,除了压缩混淆过的代码,还会有一份原始代码,方便打断点和阅读代码。

不过这样做也会有一些缺点,一是打包时间会变长,二是将原生代码暴露出去。所以,平时建议关闭sourceMap功能,只有在修复无法在本地重现的线上bug时再使用。而且,在修复完毕后,重新打一个没有sourceMap的包,上传到服务器,避免本地代码泄露。

关于sourceMap的更多介绍可以移步以下几个链接:

JavaScript Source Map 详解

打破砂锅问到底:详解Webpack中的sourcemap