什么是重构,什么不是重构 - 开源中国社区
Float_left Icon_close
什么是重构,什么不是重构
景德真人 2012年05月14日

什么是重构,什么不是重构

景德真人 景德真人 发布于2012年05月14日 收藏 37 评论 14

做APP,小程序就上开源众包。世界杯期间免费领2600元启动金。>>>  

有时候,会有程序员跑到我这里说他们不喜欢某个东西的设计,“我们需要给它来个全面的重构”,来纠正里面的错误。哦,哦。这听起来可不是个好主意。而且这听起来也不是重构…

重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义,它是

一种修改,使软件的内部结构更容易理解,在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节       制的整理代码、使bug产生几率最小化的方法。

重构的结果是引用了快捷方法、去除了重复代码和死代码,使设计和逻辑更加清晰。是在更好的、更聪明的使用编程语言。是在优势利用你现在知道、但当时的开发程序员并不知道——或并没有加以利用的信息。不断的简化代码,让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。

在这个过程中发现了bug、修改bug,这不是重构。优化不是重构。强化异常捕捉、增加预防性代码不是重构。让代码更容易测试不是重构——尽管重构能达到相同的效果。这些所有的事都是有益的。但这些都不是重构。

程序员,特别是做维护工作的程序员,清理代码是他们的日常工作之一。这是基本工作,是必须要做的。Martin Fowler等人的贡献是使重构代码的最佳实践方法格式化,并把常见的、证明切实有效的重构模式——重构的目标和重构的步骤——进行归档分类。

重构很简单。尽可能在写代码前先写测试能够防止你犯错误。小规模的、独立的、稳妥的对代码进行结构上的调整,每次调整完后都要进行测试,确保你没有改变代码的行为特征——功能和以前一样,只是代码上看着不同。重构模式和现代化的IDE里的重构工具使重构变得容易、安全和代价低廉。

不要为了重构而重构

重构可以被当成一种能给你的代码变更带来帮助的措施。代码重构应该在你进行代码变更前进行,这样能让你确信你对代码理解了,使你更容易、更安全的把变更引入代码。对你的重构动作进行回归测试。然后进行纠正或变更。再次测试。之后可能需要对更多的代码进行重构,使你代码变更的意图变得更加清晰。再次进行全面测试。重构,再变更。或变更,然后重构。

你不是为了重构而重构,你重构是因为你想做其它的事情,而重构能帮助你完成这些事情。

重构的范围应该受你需要实施的代码变更或代码修正来决定——为了让代码变更更安全和更简洁,你应该做些什么?换句话说:不要为了重构而重构。不要对那些你不打算进行变更或不会变更的代码进行重构。

为理解而做简略重构(Scratch Refactoring)

Michael Feather的《Working Effectively with Legacy Code》这本书里提到了简略重构(Scratch Refactoring)的概念;Martin Fowler称之为“为理解而重构”。这是用来对付那些你不理解的(或不能忍受的)代码,清理它们,这样在你打算真正动手修改它前,你能对它们是干什么的有了更好的理解,同样也对你debug这些代码有帮助。一旦你能清楚了一个变量或方法的真正意图,重命名它们,给它们一个更合适的名称,删除那些你不喜欢看的(或觉得没有用的)代码,拆解复杂的条件语句,把长程序分解成数个容易理解的小程序。

不要惦记着复查或测试这些改动。这是为了让你的重构快速的推进——这能让这些代码以及它们的运行原理在你的大脑里产生一个快速但不完备的原型。从中学习,然后丢掉它们。简略重构还能让你尝试各种不同的重构途径,学到更多的重构技巧。Michael Feathers建议说,在这个过程中要留意那些看起来没什么用处、或者特别有用的东西,这样当你完成此练习后、要真正修改它们时,才能把事情做正确——修改时一点一点来,讲究方法,边修改边测试。

什么是“大规模”重构?

对代码进行简单的但又明显的重构:消除重复,修改变量和方法名称使其更有意义,提炼方法使代码更易懂、更易复用,简化条件逻辑,把无意义的数字换成命名的变量,把相似的代码集中到一起。通过这些重构,在代码的可理解性和可维护性上,你能得到巨大的回报。

相对于这些较小的、行内的重构,更加重大的设计上的重构与之有明显差异——这就是Martin Fowler所指的”大型重构”。大的、代价很高的变动,附带有大量的技术风险。这不是你编程过程中的清理代码和设计改进:这是根本性的重新设计。

有些人喜欢把对一个系统的重新设计或重写或重新搭建平台或返工叫“大规模重构”。因为技术上讲,这些并不改变软件功能特征——业务逻辑、软件输入和输出仍和以前一样,“只是”设计和代码实现变了。它和常规重构的区别看起来就是:一个是重写了一段代码,一个是重写了一个系统,只要你是一步一步做下来的,你都可以称之为“重构”——不管你是长年累月被困于将一个老系统换成新代码,还是对系统架构进行大规模的改造

“大规模重构”会变的很糟糕。你可能需要花数周、数月(甚至数年)才能完成,需要你对软件的很多部分进行改动。软件会因此不能运行,需要分多次发布这些变更,需要你做临时的台架(scaffolding)和变通方案——尤其是你采用短周期的敏捷开发方法时。这时Branch by Abstraction这样的实践方法就派上用场了,它能帮你在长周期内管理代码中的变化。

而且在开发新代码的同时你还要维护旧代码,这使得代码版本控制很麻烦,变更起来不方便,致使代码很脆弱,易犯错——这正和重构所预期的目的背道而驰。有时这样的情况会一直持续下去——这种新旧代码交替的过程永远不能完成,因为能获得最大利益的部分都是最先完成,或者因为最初带来这个想法的顾问已经干别的去了,或者是预算被消减,而且你也讨厌维护这样一个拖拉的项目。

这些是重构——那些不是

在这种重型的项目开发过程中混入重构的概念是不对的。它们从根本上就是另外一种工作,带有完全不同的开发成本和风险。它混淆了人们对什么是重构、重构能干什么的认识。

重构可以、也应该融入到你写代码或维护代码的过程中——作为日常开发/质量管理的组成部分,就像写测试和代码审查一样。重构应该被安静的,持续的和低调的完成。它需要我们把工作精力分出一部分给它,它需要在我们的工期评估和风险评估中考虑到它的存在。如果做的正确,你不需要去解释或向外人验证这部分工作。

花几分钟、一两个小时做重构,就像是你开发过程中的一种修改,是工作的一部分。如果它让你花了数天时间,或者更长,那不是重构;那是重写,或重新设计。如果你需要明确的留出一部分时间(或整个sprint周期)来重构代码,如果需要为清理代码而申请批准,或把清理代码作为一个开发需求,那你不是在重构——即使你用了重构的技术和工具,你仍然做的是另外一种工作。

有些程序员认为对代码进行根本的、重大的修改是他们的权利和义务,在重构的名义下进行重新设计、重写,为了将来,也不辜负自己的技艺。重新设计和重写有时候是你正确的该做的事情。但出于坦诚和表述清楚,请不要把这些活动赋以重构的名义。

[本文英文原文链接:What Refactoring is, and what it isn’t ]

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:什么是重构,什么不是重构
分享
评论(14)
最新评论
0
为了实际需要的重构才是好重构。
0
推倒重写
0

引用来自“xoHome”的评论

不知道为什么,总有人非要为某些平常的事件下一个标准的定义。重构是开发过程中必不可少的一环,每个人或多或少都经历过,这是开发过程中的一个普通过程而已,难道非要下个严格的标准来衡量区分? 规则已经够多了,有必要再给自己加一道枷锁? 至于严格标准带来的所谓提高,能觉悟到的自己会去区分,觉悟不到的看了也没用,只会增加学习成本! 我是这样认为。

软件工程这么多年的发展,伴随了太多方法和定义的不断演化,可能正是因为某个方法或定义的引入,才出现了后来大多数程序员们心照不宣的一些常识和流程吧
0
mark
0

引用来自“xoHome”的评论

不知道为什么,总有人非要为某些平常的事件下一个标准的定义。重构是开发过程中必不可少的一环,每个人或多或少都经历过,这是开发过程中的一个普通过程而已,难道非要下个严格的标准来衡量区分? 规则已经够多了,有必要再给自己加一道枷锁? 至于严格标准带来的所谓提高,能觉悟到的自己会去区分,觉悟不到的看了也没用,只会增加学习成本! 我是这样认为。

把概念、范围明确是必要的,要不然将变得不可控,做的事越多,问题反而越多,因为把太多东西夹杂在一起了。而且太多的人,随便拿概念来忽悠
0
拒绝重构
0
技术管理中有很多伪科学,特别是那些让人看不明白的虚头巴脑管理概念、框架、体系,因为它们从来无法深入人心,从来无法得到有效执行。
重构,只要做到能够使开发阶段Hack出来的代码更具备逻辑性、可读性就OK了。弄那么多虚的......
0

引用来自“delphixp”的评论

除了加法交换律之外,人们发现乘法也满足交换律。。。再接着发现某些几何变换也满足交换律。。。于是将前面的“加法”,“乘法”这些算符去掉,抽象为“交换律”。。接着就出现了满足交换律的群,定义为交换群。。。为什么西方能够将科学发展到今天这样庞大。。这跟他们的这种思维方式有非常大的关系。。

nice
0
不喜欢这种划定定义的规范,很多时候已经是分不清是重构还是优化,当我们在做优化工作的时候,做着做着就变成了重构,你能说什么?
0
好文章! Cheers!
0
对于重构的定义明显是一道简答题,不是算术题。简答题的答案并没有完全一样上的标准,大体遵循定义结合自己的经验来做其实就是重构。李小龙创建截拳道是结合自身长处与武术的套路来的,所以我们没有必要完全被固定在截拳道这个名词上。欢迎吐槽
0
除了加法交换律之外,人们发现乘法也满足交换律。。。再接着发现某些几何变换也满足交换律。。。于是将前面的“加法”,“乘法”这些算符去掉,抽象为“交换律”。。接着就出现了满足交换律的群,定义为交换群。。。为什么西方能够将科学发展到今天这样庞大。。这跟他们的这种思维方式有非常大的关系。。
0

引用来自“xoHome”的评论

不知道为什么,总有人非要为某些平常的事件下一个标准的定义。重构是开发过程中必不可少的一环,每个人或多或少都经历过,这是开发过程中的一个普通过程而已,难道非要下个严格的标准来衡量区分? 规则已经够多了,有必要再给自己加一道枷锁? 至于严格标准带来的所谓提高,能觉悟到的自己会去区分,觉悟不到的看了也没用,只会增加学习成本! 我是这样认为。

但事实上,有很多人并不会有意识去做。。。就好象,我们为什么要创建“加法交换律”这名词呢?。。算多了,大家也明白了。。
0
不知道为什么,总有人非要为某些平常的事件下一个标准的定义。重构是开发过程中必不可少的一环,每个人或多或少都经历过,这是开发过程中的一个普通过程而已,难道非要下个严格的标准来衡量区分? 规则已经够多了,有必要再给自己加一道枷锁? 至于严格标准带来的所谓提高,能觉悟到的自己会去区分,觉悟不到的看了也没用,只会增加学习成本! 我是这样认为。
顶部