虽然软件质量不等于代码质量,但是代码上的缺陷会严重的影响到软件产品的质量。那么如何提高代码质量？请看我为大家带来提高代码质量的十二个技巧。
技巧一：测试驱动开发(TDD)
如果说要找一个最能提高代码质量同时还要减少bug的实践练习恐怕就非TDD莫属了。它的优点是适用于任何类型的项目和敏捷开发。其历史可以追溯到很早以前，但是直到XP的普及它才渐渐为人所知。当作为能自动化构建和测试实践的持续集成周期的一部分运作的时候，它被称为单元测试。
很多开发人员并不知道该怎么提高这方面的能力，这需要培训和教育。而且这是一个学习和积累的过程，不要想着能一夜吃成个胖子。
技巧二：验收测试驱动开发(ATDD)
这是基于TDD单元测试之后的一个新的水平。这不但表明了验收标准，而且还能在开发工作开始之前自动执行开发需求。在很多情况下，需要专业测试人员和客户携手共同参与到测试中去。
技巧三：持续集成(CI)
这能确保新代码不会干扰到已经存在的代码。如果再加上TDD和ATDD一起创建一个自动化、可重复的的测试套件，将会大幅度提高其使用价值。
技巧四：结对编程
有关于结对编程的争论似乎已经偃旗息鼓了，同样的人们实际应用的例子也越来越少。这不可谓不是一个遗憾。因为在即时的代码审查上，两个脑袋总比一个管用。它也允许开发人员将注意力全部灌注到手头的工作上——不必分心于电话、邮件、短信等等，因为我们的partner会搞定。
技巧五：代码审查
如果没办法结对编程，那么退而求其次，至少得进行一次代码审查。最好代码一写好就能落实到位一个轻量级流程的代码审查。我们在学校里学的那种又大又正规的流程其实并不实际——只有NASA( 美国宇航局)这种不差钱的土豪才买得起。所以换个轻量级的流程，意味着只需20%的成本就能享受80%的相同效果。
技巧六：静态分析工具
以前人人都不看好所谓的静态分析工具。现在则好了很多，虽然它们仍然并不能真正替代代码审查，但是其使用成本比较低。当然可能需要购买许可证，但是一旦将它们设置进系统中之后，以后每一次我们输入代码，它们都会一丝不苟兢兢业业地检查并且快速提示发现的所有错误。
技巧七：编码标准
老实说我并不怎么喜欢编码标准。从我的经验来看，很多团队在讨论编码标准上面浪费了太多的时间，而且一旦确定了某种标准，这往往会损害一部分开发人员的利益。不过如果我们能克服这些问题，那么绝对会有意想不到的效果。
首先建立一个讨论小组——应该以一种面对面的形式，不要通过电子邮件和电话——讨论出编码标准里应该包含哪些内容。找到需要讨论的地方，规分为不同的类别：少许定位为必选项目，推荐项目的数量可以较前者多点，候选项目则可以更多。在候选组里的需要经过深思熟虑之后才能放到推荐组和必选组中。剩下的第四组则是明确不能成为编程标准的内容。
每隔三至四个月检查一下这些标准，看看有没有需要从候选组提升到推荐组，或者从推荐组放到必选组的，要是发现什么已经不适应当前工作的项目，那就尽快删除或者降级。
此外，我们不应该将编码标准当做代码审查的一部分，而是两手都要抓，两手都要硬，万一不得不遗漏其中之一，可以借助自动化工具，例如运行静态分析工具，自动执行代码标准来检查代码。
技巧八：自动化
其实就目前而言，我们提出的大多数意见和建议，是能够自动化执行而且也应该被自动化执行的，但是可惜的是这个概念还没有深入人心。从长远看，非自动化就意味着需要耗费大量的时间，而且成本更高。虽然自动化看似在短期内需要投入大量的成本，但是从整体上而言，其实是节约了成本的。
技巧九：重构(以及重构工具)
重构的目的就在于提高代码质量，当然更重要的是，改善整体的设计。如果重构之后不能达到上述目的，那么说明你的思路错了。我们可以在重构的时候摒弃自动化单元测试，而且很多人也是这么做的，但是这等同于高空走钢丝的时候下面没有安全防护网——一旦失足便万劫不复。如果是装备了“安全防护网”的重构不但毋须占用大量时间，而且还能频繁运行。
以上这些对于能提高代码质量显然是显而易见的。还有一些虽然也在图片名单上，但是并不那么为大家所认可，不过我认为它们也值得包括进去。
技巧十：展示和说明(早期)
也许你会奇怪这怎么能提高代码质量呢，请不要怀疑，It does。因为定期展示相关潜在客户对于软件的要求，能促使开发人员不断地将他们的代码保持在最接近发布的状态，这也使得开发进程更快、更细致。
第二个原因则是能收集更多周期性的反馈，指引我们正确的方向。
最后，如果一个开发人员害怕将他的工作展现给用户和客户看，这是一个非常危险的信号，最好停下来好好自我检查一番。
技巧十一：用户测试
用户测试能让我们从另一角度进行测试，以便尽早发现问题。
与第10点相同，碎片化的处理模式能提供更为细致的步骤。无论是在工作规划上还是在改进代码上面，这都给了我们一个机会，能在做每一个决定之前都可以重新调整和矫正航向。
技巧十二：团队凝聚力
关于团队的凝聚力其重要性不言而喻，因为一个团队一旦失去了凝聚力，那么大家就会各执己见，各施其力。要想不如此，我们就必须要在开发目标和如何设计代码以及如何改进代码上面的观点达成一致。
原文地址：http://blog.csdn.net/oydaybreak/article/details/45743055
