一直打算着对服务器进行全面的单元和模块测试，但是目前的服务器代码之间耦合性很高，模块和模块之间交错调用，几乎无法将代码单独抽取出来进行模块测试，如果要进行单元或模块测试，则需要对代码进行重构。那么如何来对代码进行重构，编写出可测试的代码呢？    我觉得我们首先有必要定义一下什么才是可测试的代码，个人觉得可测试的代码应该是低耦合的，接口清晰明确的代码，可以说就是“个人自扫门前雪，不管他人瓦上霜”，每一个函数、每一个模块，都应该只做自己该做的事，不要把别人做的事扯进来。高质量的代码应该是可测试的，只有能测试了才可以验证和提高其正确性。    我们重构的准则是：重构不应该改变程序对外的行为，从外部观察，重构前和重构后，软件行为应该是一致的。重构的好处：1、改进软件设计，一个设计良好的软件，在逐渐往里面增加新功能、修改bug，扩展功能，一段时间后，整个代码的结构往往会偏离原来的设计思想，程序也逐渐失去了自己的结构。重构可以将代码重新拉回到原来的设计，并减少冗余的代码。达梦5.6服务器的整体设计应该说是比较良好的，也保证了其可扩展性，但是模块内部由于功能的扩展或修改，经常可以看到函数A和A_ex，甚至A_ex2之类的，这些函数的相似性非常高，通常只是很少的修改而已，这样代码的冗余完全可以通过重构来减少。2、提高代码的可测性，只有经过充分测试的代码才是正确、稳定的代码，通过重构，可以更好的直接对单个模块进行测试，验证其正确性，另外未来再在该模块上进行开发，也可以很容易的通过回归测试来保证这部分代码的正确性。    那么我们如何来对达梦服务器的代码进行重构呢？目前我们的重构首先要保证的是代码的可测试性，即重构后的代码应该是能够将单个的模块单独抽取出来，通过开发桩和驱动程序来进行模块测试，极限开发是测试驱动开发的，那么我们的重构可以理解为测试驱动重构，即我们希望如何来对这些模块进行测试，编写出我们的测试代码，然后通过重构来满足测试条件，使得这些模块可以在测试代码下运行。所以说对服务器进行重构首先是编写测试代码。我们可以将重构的步骤大致的做下面的归纳：1、模块划分：这个模块的划分不只是从宏观上对整个服务器进行划分而已，还要细化到每个功能的实现，例如事务模块，还可以细分为事务管理模块，封锁模块，日志模块。2、模块功能的明确：进行完模块划分之后，接下来就要明确该模块完成的功能，这个模块是不是只做了它应该做的事情，而没有做其它模块需要做的事情，低耦合的模块其功能应该是相对明确的。3、模块接口的明确：某个模块的功能清晰了之后，那么就可以明确该模块对外提供哪些接口来供其它模块调用，其它的函数都应该只是内部调用的，外部没理由也没办法去使用这些模块，如果要使用的话，都应该是通过这个模块提供出去的接口来使用。4、模块调用关系确定：除了非常底层的模块，其它模块应该都会有和某个或某些模块产生一个调用的关系，那么我们需要明确这一关系，从而方便未来测试时编写相应的桩。5、测试程序的编写：明确了模块的功能、接口和调用关系之后，我们就可以开始编写测试程序了，对于模块测试，我们不需要知道这个模块具体是如何实现的，模块测试只关心这个模块提供的功能是否正确。6、代码重构：重构前，我们的模块测试程序也许是不可运行的，甚至可能是不可编译的。就像测试驱动开发一样，测试用例完成之后，这些测试用例肯定都是不能pass的，接下来就是编写代码来满足这些测试用例，使得所有的测试用例可以通过。那么重构也是这样，我们需要对这个模块进行修改、调整，使得其可以满足编写的模块测试用例。