项目心得－关于提高代码质量的一些体会

如何进行良好的编码，提高编码质量

1        问题的提出

到公司两年也作了一些项目（主要是业务系统）。对公司相关的流程也有了深刻的体会。项目的进行过程主要分为大给以下部分：

 需求- 设计- 编码-测试-部署-维护。

项目人员投入和时间分配大概如下

房地产项目：

还有科技局项目：

从上面可以看到：业务系统的周期可能（因为只是这两个项目，所以一切只是可能，只能说很有可能）会非常漫长，系统构造的时间（包括1-5步）小于（或远小于）系统维护的时间，因为这种业务系统用户的特殊性，维护工作将会持续很长时间。比如科技局的，到现在用户才用了1/3的功能，我在科技局的第一个月中，每天都有用户提出至少一个bug，或者对于某个功能的修改意见，加上功能修改基本都是基于jsp页面，修改起来并不轻松。系统后期维护的成本非常大！

2        解决方案

我们哪里做的不好，系统后期不也作了测试吗？为什么会在维护期出现这么多的问题？

原因有很多，一部分在我的《如何合理的进行业务系统的设计》说明，系统设计是个重要的部分，设计阶段的错误如果在后期要进行修改，花费的时间和改一个bug不是一个数量级的，因此要注重进行系统的分析设计，这里就不再多说。另外一些原因个人觉得如下：

l       没有进行单元测试，无法保证代码的可靠性。

l       基于jsp的机制造成代码的可读性十分低下，修改十分困难。

l       代码的重用率低，不同人对业务过程的复写会因为各自对业务逻辑的理解而存在差异。

解决上面的问题个人觉得有以下几个方法：单元测试、代码重构、代码审查。

2.1        单元测试

测试人员所进行的测试是集成测试，也就是黑盒测试，它不能保证代码的测试覆盖率（就是被测试的代码占所有代码的比率），如果哪个功能使用到没有被测试的代码那么很可能会出现新的程序bug！在科技局项目提交测试之前，任何单元测试的代码都没有，没有人能拍着胸脯说：“我的代码绝对没有问题”。我听到的最多的也是我说的最多的：“应该没有问题吧！”。这样的系统将很多问题的发现向后推了一个甚至更多个阶段，如果测试人员发现了一些问题，这好办，如果部署到用户环境后，仍然有大量的bug出现，这确实要问问自己了。对于程序员来说，不能过分的依赖测试人员，原因上面也说了，测试人员进行的是黑盒测试，他们不知道你的代码有多少条件分支，比如