某厂老板曾送我这本书，并对我说：“这应该是你看的最后一本技术书”，很可惜的是，我后来又看了很多技术的书，没能如他所愿完全转向管理和产品。

《重构》这本书，介绍了一套非常实用的方法论。里面有几点我记忆尤深：

从上面这三条，我们可以看出，重构实际上是一种应对需求变更的方法论，所以也是解决所谓“软件危机”最重要的方法论。《重构》着重于在代码维护过程中，逐步的建立符合需求的模型。这是一种非常踏实的态度，避免了过度设计。

在后来我学习的《领域驱动开发》中，重构也作为一个非常重要的部分被反复提及。虽然领域建模有大量叙述并没确定，建模应该在何时进行，但伴随需求变更的模型修改是肯定的。

当然，这边经典著作肯定不止上面我说的这三条道理，里面包含了很多可以操作的重构技巧和重要的观念。就算你没有“设计模式”的技术知识，也能读懂，但如果你很熟悉设计模式，那么会感觉这本书，给你指明了一条路：何时、如何把代码应用上设计模式。

关于测试驱动开发，网上有很多的讨论。我觉得要真正的施行，是有条件的：

关于敏捷开发，可以说是“测试驱动开发”的配套项目管理方法。这个方法主要解决的问题，并不是单一软件版本的开发速度问题，而是整个软件产品的设计准确度问题，简单来说，就是很多时候客户自己都没想明白产品应该有啥功能。这在互联网产品、游戏领域是非常常见的情况，但在通信、金融这些领域却不太常见。

由于需要反复多次的构建“原型”产品，所以软件代码必然经历非常多的“需求变更”，为了解决高频率的代码修改，重构的方法显然是必须要掌握的，而自动化测试用例，则是这些修改的“安全网”，防止一顿修改后，很多原来需要保留的特性都出问题了。而新加特性的测试用例，除了用来“程序化”需求内容，同时也会积累下来成为下一个原型的保障。所以“敏捷”开发模式，节省的是“纸上谈兵”的需求讨论过程，而代价是增加了很多原型尝试和测试用例编写的时间——这并不能在短期内加速软件开发过程，而是避免因为需求理解错误导致的巨大的开发时间浪费。（有一些半吊子喜欢用“敏捷”作为说辞来推动软件项目早日完工，完全就是南辕北辙）

从工具化、自动化的角度来看，通过程序来检验程序，是代替手工操作的一次重大转变，也是软件工程中提高效率的主要思想。一切不能进行自动化测试的工作，本质都是低效和易错的，发布构建过程、运维部署过程、运营活动操作，这些统统都应该做成可以自动化测试的。