About Blog GitHub

11 Jan 2018
coding感想(三)

最近的主要工作就是bug fix,所以借此机会总结下,都是bug fix的相关内容,其实是我工作中遇到的一些小问题,有些道理很简单,但没经历过,也就未必明白。本次主要分享以下5点:

  • 代码有bug是常态
  • bug fix一定要找到root cause
  • 提交的代码一定要测试通过
  • 提交代码一定要有commit信息
  • bug fix时能删除的代码就不要注释

1) 代码有bug是常态

我们经常需要去维护别人写的代码,有时候看见一些自己认为写得很烂的代码时,总是控制不住自己,忍不住想,写这代码的人得多不负责,才写出这种代码,不排除存在一些不负责的程序员敷衍了事,但是编程经常都是受到时间、业务场景和技术水平等各种因素影响,有可能我们看到的烂代码是人家一天时间写出来的,估计给自己一天时间,也未必赶得上这水平。在维护别人代码时,不要老是抱怨有那么多bug,多些理解,少些抱怨,要想写出没有bug的代码,只有一个办法,就是不写代码。额,那位站起来的同学,把你手中的砖头放下,我开个玩笑而已。

2) bug fix一定要找到root cause

在fix bug时, 一定要找到导致bug的真正原因,例如,某bug产生现象A,但是现象A是由B引起,B又是由于C导致。那么在fix时,如果不真正解决C,那么该bug的fix就治标不治本,达不到fix bug的目的,真正的原因未找到,那么该bug有可能在fix后还会出现,导致bug fix失败,然后就会 reopen += 1。

3) bug fix提交的代码一定要测试通过

提交到版本库的代码,如果是bug fix阶段,一定要确保代码经过测试,也许你觉得一点小改动不会有什么影响,修改完就直接提交,但是往往等待你的是编译失败,或者编译成功了,产品却不能正常运行。到了bug fix阶段,要确保版本库中的代码处于可用状态,随时可以编译成功,不影响QA测试,也不影响其他同事使用。试想,如果因为你的一个改动,导致整个项目编译失败或者编译完不能正常使用,这是很不负责任的做法。所以,bug fix完后,往版本库提交代码时,一定要测试通过,至少要测试下引起bug的相关case。

4) 提交代码一定要有commit信息

在工作中,不管是产品的开发阶段,还是发布后的维护阶段,经常需要往代码库提交代码,在提交代码时,一定要写清楚本次提交的目的,有时候查看公司代码库的提交日志时,发现很多人提交代码竟然没有任何commit信息,或者简单的写了一个单词update,对于这种人,我就等着看他们回滚代码的那天。为什么要有commit信息?因为大家是在一个代码库工作,如果某天有很多次代码提交,第二天build的产品出现各种bug,那么有时候根据commit信息就能很快找到原因,因为bug往往在被修改的代码周围。另外,如果有时候需要回滚代码,如果没有commit信息,需要去仔细查看每次提交的diff才能确定回滚版本,实在是太浪费时间了。

我个人的commit信息一般会有以下4类:

  • bug fix:表示本次提交是一次bug fix,并附上bug相关信息
  • code format:表示本次提交是格式化代码,仅修改代码的格式
  • code refactor:表示本次提交是一次代码重构
  • daily commit:日常开发提交,附上本次提交的主要内容

5) bug fix时能删除的代码就不要注释

有时候看代码,会发现大片被注释的代码,然后在被注释代码旁边,又写了和被注释代码功能类似的代码,让人一头雾水。最后猜测估计是bug fix时,将以前的错误代码全部注释掉,然后将正确代码写在旁边。对于此类人,我想问下你,难道你不知道版本管理器的存在吗?每次bug fix都将错误代码注释掉,以后代码库怎么维护?既然是不需要的代码,就应该直接删除,下次如果想查找本次删除的代码,通过版本管理器,查看本次提交的code diff就可以找到。

本次分享就到这里,下次再继续~



LEo at 15:51

About Blog GitHub