关于程序猿怎样降低程序Bug的若干建议

毫无疑问，程序猿是善于思考问题的一族。

一个程序的编写都是通过：思考、设计、编写、调试、測试以及执行这些主要的阶段。

　　但大部分程序猿都有一个问题就是不太愿意測试自己的代码。

他们草草的调式完毕以后就觉得工作结束，測试那是測试人员的工作。

　　依照理论上。假设代码存在问题。那么測试人员和终于的用户肯定能够发现这些 BUG ，而等待哪个时候再返回来查找问题究竟错在什么地方确实代价不小，其代价有：

　　1. 影响了程序猿自己的声誉

　　2. 影响了产品的质量

　　3. 影响了客户的信任度

　　4. 这个时候再 DEBUG 难度增大了很多。

　　大的不说，就说多自己声誉的影响吧。假设你的程序总会有这样那样的 BUG ，你得到收益会降低，即使你写了非常多代码。

　　事实上最后一点也非常重要;在我们面对一块代码的时候。什么方法都好办，但假设将这块代码防到庞大的系统中之后。简单的问题也难以被马上找出来。为了自己考虑，节省自己 DEBUG 的时候，我们应该让我们的程序尽量没有 BUG 。

　　那么怎么样才干保证自己的代码没有 BUG 来?

　　程序猿必须克服一些自身的致命缺点才可以从根本上解决问题。

那么这个问题是什么?前面我们已经提到。程序猿对自己的代码都非常宽容，觉得那是正确的没有问题。实际上这样的想法比較正常，程序是通过程序猿思考和设计之后才写出来，程序猿不会将自己觉得不对的东西写到代码里，而到这个时候都一直如果程序是正确的;但人非圣贤，怎么可能不犯错误来。实际上程序猿在对待其它程序猿时候的态度就非常好，带着一种挑剔和学习的态度;但一旦对待自己的代码就非常难这么做;这就是最致命的。程序猿也必须对自己的代码带着挑剔和学习的态度;这个基础是如果自己的代码是错误的，然后须要做的是怎么样证明自己的代码是正确的。程序猿自身可以在程序生成的每一个阶段做这些工作：

细致的设计、编写代码时、单元測试(重要)、功能測试。

　　1.细致的设计：这个的细致是说在程序猿编写代码之前，其必须对代码的整个结构以及逻辑结构有明白的清晰的了解，仅仅有这个时候才干够去写代码。这里没有谈到文档。但我说到了一定要清晰的思路，但清晰的思路不是每一个人都能够在脑袋中直接形成的，非常多人都是普通人，没有办法在脑袋瓜中把全部问题都想清晰，那么就记下来，特别对于复杂的逻辑（这个时候画点时间是值得的。必须保证我们对自己的程序有清晰的轮廓后才干開始动手写）。

　　2.编写代码：对于没有把握的代码。比如：新设计的算法，最好保证其正确性。

能够单独将这部分測试，这能够让代码模块化的同一时候又保证了代码的正确性。一句话：少量的代码保证质量还是比較简单的。

　　3.单元測试：单元測试的重要性不在赘叙了，如今也有很多工具能够帮助程序猿并降低工作量。

　　4.功能測试：程序猿保证自己代码质量的最后一关;为了做这种工作我们可能必须写一些代码来測试，甚至是測试工作。

使用大量的 CASE 来測试，以及错误的 CASE 。这里和測试人员的測试不同之处在于：仍然让程序猿的注意力放在其自己的代码范围内。减小了排错的难度。

　　*.假设你通过了以上的步骤都找不出你程序中有不论什么问题的话。那么我想你的程序可能须要的不仅仅是REVIEW了，你可能须要抛弃它，依照之前的思路或者换个思路又一次来一遍，这个过程想想也许非常麻烦。事实上当你真的静下心来去做时，你会发现你得到的不仅是一个没有bug的程序。很多其它的是你根本意想不到的收获。并且这次的代码写的远比第一遍更顺利，更快。更健壮。

it's unbelievable.

　　前面说道了程序猿对待别人代码的态度是挑剔和学习的态度。所以让其它程序猿来 REVIEW 你的代码也是检查程序有没有逻辑错误的非常好的办法。团队中应该交叉 REVIEW 代码，这是实践的经验。

　　作为一个好的程序猿必须有以上的习惯。以及对待自己代码象孩子一样。我们要爱惜我们的代码。同一时候也要让代码走正确的路。