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就可以找到。

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