曾经我已经提出过 O.R.I. 原则。不过不知道什么原因我似乎找不到它了。这份重构原则适用于解决他人代码缺陷的情况，这也是我经常在做的——帮助其他人解决问题的技术顾问。

什么是 O.R.I.

有时候可以理解为 Overwrite, Reference, Interpretation (覆写，参考，解释)，尤其是遇到存在接口的项目，刚性十足的接口改动其方法是非常危险的。因此需要覆写内部方法，参考原始方法，解释新方法存在的理由。
但是我更喜欢将其定义为三个步骤：Opinion, Review, Imitation（观点，审查，模仿）。
对现有项目的不足提出观点，对代码细节进行审查，模仿原始代码再次修改。

观点 Opinion

如果不是从头参与的项目，而是突然被分配到项目组，发现项目是个大粪从而准备好开始重构——其他人肯定会想在你动手之前杀了你。
因此重构前的观点是非常重要的：好的观点才能用于说服其他人。

这些项目变成大粪的原因有较大概率是因为缺乏严格的审查，从而留下了较多技术债未能还清。
因此，是时候提出观点了，梳理项目本该有的架构，然后提供解决方案。但是实际？依然得进行外部审查。

但是，不审查何来的观点？好问题。事实上，观点并不应该从代码出发，这份观点应该是你对这个项目需求的理解，以及现在的解决方案的缺陷的理解。
记住，编写代码的目的是解决问题，而不是编写代码。你的代码是为问题服务的。任何无法解决问题或制造了新的问题的代码理应消失。
以此为基础，提出你的观点，对于项目结构设计的观点，这将会影响你审查与模仿。

审查 Review

就像上面说的，这些技术债很可能是因为没有经过良好审查导致的。那么现在审查的目的是什么？
指出缺陷代码。

技术债是债滚债累计的，尤其是在面向对象语言中，这份技术债随着不断的继承和拓展，刚性语法强大，修正和补丁都只会帮倒忙。

但盲目的根据项目需求重构是绝对不可以的。如果最终项目难以快速达到原有项目的品质，项目组的成员依然会杀了你。
因此，认真审查代码，得到他们的代码的细节。
提取细节与你的观点的差异部分，定向的提出新的观点。如果与你的观点已经完全不着边了，好吧，这种情况太少了，除非这个项目组的人没有一个是真正在写代码的，如果真的遇到了——整个重写吧，不要再去重构了。这已经失去了重构的意义。

模仿 Imitation

重构的价值在于尽可能保证现有架构不变，模仿是很重要的。
如果一个代码里的部分方法没有问题，仅仅只是因为各种原因看起来很脏，那就模仿它，按照你的良好风格重写它。你的风格并非良好？恕我直言，你还没有能力重构代码。

对于任何接口或抽象对象，最好保持原有方法不变，如有必要再新增，但绝对不要直接取消一个方法。如果你确定需要取消一个方法，让他保留至少两个版本，让其他开发者做好跟上你的节奏的准备。
如果亦然决定清扫门户，这可能会导致项目依赖链断在你手上，这将得不偿失。记住，你在重构，不是在重写。

当然，如果你认为一个地方应该需要有抽象，去做吧！提供一个新的抽象构建它。面向维护者编程，面向问题编程，记住这一点，重构后的代码就不至于变成散件；否则，重构后的代码可能在未来的某一时刻需要再度重构，只因为你重构后的代码依然存在较强的刚性和较弱的可维护性。