### 现实的检验（再论） 如果要让软件开发者接受重构，首先必须解决一些非常实际的问题。下面列出四个最常见的问题： - 程序员不知道如何重构。 - 如果重构利益是长远的，何必现在付出这些努力呢？长远看来，说不定当项目收获这些利益时，你已经不在职位上了。 - 代码重构是一项额外工作，老板付钱给程序员，主要是为了编写新功能。 - 重构可能破坏现有程序。 本章中我简单回答了这些问题，并为那些希望更深入钻研的人指出方向。 对于某些项目，以下问题也是需要关心的： - 如果代码由多位程序员共同拥有，怎么办？ 一方面，许多传统的变更管理机制都可以解决这个问题；另一方面，如果软件设计良好，又经过重构，子系统之间就会有效分离，于是很多重构手法都只会影响代码的一小部分。 - 如果你的code base （代码材料库〕中有多重版本的代码，怎么办？有些时候， 重构和每一个版本相关，这种情况下我们必须在重构前先对所有版本进行安全测试。另一些时候，重构可能只与某些版本相关，那么，检查过程和重构过程就简单多了。如果打算同时管理多个版本变化，通常需要使用许多传统的版本管理技术。如果想将多个版本并入一个新的code base （代码材料库）中，重构也会有所帮助，因为它可以顺畅地简化版本控制工作。 总而言之，「让软件开发者相信重构的实际价值」和「让博士论文评议委员会相信重构研究够得上博士水平」是完全不同的两码事。在写完毕业论文以后，我又花了相当长的时间才对这种差异有了足够充分的认识。