最近的两次Bug:
- 做A需求的时候,看到以前的一段代码写的很难看,很不好维护,我忍不了了。所以麻(shou)利(jian)的修改了,然后我就狗带了~
- 做B需求的时候,要修改以前的代码,我在已有的函数上加了一个参数。然后我又狗带了~
发bug就像无孔不入的虫子,你以为你堵住了这个洞,但是它有在另外一个洞生长飞进来,防不胜防!
总结:导致发bug的原因往往不在新的功能和新的需求,而在你修改了以前的代码!!这些牵涉到的修改点,测试并不会去很仔细的测啊!!!!
以下是我们高工严厉指出并给我的建议并加上我的个人总结,与大家分享,定期踩坑更新(我希望再也不要更新了!!!)。
1. 修改前与原作者沟通
如果原作者还在,可以和原作者聊一下,最好他能讲一下代码结构,可以减少很多看代码的时间
2. 仔细阅读修改段落的上下文,并Get以下重点:
- 包括参数命名模式
- 注释风格等代码风格(分号啊,空行啊,空格啊.....)
- 参数定义位置(一般都在顶部)
- 函数定义方式(函数声明方式or 函数表达式方式)
- 代码结构(MVC分块)
get之后就按照已有的风格进行修改,也许你是一个很有风格的码农,你可以改变其他人一起用这个风格~
3. 开始修改了,以下雷请扫:
-
定义一个新的变量(函数): 记得检查变量作用域并全局搜索~ 不要自信的觉得你和别人定义的不一样。
-
修改已有的函数参数: 不要修改参数顺序!!!!这样就算有些调用的地方你没有看到,也会降低很多的bug率。
4. review一遍代码,这里分为自己review和邀请其他人review。
- 自己review:
- 看是否有啥异常没有处理。前端经常犯错就是容错性不够好,毕竟从发起后台请求到你拿到数据,过程是多么艰辛。
- 修改了哪些点,尽可能记下来会影响哪些模块!!
- 他人review: 对于新人来很有用啊~
5. 提交测试
把自己会影响的模块列出来发给测试,这样他才知道重点啊~尤其是在写新需求夹带修改旧代码的时候!! 这个很重要!!! 如果有接入前端错误监控的话,关注一下报错内容。我们项目是有接入Badjs错误监控的。
6. 发布之后,你的产品有论坛或者群吗?
有的话直接加上去,观察用户反馈。往往这些地方是bug反馈最及时的~~~~~
总结完了,忐忑的去吃鸡然后默默等待明天批评。
原文作者:MirroZhou
本文来源: 掘金 如需转载请联系原作者