重构

在应用程序的整个生命周期中，我们够可以使用重构。
持续学习使我们经常听到的一句话，这句话也非常试用于重构。例如重构可以获得更好的模型
重构是一步步的执行小的，众所周知的变更，以改变现有代码的设计，既不改变显性的行为的情况获得可维护性质。换句话说就是：改变方式，但不改变内容

简单地说重构就是把糟糕的代码转化为良好的，可维护的代码，就是这么简单，因此我们不必在前期就给出一个完美的架构或者答案。这是一个好消息，因为无论我们如何设计都不会达到完美的状态(可以证明吗？)。

我们在识别糟糕的代码方面几乎人人都是高手，没有问题，但是重点在于如何修复他。在我看来应该在一发现问题之后就立马进行处理，我们应该使用重构。因为如果不对代码进行持续维护，那么他将退化和崩溃，就像房子一样的。如果在bug修复和功能扩展期间如果不使用重构，那么可以想象在不远的将来将会发生什么情况。所以理解软件的生命周期很重要，能够在更高的层次掌握软件开发的核心。尘封不动的代码将滋生bug

如何使用重构

正如文章开头的第一句话所说，在软件开发的整个生命周期中都可以使用重构。假如我们不使用重构，而沿用前期的，传统的设计为重点的过程方法，我们在初始化详细设计阶段反复琢磨，花费大量时间，创建大量的UML，作为结果我们希望在后期的软件开发中过程会变得很顺利和快速，但即使是这样，代码还是会有变得很糟糕的风险。

相反我们应该接受这样一个事实，我们不可能在一开始就设计的很完美正确，另一种略微不同的方法是将一些工作从初始详细设计阶段转移到开发过程中去（这种情况所有的开发人员都是设计人员），并且准备好持续学习，当了解到更多的内容的时候进行持续的重构，在我们开发的过程中，我们会学习到更多的东西，此时进行重构的设计，会做的更正确，也的确符合我们日常开发的模式，所以重构的使用很重要。
因此，与其进行更多的推测的详细设计，不如进行更多的学习和验证，并反复重构

1. 重构 + TDD = 事实

为了安全的重构，我们必须执行全面的测试，如果不这样做，这将会引入bug。
使用TDD+重构来修复bug是一张好的思想，首先是红色的来暴露bug，然后修复bug成为绿色，然后重构就算是成功了。

最后：领域模型DDD非常适合TDD