代码重构原则：O.R.I.

O.R.I.**

展开意指 Organize the code, Rewrite the code, and Ignite the code （组织代码，重写代码，燃烧代码）。

一个项目以任何原因决定重构，但如果项目是已经上线/发布，完全重构会对玩家造成影响，那么重构时就要多方面考虑。

因此，我为我自己定义了 O.R.I. 原则，确保在最小影响下最高效率重构代码。

Organize the code

组织代码，亦或者称为分析代码。重审我们的需求，想清楚一些问题：我们为什么要重构，我们重构的最终目的是什么，我们重构的次要目的是什么，我们要从哪里开始重构可以达到不会造成过大影响。

想清楚这些问题，对症下药，找到重构点，开始清理代码。

首先提高代码可读性：开始构建一个项目时总是会以速度优先，这是任何项目开发中通用的原则。但是速度优先通常会带来一些技术债：低可读性与低性能。既然要重构，自然要先从可读性开始入爪。性能不是最重要的，因为在提高可读性的同时性能也会相对的被提高… 除非是低效率的重构，重构前与重构后的区别仅仅只是把Bug修了。

语法糖不应滥用，不要太吝啬一点点的性能。局部变量的生命周期会在方法结束后结束，因此不要害怕变量变多。这里也引出一个重点：不要把代码全部放入一个方法，也不要把代码的嵌套堆叠成山。

让局部变量在该去死的时候去死，让他消失。将你的一个方法拆分成多个方法，参数仅传入必要的成员，其他的使用局部变量运算并持有即可。

Rewrite the code

了解了重构点，也了解了应该怎么重构，现在开始重写方法。

不要害怕打破——如果代码确实复杂到令人望而生畏，不妨从嵌套最深层开始分支方法以及去if化。去if化是很多提高代码可读性教学中经常会提到的，即便如此也依然有很多开发者不太会掌握这个。没关系，只需要记住一点：能反转运算并提前返回的，就不要再去嵌套它。对cpu来说这无所谓，但对你的大脑来说，这非常有所谓。你的大脑需要知道应该从哪开始跳过代码，而不是慢慢看这个括号对应的另一个在哪。 分支方法时，不妨尝试小黄鸭调试法——解释你的代码。通过解释代码来确定方法名，当你的if下全是阐述方法功能的方法调用时，现在你的重构工程就比刚才的压力小了一大半，不是吗？ 现在，再来开始尝试去掉那么多嵌套，整理代码，善用Utils整理你的代码，最后你就能得到一份干净的，没有那么多嵌套的代码。

Ignite the code

如果代码又多又杂，而硬上有一定会自造兼容性问题，那就是时候点燃代码了。

开一个新的页面，复刻你的代码。不要复制黏贴，用手打。一边打一边解释自己的代码，如果你觉得一段代码可以分支到单独的方法中，那就这么做吧。最后就能找出全部细节问题，同时重构你的代码，这也算得上是一种相较于与代码肉搏更有效率的重构方法。

尝试 O.R.I. 重构代码，每一次重构都是一次学习。