故事是这样的，我最近深陷在一个刚接手不久的项目中，经过完成两轮需求上线后， 我迫切地告诉自己，需要给这个项目完善一下测试用例（原工程测试用例几乎为零）， 然而事情并不是我想象的那么简单。
经过两天给项目引入EasyMock，Jmockit相关测试框架，最终我还是没有完成对其中一个任务Job的测试代码。虽然结果不如我的预期，但这种挫败感反而让我平静，让我思索这一切为何反复发生，像一部递归的电影。
现实就是，大部分程序员在其职业生涯中，半数以上的时间都是工作在别人的代码之上的。
相对于写出不可阅读的代码，写出不可测试的代码的情况更常见。
究其原因，问题还是出在测试上。
通过对相关参考书籍走马观花的阅读，我总结了以下两点书中未提及的现象。
纠正认知
在日常生活中，我们作出很多行为，并不需要考虑一个问题：如何测试行为结果是否符合预期？所以我们基本不会把生活中的未知结果，定义为不可测试。
另外一个现实是，我们进入程序员这个行业的时候，首先学会的是如何利用工具创造（软件开发），然后才衍生出如何测试。创造和测试作为两个完全独立的部分被认知，结果就是我们花更多的时间在创造上。
如今软件工程越来越庞大，业务领域越来越复杂，所以如果要将软件开发分解成创造和测试两个部分的话，我觉得在他们各自的投入上应该是五五开。
我看到的很多工程都是在完成需求上花的时间比测试更多，虽然他们声称测试很重要。
如果整个软件构建链条上的所有人员达成了共识，那么就可以借助相关的技术来完成任务。
保持风格统一
让我们再回到代码工程中，软件开发就像写作，你可以在一定的原则下完成创作，既然是创作就有风格问题。
多人协作的项目里，很容易留下开发人员的风格，所以很多团队推出了自己的工程规范，以及代码规范，比如Google Java Style Guide，尽管这些开发人员熟读了《重构 改善既有代码的设计（第2版 ）》这样经典的指导书籍，但风格问题还是会在项目中出现。
当你加入一个项目时，首先要弄清现有工程的风格是什么样的，在重构的过程中尽量避免破坏好的风格，引入自己独特的风格。
总结
回到我的故事，我属于进攻型编程人员，在面对不可测试的的代码时，会让情况变得更糟糕，所以还是反复确认了几个原则:
- 能工作的代码，就尽量不要改善它。
- 在有单元测试的情况下，最小单元修改。
- 不写代码，就不会有BUG。
最后总结：术可以学习，但道却需要领悟。
—— 我是分割线 ——
下面的相关书籍，在开发，测试，重构方面提供了很好指导，值得仔细反复阅读。