相信程序猿们敲代码时都经历过这种阶段。一开始，怀着极大地志向，打算把代码写的尽量优雅，各个方法清晰易读。但随着时间的推移，项目的逐步增长，发现代码越写越乱，自己花费了大量的时间在代码的调试上，经常是改了一处，却牵扯到其他众多地方，级联的错误，而导致你把大量的时间花费在回忆自己先前的逻辑与代码调试中，而陷入了“焦油坑”中。经过了这个过程，心中唯一想做的就是尽快把这份代码写完，早些摆脱这堆臭代码，先前的志向种种早已不复存在了。

　　乐观的以为自己在下一个项目中，再次从零开始编写代码，只要多注意，就能够写出一个好的代码，殊不知却永无改进，下一次，仍然一团糟！

　　看来，我们需要一些手段，一套好的方法，来帮助我们构建出更好的代码。

　　1、善用单元测试工具、而非仅使用控制台的输出

　　我想是因为软件测试课，教我们各种测试的方法，黑盒、白盒、单元测试、功能测试、系统测试…大量的测试，一个完备的测试有语句覆盖、路径覆盖、分支覆盖、条件覆盖…让我们对测试充满了恐惧，程序的开发者，能不接触就少接触吧！

　　正是这种方式，让我们失去了改善代码开发效率、摆脱无尽的调试过程的有力武器。意外中接触到了TDD（测试驱动开发），尝试了里面教我们的“在编写代码前先写好测试用例”的方式来进行项目开发。初期，我们应该都是使用控制台的输出语句来进行正确与错误的判断，但这种方式有几点的弊端：1、输出语句与主代码相杂糅，导致代码不干净。2、往往在某个功能实现完毕后，便删除了这些测试方式（输出语句），他们难以被复用。3、我们需要人工验证输出的结果是否与我们预期的相符合，如果多次调试，势必耗费大量时间。

　　需要一种方式，将我们的测试与主体代码相分离，并且其他的存在不会对主体代码产生干扰，如果还能够减少我们人工验证的工作量那就更好了。Java提供了JUnit的测试框架，这是由kent beck（极限编程之父）与他的同时共同开发出来的一套测试框架。提供给我们十分方便的通过测试套件进行单元测试。我们只需在完成某个功能或者写完某个方法后，在相应的测试类中添加测试方法，便能够对所实现的功能进行测试，通过断言来验证匹配输出与我们预计的结果是否吻合。这样，我们在对程序做任何的修改之后，都能够通过运行测试用例及时发现bug，对其跟踪。而不是在改了代码一段时间后，发现修改的代码引发了一系列的问题，而需要耗费大量时间修复。编写测试，虽然增加了一部分时间，但能够减少大量的程序调试时间（这话是前辈说的，但我亲身体验过）。并且让自己的思路更清晰，何乐而不为呢？

　　推荐资料：《Agile Java》，上网下了他的电子版，虽然只有前四章，但对TDD有了大体的了解。

　　《重构：改善有效代码的设计》，第四章也有提到测试驱动开发。

　　《测试驱动开发》Kent Beck写的，没看过，应该不错。

　　编写测试不是为了应付交差，而是让自己更有效率的开发，记住，在值得的地方写测试，将力气花在大头上。“编写不完善的测试用例并实际运行，好过完美测试的无尽等待”。

　　2、重构不是因为你的代码很糟，而是让你的代码更棒

　　记得我和一个同学推荐《重构》这本书时，他回复我说，“你说我的代码需要重构，是说我的代码写的很烂么？”虽然他出于半开玩笑的态度说这句话，但可知他对于重构，并无意识，觉得重构是针对烂代码而言的。

　　其实，重构的意义，不仅仅是对不好的代码内部结构的调整。毕竟没有人在做项目时，能够写出一首完美、无需变动的代码。那么，在代码需要调整的时候，如何既能够保证代码的可读性，又能够保证代码的正确性进行结构的修改呢？面对一个不具有很好的扩展性的代码，如何能够最大的利用原有代码，去添加方便的新功能？

　　在开发阶段引入重构，习惯性的重构自己的代码，让他更具可读性、变得更易修改，这样，在你今后需要修改代码或者引入新功能的时候，更有效率。清晰地代码也减少了你沉溺于寻回早期设计思路的泥藻。回到最初，你一开始不就希望能够写出一份设计清晰、方便阅读的代码么？

　　开始编码前的设计是必不可少的，但如果一味的期望前期的设计能够完美的呈现于最终的代码中，难度难免有些偏高，并且设计的成本风险也很大。重构的方式就犹如迭代的开发方式的细化，能够让我们不断对整体的设计进行调整，让他能够达到一个最佳位置，以最好的方式呈现。

　　掌握测试的方式，就像是让外界的人帮助监察自己的不足，及时发现，及时告知。掌握重构的方式，就像是及时审视自身，发现自己身上的不足、缺点，继而进行改正。内外兼顾，才能够做的更好。

　　掌握好这两个武器，我想，当自己穿梭于代码中，也能够游刃有余了吧！