代码重构的原则以及要考虑的问题（持续更新）

0.重复代码是万恶之源，消除重复代码。 

1.软件开发的时候会持续面对两类问题，重构和新功能开发，保证这两个行为的互斥性，在功能开发的时候，不要重构，通过升级测试用例衡量你的功能开发进度。在重构的时候，只管改变程序结构，不要添加新的功能，并锁定你的测试用例，重构的结果是在相同的用例集上对齐之前的测试结论，而不是让测试结果变得更好（更好，说明代码原本存在不确定性因素）或者更差(说明重构导致回归了）。

代码持续迭代的时候，你可以能一会儿在做重构的事情，一会儿在做新功能开发的事情，不断交替，但是没关系，时刻知道你在做哪件事情，而不是两个都在做。

2.重构在前，优化在后，不过早优化，重构时不要过于担心框架对性能的影响，优化的时候才需要考虑这一点，因为重构结束的时候，新框架已经使你处于一个优化有利的位置了，总之，先最对的，在做好的。

3.不要再一个模块（类，源文件）中频繁用另一个模块的属性（变量，对象）做判断，分支，switch等等，如果不得不使用，将其移到所属模块或者源文件，在模块自己的数据上使用，而不是在别人的模块上使用。

4.提炼公共逻辑，找到代码的公共逻辑泥团，将其提炼独立出来，使其可复用，可维护，方便扩展。

5.方便人去理解而不是机器，尽可能地使用简单的设计来解决问题。

6.如果一个函数使用了来在其它模块的变量，对象或者类型，要立刻想到这个函数是否放错了位置，大部分情况下，函数应该放到它所使用的数据所属的类，源码文件，或者模块定义中。

7.删减临时变量，临时变量传来传去，会使代码的可读性变差，找到初始化这些临时变量公共逻辑，抽取提炼出来封装为函数，这样不但减少代码行数，也能提高复用性。

8.尽量控制变化带来的影响在最小范围，如果是C，就控制在一个编译单元（源文件）内或者函数内，如果是C++，就控制在类内部。

9.A和B没有逻辑上的关系，就不要让它们发生事实上的直接联系，A的改动不应该是导致B改动的原因。

10.避免重复，代码中避免出现重复的逻辑和代码片段，尽可能将通用的代码封装成函数或类，以提高代码的重用性和可维护性。

11.SRP（Single Responsibility Principle）单一职责原则：一个类或函数只负责一件事情，避免过于复杂的实现，提高代码的可读性和可维护性。

12.OCP（Open/Closed Principle）开闭原则：软件实体应该对扩展开放，对修改关闭。尽量通过扩展来实现新功能，而不是修改原有代码。

13.LSP（Liskov Substitution Principle）里氏替换原则：子类必须能够替换它们的基类，而不会影响程序的正确性。即子类在实现父类的方法时，不能改变方法的输入输出和抛出异常等。

14.ISP（Interface Segregati