最近发现自己目前的核心维护模块,接连出现了2个问题.

这两个问题都是自己的refine代码过程当中,自己引入的新的问题.

说实话,这个对我打击挺大的.其中一个是别人检查出来的,另一个是自己检查出来的.

bug的细节就不多说了,其实都是比较基础性.但是定位的过程是曲折的,因为从触发条件->出错现象->定位分析->解决问题,这个流程是复杂的.

但是需要注意的是新引入的问题.

我们可以从两点上面避免此类问题:

逻辑语义一致

涉及到逻辑的修改,需要务必慎重.要保证重构过程中,要尽可能保持逻辑上和之前的版本是一致的.

之前版本,可能存在问题,但需要确认存在问题,方进行修改.

一致性改动

代码中的修改,单点的改动很少.很多改动需要多处的配合,这个时候就需要保持一致性.

改动之后,要经过详细的代码走查,来保证涉及的模块,都进行了相应的变动.

自动测试

自动测试被强调的很多,这次还是需要再次强调.

测试程序也要随着代码主体一起演进,发现了新的case,那么就要加到测试列表中,从而保证更为丰富和健全的测试.

注释与日志

代码中要加上注释,这点不需要说了.尽管实际中代码没有那么多注释.

良好的日志是注释的更好的辅助,其实我的建议是良好的日志比注释更为重要.

日志系统,可以列出关键信息,并且简要说明当前的关键状态点.根据日志,其实就已经可以推想代码模块中目前所处的状态.

甚至QA和AE也可以根据现场生成的日志,更为准确的判断,从而节约开发者的时间.

良好的日志系统,要可读性良好.这个可读性是满足两方面

• 人类可读
• 机器可读

人类可读,这个非常显然,前面的描述就是为此.机器可读,是在于大量日志的情况下,通过简要的日志分析,通过日志分析工具,甚至简单的grep帮助我们快速定位的问题所在的地方,并且将其上下文展示出来.