设计编码中常见Bug及应对方法

设计编码出现Bug不可怕，可怕的是Bug太多，多到自己都顶不住压力。

这两天稍空，写个小文章，说说常见Bug及应对方法。

1）  业务逻辑实现方面的Bug

这方面的Bug主要出现在最初的分析设计环节，或者后续修改/添加业务规则时的分析设计环节。

个人理解这应该是最严重最麻烦的Bug——和业务规则关联紧密（“过后”业务规则容易忘记），代码跨度大（跨多个类甚至多个模块），分析排查起来困难，修改起来也困难。

这种类型Bug的预防，主要从思想理念上入手（个人经验能力比较重要）。N多的思想理念，就是用来提高设计质量，规避问题的。

（不要动手就编码）首先画出类图，线程模型图，并分析推敲以下问题，最好是找其他人一起做检查（通过code review来进行，这个很有价值，个人思维惯性容易作怪）：

a) 在设计实现类/模块时，多问问能隐藏些什么（尽量少透露信息出去），能更少的依赖其他类/模块吗（尽量少受其他类/模块影响）？

b) 类的继承和引用关系合理吗？

c) 耦合度如何？

d) 线程模型如何，线程间共享数据和同步如何，锁的力度如何？

e) 其他一些细节问题，如内存释放等？

f) 现在的方案对业务的分解和承担如何？是最简单最佳方案吗？有没有更简单更好的方案（大道至简，往往是理解越深，越重构，代码越少越清晰）？

实现之后，再从这些方面入手检查一遍，最好是找人review。

2）  技术应用型Bug。

对一些用到的技术理解和掌握不深导致的Bug。比方说一些参数的设置不当，一些细节上的疏忽等等。

这需要对要使用的技术有全面和深度的理解掌握。不多说。

3） 失误型Bug。

这种Bug主要出现在函数的设计实现过程中。

应对方法：

a) 一个函数只实现一个功能，保证函数体量小（这是一个大前提）。 

b) 首先编写伪代码，确定函数内的高阶层逻辑流程。然后检查高阶层逻辑正确与否。

此时不用纠结细节，减低了复杂度。

 c) 依次实现各个伪代码块的主干（中低阶层）。这样能集中精力各个击破，还是减低复杂度。

例如写if/for/while循环时，先完成总体框架，再完成各分支细节。这样各个分支中共同的代码不容易漏掉（这种Bug不少）。

d) 实现完成后，走查几遍，多问几个问题：大逻辑流程如何，细节上有没有遗漏什么前置条件，后置条件如何？如果这个函数有Ｂｕｇ，可能在哪里？

e) 单元测试。这个非常重要，但是前面的过程也很重要，不能全依赖单元测试来解决问题，这是不合理的。

（代码质量，性能等等，本文中暂且不说。）