测试方面的最佳实践：
1.测试驱动开发：先有测试再有开发。
我们一般的顺序是先开发后测试，然则这个实践要求我们先将测试想好，然后开发来满足这些测试。
这个思路其实就是目标驱动，我们先假设软件已经做好，那么我们先写出测试用例，然后我们编写的开发代码应该能通过这些测试用例。这样思路的好处就是能让我们想清楚目标，所有的开发都是有针对性的，减少无用功，提高工作效率，同时因为测试已经写好了，代码的质量会更加有保障。
这个思路其实是相当优秀的，但这个实践可能是这么多最佳实践中最难成功实施的！我们公司曾经推行过一段时间，最终还是失败告终。难以施行有以下原因：
1）开发人员普遍没有这么高的编程素质。
先不说测试驱动开发，我们往往连单元测试也做不到！测试驱动开发其实就是要求我们先写出单元测试代码，然后再写出满足单元测试代码的代码。
2）编码是一个循序渐进的过程，不太可能一开始接口就想好并且后面不会变了。
我自己编写代码也不太可能一开始就完全想清楚类中的各个属性方法，有时候会觉得方法名字不好会换掉，参数不太合适也会调整。如果我们先写出测试的代码，其实就要求我们先确定各类名称以及各类的公开接口，但往往我们需要不断调整，这样就会导致开发代码与测试代码都需要同时调整，工作量就增大了。
3）达不到自动化测试的技术层次。
自动化测试需要工具支持，并不是所有公司都具备这样的条件。
测试驱动开发的意义还是很重大的，我有这样的一些实践建议：
1）先写开发代码，然后写单元测试代码。
2）编写代码时，应该先想清楚类职责，类公开接口，然后再写具体实现代码。
3）某个类完成时或者阶段性完成了一些功能时，应该马上写出相应的测试代码，并保证开发代码能通过测试。
4）如果不能针对所有类都写出测试类，那至少应该针对重要的、核心的、被使用次数多的类编写测试代码。
5）单元测试应该能做到自动化。
2.自动化测试：自动化单元测试、自动化UI测试。
自动化单元测试，目前很多开发工具都支持，技术上问题不大，问题大的是大家不去执行或者说是能力不够执行不了。
UI方面的自动化测试就有点麻烦了，有这样两点：
1）就算是比较好的自动UI测试工具，也难以捕捉到软件界面上所有的控件以及动作。
2）软件的界面经常调整是很常见的时间，界面不冻结，UI自动化测试寸步难行。
要推行100%的自动化测试难度还是很高的，不过应该还是尽量自动化测试，单元自动化测试与性能自动化测试在技术上是没有问题的，是执行的能力与决心问题。
自动化测试这个最佳实践与测试驱动开发是紧密相关的，这两个最佳实践其实是整个极限编程中最核心、最精彩、要求最严格的两个实践。只要将这两个实践做好，代码随便你改，只要能通过测试就行，不用害怕需求变更带来的代码隐患，变就变，反正有自动化测试全面检查！
编码方面的最佳实践：
1）重构：不讲究一次将代码写好，但需要重构时应该毫不犹豫。
重构的意思是代码的接口和实现功能不变，但修改代码的具体实现，从而使代码的结构、可读性、性能、安全性等更好。
重构因为有测试驱动以及自动化测试这两个实践的支持，故不需要担心重构带来的影响，万一重构失败，取回原来的代码便可。
2）结对编程：两个人，组成一对，共用一台电脑编程。
头次听说这个，还觉得很难想象，两个人坐在一起，只用一台电脑，一个人写代码，另外一个看，过一会两个人可以交换一下。
两个人一起写代码，相当于随时在做同行评审，似乎效率降低了，但代码的质量得到保障，并且能保证所有代码至少有两个人了解的。
另外要注意的是：组成一对的两个人，应该水平相当。
这个实践很有意思，不