重构原则2.4-2.6

2.4：

对项目经理描述重构的问题的话，如果是懂技术的项目经理，可以很好的沟通；对于只关注质量，那么可以在代码复审中引入重构。

如果项目经理是“进度驱动”的话，可以不告诉项目经理重构的事情，作为专业人士，可以自己在代码的开发过程中，使用重构的技术。

2.5

重构有其的局限性，但是刚学习这门技术的时候，我们很难觉察到她的局限性。因此我们可以尝试着使用重构的技术，但是更多的时候，要注意时刻监控重构可能引起的问题，然后找到更加合适的重构方式。

数据库是重构中的一大难题，因为数据库会和业务逻辑以及代码紧密的结合在一起。然后是数据迁移，这个时候需最好在系统中插入中间层，以保持系统的灵活性。

修改接口是重构中非常需要注意的问题，java代码中，如果是已经发布的接口，最好的方式是同时提供新旧的两个接口，让旧接口调用新接口。这样的话对系统的影响最小。

或者可以通过结对编程的方式，使得对接的双方可以修改对方的代码，尽量减少接口的发布。

自定义异常基类，然后再我们的接口中约定，只对外抛出那个基类的子类，这样子对方在做代码开发的时候永远就会知道捕获那个基类异常则可以了。

何时不该重构是个比较难以界定的问题。一般来说，系统重构前，代码必须大部分功能都是通的才最好。

2.6

重构和设计是互补的，如果没有重构，需要保证预先的设计准确无误，这个对设计的要求太高，很难达到，而且代价也太大，不合适。

重构可以让设计变得简单，而且充满了灵活性。