两年后再次翻阅《重构》，感觉很多手法已经很自然的融入到平时的开发之中。而平时开发中有时犹豫不决的地方，在《重构》里正好有最佳解决方案，看来还是温书太少。
有一点，不知道别人会否和我一样想，世事无绝对，比如书里提到消灭switch, 我曾经对一段简单的代码采用remove switch with state and polymorphism， 但是实在感觉那么简单的一个class没必要又抽象出N个子类和方法的多态实现，如此去处理，感觉反而不好维护不好理解。我担心会不会有时候别人指着书对着我的代码说“嘿，按重构手法，这里应该这样改...”，要知道系统总是会有很多trade-off,比如简单编码，效率，代码所有权等等，未必是按照重构手法就是最优的解决方案，书里面也提到了，先重构了碰到效率等问题的时候以后再调整，要知道有可能那段代码已经是trade-off之后的产物。
顺便提一点当前手上碰到的一个很难进行重构的场景：项目已经进入维护阶段，客户的需求是分批来，但是后来的需求可能很紧急需要比先到的需求提前发布，所以项目经理采用了版本控制“基线+分支”的方式，我在某个分支上如果做了重构，每次将分支合并到基线上去的时候简直是莫大的痛苦，而且很容易出错，而其它正在开发的分支以后再合并的时候又要痛苦一次。有时候会放弃重构，感觉就象是看着代码在慢性死亡。
还有个疑问：喜欢重构的人的家里面是一番什么样子呢？一个喜欢代码干净利落的人，会不会忍受自己家里面东西乱摆乱放象个狗窝样呢？至少我不太喜欢那个样子。
