重构系列谈（一）重构时机的把握

重构系列谈（一）重构时机的把握

重构是一种在不改变软件系统外在行为的前提下，优化代码内部质量的方法，使得代码易于复用、易于理解、减少冗余，从而使软件实现的复杂度逼近于软件要解决问题的复杂度，降低理解和维护成本。

重构的时机一般从以下两个角度考虑：

1、缺失clean code

软件是对业务逻辑的一种表述，代码中的变量、类型、函数等所有代码元素都应该能够显式的、合理的表达业务逻辑，代码中如果出现了晦涩的命名、无序的排版、超高的圈复杂度、高低不平的语义（概要和细节不合理的同时存在，代码应该像英文的文章一样，按topic、brief、detail逐步展开，而不是三者无序混合杂乱，造成粗细粒度的语句杂乱无章的堆砌）、以及常提的22种坏味道等，这些都是要进行clean code层级的重构，增加代码的可理解性，降低维护成本。

    当需求变化方向发生变化时，就会导致系统原来的架构与新需求变化方向不匹配，这时候如果不能及时重构系统架构，开发人员往往通过大锤+铁钉

（if else套if else等）的方式，强行把新功能加上去，副作用就是功能正常了，但这些功能的代码出现在不该出现的位置上，久而久之系统架构就会被需求方向变化冲击的七零八落，造成系统的逐步腐化，形成一团乱麻。

但是这里又面临了一个新的问题，那就是对于预测到需求方向要不要做架构（OCP）上的应对呢？如果提前应对了，需求没有往这个方向变化，或者的确变化了，但变化的角度不同了，这不造成了过度设计了吗？

所谓的架构应对一般是指对OCP（开闭原则）的应用，把稳定部分和变化部分相分离，稳定部分复用，变化部分通过扩展来实现。

其实，提前预测需求变化方向并做架构（OCP）上的应对，是会在未来需求变化时带来一些收益，但是我们往往发现，我们预测的变化往往很长时间都不变化，或者即使变化，变化的角度也和之前的预先设计不同，原来的设计还是要做大的调整，反而往往增加了重构的复杂度。这样总体看，提前设计往往都带来更多的浪费。

如何均衡设计和需求方向的变化呢？这里老乐推荐0/1/N原则。

如果预测到需求变化的方向，但是这时候需求还没有真正发生，这时候就是0，除非实现已有需求的时候顺带能够实现一些未来需求，比如有个核心业务数据类型目前是int，未来有可能演变为double，那现在是否要使用double处理呢？

如果需求变化方向出现了第一次，这时候不要做过多的架构（OCP）设计，仅仅一般实现就可以了，这个需求变化方向还不明显，因此过多的架构一定会带来理解性和维护性的成本，这就是1。

如果需求在这个方向上变化了第二次，这个时候就不能仅仅实现一个2，而应该做架构（OCP）设计，使这个设计能够应对2,3,4…N，能够应对这个需求变化方向上所有的变化。因为这个时候需求方向已经明确，后续变化概率会较大，而且已经有两次变化了，此时做架构（OCP）去应对是值得的了，这就是N。