阅读 882

修改他人代码:怎么才能减少发布Bug概率?

一个周天的下午,如坐针毡。为什么?因为明天周一了.... 要上班了,可能发bug要挨批评了。博客在git上维护:欢迎stargithub.com/MirroZhou/B…

最近的两次Bug:

  1. 做A需求的时候,看到以前的一段代码写的很难看,很不好维护,我忍不了了。所以麻(shou)利(jian)的修改了,然后我就狗带了~
  2. 做B需求的时候,要修改以前的代码,我在已有的函数上加了一个参数。然后我又狗带了~

发bug就像无孔不入的虫子,你以为你堵住了这个洞,但是它有在另外一个洞生长飞进来,防不胜防!

总结:导致发bug的原因往往不在新的功能和新的需求,而在你修改了以前的代码!!这些牵涉到的修改点,测试并不会去很仔细的测啊!!!!

以下是我们高工严厉指出并给我的建议并加上我的个人总结,与大家分享,定期踩坑更新(我希望再也不要更新了!!!)。

1. 修改前与原作者沟通

如果原作者还在,可以和原作者聊一下,最好他能讲一下代码结构,可以减少很多看代码的时间

2. 仔细阅读修改段落的上下文,并Get以下重点:
  • 包括参数命名模式
  • 注释风格等代码风格(分号啊,空行啊,空格啊.....)
  • 参数定义位置(一般都在顶部)
  • 函数定义方式(函数声明方式or 函数表达式方式)
  • 代码结构(MVC分块)

get之后就按照已有的风格进行修改,也许你是一个很有风格的码农,你可以改变其他人一起用这个风格~

3. 开始修改了,以下雷请扫:
  • 定义一个新的变量(函数): 记得检查变量作用域并全局搜索~ 不要自信的觉得你和别人定义的不一样。

  • 修改已有的函数参数: 不要修改参数顺序!!!!这样就算有些调用的地方你没有看到,也会降低很多的bug率。

qq 20180503235533

4. review一遍代码,这里分为自己review和邀请其他人review。
  • 自己review:
  1. 看是否有啥异常没有处理。前端经常犯错就是容错性不够好,毕竟从发起后台请求到你拿到数据,过程是多么艰辛。
  2. 修改了哪些点,尽可能记下来会影响哪些模块!!
  • 他人review: 对于新人来很有用啊~
5. 提交测试

把自己会影响的模块列出来发给测试,这样他才知道重点啊~尤其是在写新需求夹带修改旧代码的时候!! 这个很重要!!! 如果有接入前端错误监控的话,关注一下报错内容。我们项目是有接入Badjs错误监控的。

6. 发布之后,你的产品有论坛或者群吗?

有的话直接加上去,观察用户反馈。往往这些地方是bug反馈最及时的~~~~~

总结完了,忐忑的去吃鸡然后默默等待明天批评。

文章分类
前端
文章标签