复建还是恶梦
重构还是恶梦？
谈到”重构“这两个字，每个软件工程师都会马上想起Matin Flower和他那本经典的”重构“。在那本经典中，Matrin谈到了许多重构的方式，像提取公式函数，重命名，提取父类、接口等。
在本书的试读章节，作者谈的有点和敏捷开发类似的味道。例如小步前进。这种开发方式确实很值得提倡，毕竟一次考虑太多的东西，同时进行，可能会导致每一部分都不够好。
同时，作者在书中提到了重构和测试。这一部分又和TDD有一些类似。如果整个项目中的测试覆盖率比较高，那每次的重构都能得到保障。在每次重构后的测试保证功能的正确。重构中，如果测试不够全面，就会出现和作者书中所说，重构了一次老系统，看似一切完美，但在上线不久，发现已经旧系统中已经解决了的问题，在新的系统中再次出现，而没有完善的文档，没有全面的测试，没有熟悉业务的开发人员。一切的重构会是一个恶梦。
从这一点上，如果能看到关于作者如何解决他提到的这种情况，会是相当不错的，期待。
谈到”重构“这两个字，每个软件工程师都会马上想起Matin Flower和他那本经典的”重构“。在那本经典中，Matrin谈到了许多重构的方式，像提取公式函数，重命名，提取父类、接口等。
在本书的试读章节，作者谈的有点和敏捷开发类似的味道。例如小步前进。这种开发方式确实很值得提倡，毕竟一次考虑太多的东西，同时进行，可能会导致每一部分都不够好。
同时，作者在书中提到了重构和测试。这一部分又和TDD有一些类似。如果整个项目中的测试覆盖率比较高，那每次的重构都能得到保障。在每次重构后的测试保证功能的正确。重构中，如果测试不够全面，就会出现和作者书中所说，重构了一次老系统，看似一切完美，但在上线不久，发现已经旧系统中已经解决了的问题，在新的系统中再次出现，而没有完善的文档，没有全面的测试，没有熟悉业务的开发人员。一切的重构会是一个恶梦。
从这一点上，如果能看到关于作者如何解决他提到的这种情况，会是相当不错的，期待。