敏捷开发纵横谈(2)

　　这个实践有点剑走偏锋，有人还会因为这个实践不仔细思考软件设计就编码了，我们有很多项目因为设计得太烂而吃了不少苦头。实战简单设计时，我有这样的一些建议：

　　1)对于没有类似经验的项目，设计应该尽量简单，但简单的设计是需要严谨的思考得到的，你不要认为简单想一个设计出来就是简单设计。

　　2)思考项目设计时，应考虑有什么东西可以重用，同时适当考虑本项目有什么东西可供以后的项目重用。

　　测试方面的最佳实践：

　　1.测试驱动开发：先有测试再有开发。

　　我们一般的顺序是先开发后测试，然则这个实践要求我们先将测试想好，然后开发来满足这些测试。

　　这个思路其实就是目标驱动，我们先假设软件已经做好，那么我们先写出测试用例，然后我们编写的开发代码应该能通过这些测试用例。这样思路的好处就是能让我们想清楚目标，所有的开发都是有针对性的，减少无用功，提高工作效率，同时因为测试已经写好了，代码的质量会更加有保障。

　　这个思路其实是相当优秀的，但这个实践可能是这么多最佳实践中最难成功实施的!我们公司曾经推行过一段时间，最终还是失败告终。难以施行有以下原因：

　　1)开发人员普遍没有这么高的编程素质。

　　先不说测试驱动开发，我们往往连单元测试也做不到!测试驱动开发其实就是要求我们先写出单元测试代码，然后再写出满足单元测试代码的代码。

　　2)编码是一个循序渐进的过程，不太可能一开始接口就想好并且后面不会变了。

　　我自己编写代码也不太可能一开始就完全想清楚类中的各个属性方法，有时候会觉得方法名字不好会换掉，参数不太合适也会调整。如果我们先写出测试的代码，其实就要求我们先确定各类名称以及各类的公开接口，但往往我们需要不断调整，这样就会导致开发代码与测试代码都需要同时调整，工作量就增大了。

　　3)达不到自动化测试的技术层次。

　　自动化测试需要工具支持，并不是所有公司都具备这样的条件。

　　测试驱动开发的意义还是很重大的，我有这样的一些实践建议：

　　1)先写开发代码，然后写单元测试代码。

　　2)编写代码时，应该先想清楚类职责，类公开接口，然后再写具体实现代码。

　　3)某个类完成时或者阶段性完成了一些功能时，应该马上写出相应的测试代码，并保证开发代码能通过测试。

　　4)如果不能针对所有类都写出测试类，那至少应该针对重要的、核心的、被使用次数多的类编写测试代码。

　　5)单元测试应该能做到自动化。

　　2.自动化测试：自动化单元测试、自动化UI测试。

　　自动化单元测试，目前很多开发工具都支持，技术上问题不大，问题大的是大家不去执行或者说是能力不够执行不了。

　　UI方面的自动化测试就有点麻烦了，有这样两点：

　　1)就算是比较好的自动UI测试工具，也难以捕捉到软件界面上所有的控件以及动作。

　　2)软件的界面经常调整是很常见的时间，界面不冻结，UI自动化测试寸步难行。

　　要推行100%的自动化测试难度还是很高的，不过应该还是尽量自动化测试，单元自动化测试与性能自动化测试在技术上是没有问题的，是执行的能力与决心问题。

　　自动化测试这个最佳实践与测试驱动开发是紧密相关的，这两个最佳实践其实是整个极限编程中最核心、最精彩、要求最严格的两个实践。只要将这两个实践做好，代码随便你改，只要能通过测试就行，不用害怕需求变更带来的代码隐患，变就变，反正有自动化测试全面检查!

　　编码方面的最佳实践：

　　1)重构：不讲究一次将代码写好，但需要重构时应该毫不犹豫。

　　重构的意思是代码的接口和实现功能不变，但修改代码的具体实现，从而使代码的结构、可读性、性能、安全性等更好。

　　重构因为有测试驱动以及自动化测试这两个实践的支持，故不需要担心重构带来的影响，万一重构失败，取回原来的代码便可。

　　2)结对编程：两个人，组成一对，共用一台电脑编程。

　　头次听说这个，还觉得很难想象，两个人坐在一起，只用一台电脑，一个人写代码，另外一个看，过一会两个人可以交换一下。

　　两个人一起写代码，相当于随时在做同行评审，似乎效率降低了，但代码的质量得到保障，并且能保证所有代码至少有两个人了解的。

　　另外要注意的是：组成一对的两个人，应该水平相当。

　　这个实践很有意思，不过往往也是很难实践的。

　　就我个人来说，我就不喜欢两个人一起编程，我觉得每个人的思考其实很难同步的，每个人都需要静下心来一个人思考问题，思考后才适合与别人讨论，如果思考过程也与别人在一起，很难想象这个思考能有好的效果。

　　我们曾经将两位编码新手放在一起，让他们结对编程，尝试了这个实践，似乎有一点效果，但我们后期就没有再推行过。

　　3)代码共有：每个人写的代码都是属于全体的，每个人可以去改别人的代码。

　　这里强调共享与进步精神，欢迎互相研究代码，欢迎写出更好的代码，只要能通过测试就可以了!这个实践是依赖于测试驱动开发以及自动化测试这两个实践的，如果不能做到那两个实践，就不应该随便改动别人的代码。

　　4)强调编码标准

　　对于这点大家应该没啥异议了，现在有不少开发工具支持编码标准检查呢!

　　项目管理方面的最佳实践：

　　1.持续集成

　　持续集成与微软的“每日构建”是一样道理的，强调我们的软件要随时处在可以编译通过可以发布的状态，持续集成让软件的问题提早暴露更快解决。持续集成需要一定的工具和管理措施支持，我有这样的一些实践建议：

　　1)代码的签入与签出要定下严格的规矩，如：每天工作前先获取最新代码，每次签入前必须先保证编译通过。

　　2)如果能做到测试驱动测试和自动化测试，那么还应该规定必须通过所有测试才能签入代码。

　　3)一般来说我们没有条件做到每日构建，也没有这么多工具支持，那么至少一周要编译一次内部版本，检查软件各部分的协调情况。

原文转自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html