《代码大全》读后感（2） 程序工作不正常总是有原因的

        作者在书中，反复提及，不要在代码还没有写好或者自己根本就没有弄清代码逻辑的时候，就采用简单的尝试方法让程序编译和运行起来，查看结果是否正确，当结果正确后就认为已经完工了；一个典型的例子便是更改循环时候的比较条件，试试能不能干活。
        我想很多人在还是新手的时候都犯过类似的错误吧，至少我犯过类似的错误。在学生时代实验室的项目里面，能够成功的编译是主要的工作目标之一，很多时候根本没有弄清楚代码的逻辑，只求为了编译通过急切的看一下运行的结果。运行结果不正确的时候，再凭空猜想一下哪里出了问题去改一改，运行结果正确后就觉得万事大吉了。
等到工作后才发现，要想让程序健壮可靠，首先必须自己弄懂了程序，即使不能做到明白每一句代码是做什么的，也要明白每个函数是在做什么，是不是正确完成了功能。当然，最好是能够弄明白每一句代码是做什么的，至少明白自己为什么要写这一句代码，为什么是+1而不是-1，即使是因为架构或者历史代码或者进度的原因，不得已需要添加一些不够好的代码或者设计，也请给自己留下注释，而不是简单的根据当前是否能够工作来进行编码工作。要知道，在你开发的机器上没有出现问题，可能是因为你测试的Case不具备一般性，或者是本身的环境特殊等等原因。
        具体到修改Bug来说，我看到很多人都没有找到造成问题的真正原因，只是尝试性的修改了代码，好像当时可以工作了，就以为问题解决了；实际上呢，可能对于更一般性的Case引入了更多的问题，或者，只是针对一种特殊的情况作了改变，最常见的，是针对出现问题的情况进行了改变；然而，本质的问题，代码中的逻辑错误，并没有被修正，从而埋下了隐患。
        引申思考一下，程序工作不正常总是有原因的，80%以上都是由于程序代码本身的原因造成的。我们需要找到了根本原因，才能改善程序。即使不是程序代码的原因，那么也可以从其他方向改进。
        要找到原因，首先就如书上所说的，弄清楚程序的架构，设计和逻辑，至少是相关代码的架构，设计与逻辑；如果设计和代码逻辑本身就有问题，程序如何能够工作正常呢？即使偶尔出现了负负得正的结果，那也是非常危险的。我曾经遇到过这种情况，某个函数，正常情况应该返回TRUE的，但其实内部两处代码都写错了，于是将所有的异常情况都处理为正常情况了，工作起来没有问题，QA发现不了Bug，因为异常情况是难以模拟出来的，但是一般在最终用户机器上出现这种问题，将是致命的。而且，这个工作，不仅仅是在出现了问题的时候要做，在平时的时候，如果有足够的时间，就应该做掉，如果不了解自己的程序，那么工作效率不会高；如果代码本身质量太差，差得让人难以理解，那么想办法通过重构来改进。
        此外就是调试。当发现问题所在的时候，Debug一下，很容易就能找到问题所在。不调试是改不了Bug的，即使通过Review代码的方式发现了问题所在，修正问题之后，仍然需要通过调试来确认程序按照设想的逻辑运行，更何况，有很多问题很容易在Review的过程中忽略掉。