重构是 一种对软件进行修改的行为，但它并不改变软件的功能特征，而是通过让软件程序更清晰，更简洁和更条理来改进软件的质量。代码重构之于软件，相当于结构修改 之于散文。每次人们对如何对代码进行重构的讨论就像是讨论如果对一篇文学作品进行修订一样无休无止。所有人都知道应该根据项目的自身情况来对代码进行重 构，而重构是无止境的。莫扎特从来不不对他的作品进行修订，特罗洛普对自己作品修订的恰到好处，大多数作家认为他们俩这样做都是合适的，但他们的合适对于 你我来说未必是合适的。
最常见的基本重构方法 可以归纳为两个方向。通过归纳方法将一个长的过程分解为小的可以重用的组件，和通过内联(inline)方法来消除那些不够份量的小方法。我们可以提炼方法来让大量的子类共享相同的功能特征，我们可以下放方法来让只有用到这些功能的子类才知道它们的存在。重构就是爬山，通过一步一步的小的提高来逐渐的改进整体的质量，但在重构时，我们如何知道哪种方法是上山的正确道路？文章源自运维生存时间-https://www.ttlsa.com/web/refactoring-direction-guiding-principles/
关于代码地形学的这个问题公认的方法有两种。去除有异味的代码和重构成模式。 如果能做到这样，当然是很好的。就像是纠正作文里的一个语法错误或不恰当的比喻。如果我们可以找到这些四处隐藏的有异味的代码，将它们重写成整洁的，条理 的，结构化的形式，何乐而不为。但这些都是特殊情况。如果没有明显的模式来重构，或没有很直接的方法来去除代码异味，那该怎么办呢？文章源自运维生存时间-https://www.ttlsa.com/web/refactoring-direction-guiding-principles/
这才是 我们如今编程艺术的中心问题，而很少人讨论这些。通常我们讨论这些问题时都是罗列出更多更长的有异味的代码模式的清单，但这并不是解决问题的方法。代码异 味应该是我们公认的不好的东西，而不是那些置之不理也无妨的事情。我们经常会说到老板不给我们重构的机会，甚至代码有明显的异味，老板们认为这是浪费时 间。并不是每个人都有懂软件的老板。我很吃惊为什么只有很少的讨论谈到点子上。。也许我这篇文章才说到问题关键处。文章源自运维生存时间-https://www.ttlsa.com/web/refactoring-direction-guiding-principles/
我的观点，当重构没有现成的明显的方向时，我们可以遵循下面的原则：
1. 当属性、方法或类存在任何的需要复用的意向时，归纳提炼它们。
2. 不要低估小方法对代码整洁的作用。使用小方法能让你节省很多笔墨。
3. 能让代码长度变短的提炼都应该去提炼，包括注释。
4. 用switch()代替多形——即使这样做会使代码变长。
5. 用封装控制可见度。
6. 消除依赖。
7. 简化构造方法——即使这样做会使代码变复杂。
8. 封装或避免条件表达式。使用guard语句，避免使用else语句。
9. 使用常量代替魔幻数字。
10. 不确定时，偏向使用组合而不是继承。
11. 不确定时，将计算操作移入到这些数据的所有者对象里，或将数据移动到执行计算操作的对象里(也就是迪米特法则(Law of Demeter))。
12. 使用小对象，松耦合，避免大对象，高聚合。
13. 不确定时，偏向使用递归而不是循环。
14. 使用代理对象，模拟对象和辅助对象来隔离网络，数据库，文件和用户接口。
15. 不确定时，尽量在model里添加代码，必要时才往controler添加代码。view里添加的都应该是便捷功能和简写方法，但不要局限于此。
16. 偏向使用apply, each, mapcar，而不是loop.
17. 尽量使用新技术。文章源自运维生存时间-https://www.ttlsa.com/web/refactoring-direction-guiding-principles/
文章源自运维生存时间-https://www.ttlsa.com/web/refactoring-direction-guiding-principles/
评论