重构代码的过程就是发现知识，探索规律的过程。
第一件事情，就是要发现隐藏在泥潭中的各种概念。然后把这些概念意义提炼出来、抽取出来。这个过程犹如发现团队所需要的人才一样。一旦发现某个概念，我们便可以了解到他们能做什么，不能做什么。
第二件事情，就是观察代码在做什么事情，已超过一个屏幕的代码，其中必然蕴含着各种缺陷，当我看到一个超 6 屏的代码时，我就想到一个孤独的程序员，他不愿与别人沟通，不会寻求帮助，他很累，但是他仍然要不断写代码。我所要做的事情就是引导他，让他学会与其他沟通，和别人一起工作。代码也是如此，分析每一个方法的职责，不要让函数越权，然后让适合的类完成恰当的事情。代码才会具有活力，也更容易吸引新的成员加入中。
第三件事情，就是给每一段代码，写多个测试用例以保证代码能够朝着正确的目标前进。正如我们给每个团队成员确立目标一样，有了目标，我们不会迷茫，可以衡量离目标距离。我想这就是测试驱动的精华。给自己的代码确立一个目标，让代码茁壮成长。
但是现实是如此的糟糕。传统的 dao ， service ， action 三层结果过于僵化。在验证业务测试的过程中，我们发现 service 过于强大，以至于每个业务逻辑需要依赖 service ，于此同时 service 又直接依赖于 dao 。使我们无法专心与目标。
于此同时又一个问题浮现在眼前。遗留系统的业务几乎集中在 action 层，系统难以改动，难以吸引新的成员加入。
遇到这些问题，我们怎么做？首先深呼吸一下，浏览代码，你会发现几乎同样的代码散落在各个角落，比如
If(null != id && !””.equals(id.trim()){
//do xxxxxxxxxxxxxxxxxx
}
看到这里，你应该把这个方法提取出来放到 StringUtil 中，并名为 hasText(String str) 并编写一个 testCase ，保证正确。随后替换这些重复代码。这样做之后，你会发现，代码行少了许多，心情也好多了。干劲也更加足。