代码重构应遵循的若干原则

4顶
1踩

2013-10-21 10:36 by 副主编 WnouM 评论(8) 有9772人浏览

代码重构编程原则经验

重构是一种对软件进行修改的行为，但它并不改变软件的功能特征，而是通过让软件程序更清晰，更简洁和更条理来改进软件的质量。代码重构之于软件，相当于结构修改之于散文。每次人们对如何对代码进行重构的讨论就像是讨论如果对一篇文学作品进行修订一样无休无止。所有人都知道应该根据项目的自身情况来对代码进行重构，而重构是无止境的。莫扎特从来不不对他的作品进行修订，特罗洛普对自己作品修订的恰到好处，大多数作家认为他们俩这样做都是合适的，但他们的合适对于你我来说未必是合适的。

最常见的基本重构方法可以归纳为两个方向：

通过归纳方法将一个长的过程分解为小的可以重用的组件；
通过内联(inline)方法来消除那些不够份量的小方法。

我们可以提炼方法来让大量的子类共享相同的功能特征，我们可以下放方法来让只有用到这些功能的子类才知道它们的存在。重构就是爬山，通过一步一步的小的提高来逐渐的改进整体的质量，但在重构时，我们如何知道哪种方法是上山的正确道路？

关于代码地形学的这个问题公认的方法有两种——去除有异味的代码和重构成模式。如果能做到这样，当然是很好的。就像是纠正作文里的一个语法错误或不恰当的比喻。如果我们可以找到这些四处隐藏的有异味的代码，将它们重写成整洁的，条理的，结构化的形式，何乐而不为。但这些都是特殊情况。如果没有明显的模式来重构，或没有很直接的方法来去除代码异味，那该怎么办呢？

这才是我们如今编程艺术的中心问题，而很少人讨论这些。通常我们讨论这些问题时都是罗列出更多更长的有异味的代码模式的清单，但这并不是解决问题的方法。代码异味应该是我们公认的不好的东西，而不是那些置之不理也无妨的事情。我们经常会说到老板不给我们重构的机会，甚至代码有明显的异味，老板们认为这是浪费时间。并不是每个人都有懂软件的老板。我很吃惊为什么只有很少的讨论谈到点子上。也许我这篇文章才说到问题关键处。

我的观点，当重构没有现成的明显的方向时，我们可以遵循下面的原则：

当属性、方法或类存在任何的需要复用的意向时，归纳提炼它们。
不要低估小方法对代码整洁的作用。使用小方法能让你节省很多笔墨。
能让代码长度变短的提炼都应该去提炼，包括注释。
用多形代替switch()——即使这样做会使代码变长。
用封装控制可见度。
消除依赖。
简化构造方法——即使这样做会使代码变复杂。
封装或避免条件表达式。使用guard语句，避免使用else语句。
使用常量代替魔术数字。
不确定时，偏向使用组合而不是继承。
不确定时，将计算操作移入到这些数据的所有者对象里，或将数据移动到执行计算操作的对象里（也就是迪米特法则(Law of Demeter)）。
使用小对象，松耦合，避免大对象，高聚合。
不确定时，偏向使用递归而不是循环。
使用代理对象，模拟对象和辅助对象来隔离网络，数据库，文件和用户接口。
不确定时，尽量在model里添加代码，必要时才往controler添加代码。view里添加的都应该是便捷功能和简写方法，但不要局限于此。
偏向使用apply, each, mapcar，而不是loop。
尽量使用新技术。

英文原文：Hill Climbing (Wonkish) / 译文：外刊IT评论

来自: 外刊IT评论

分享到：

4
顶

1
踩

评论共 8 条请登录后发表评论

8 楼 dohkoos 2013-11-21 10:11

在重构时，我们如何知道哪种方法是上山的正确道路？关于这个问题公认的方法有两种——去除有异味的代码和重构成模式。

7 楼 sky10198866 2013-10-23 16:16

我更看中的是重用性、移植性、维护性。

6 楼 netkiller.github.com 2013-10-23 12:59

说的很好听，中国企业人流量巨大，一批又一批，一轮又一轮。
后面来的人说前面写的是垃圾，后面接手的人根本不敢用前面人留下的代码。

5 楼 clxy 2013-10-22 19:38

runshine 写道

clxy 写道

虽然不同意下面几个

》不确定时，偏向使用递归而不是循环。
递归比较反人类，且开销大，不是好选择。

我到觉得递归更接近人类对问题思考的方式。
有种递归叫尾递归，配合出色的编译技术，空间效率等于循环。
特别是文中提到“apply, each, mapcar”，感觉像是在说LISP或Haskell？那就更是只有递归没有循环了...
可是前文又像在说一些OO的东西...搞不明白原文作者的上下文是什么

唔...我觉得我们的“觉得”不一样，哈哈。
“尾递归”学习了！多谢了。

4 楼 runshine 2013-10-22 19:05

clxy 写道

虽然不同意下面几个

》不确定时，偏向使用递归而不是循环。
递归比较反人类，且开销大，不是好选择。

3 楼 clxy 2013-10-21 20:28

好赞！用于确定不确定时该如何做才是完全之策。

虽然不同意下面几个

》不确定时，偏向使用递归而不是循环。
递归比较反人类，且开销大，不是好选择。

》尽量使用新技术
初期调研时应该如此，后期要尽量避免新技术。
好多项目灾难都是由于技术过于超前...

2 楼 white_crucifix 2013-10-21 18:44

重构最重要的一点是要让自己看着爽……别人爽不爽就~~再说了，呵呵呵呵呵

1 楼云中苍月 2013-10-21 13:46

绝大多数的代码都是无模式的，所以这些小原则很有用，在遵循原则的过程中需要作出取舍，生搬硬套只会让自己很累。

发表评论

您还没有登录,请您登录后再发表评论

4顶1踩