重构代码的7个阶段

标签: 杂项资源 Coding Programmer Refactory 程序员 | 发表时间:2011-08-16 08:42 | 作者:陈皓 风子
出处:http://coolshell.cn

你曾去想重构一个很老的模块,但是你只看了一眼你就恶心极了。文档,奇怪的函数和类的命名,等等,整个模块就像一个带着脚镣的衣衫褴褛的人,虽然能走,但是其已经让人感到很不舒服。面对这种情况,真正的程序员会是不会认输的,他们会接受挑战认真分析,那怕重写也在所不惜。最终那个模块会被他们重构,就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段,文章来自:The 7 stages of refactoring,下面的翻译只是意译。

第一阶段 - 绝望

在你开始去查看你想要重构的模块的,你会觉得好像很简单,这里需要改一个类,那里需要改两到三个函数,重写几个函数,看上去没什么大不了的,一两天就搞定了。于是你着手开始重构,然后当你调整重构了一些代码,比如改了一些命名,修理了一些逻辑,渐渐地,你会发现这个怪物原来体型这么大,你会看到与代码不符甚至含糊不清的注释,完全摸不着头脑的数据结构,还有一些看似不需要方法被调了几次,你还会发现无法搞清一个函数调用链上的逻辑。你感到这个事可能一周都搞不定,你开始绝望了。

第二阶段 – 找最简单的做

你承认你要重构的这个模块就是一个可怕的怪物,不是一两下就可以搞定的,于是你开始着干一些简单的事,比如重新命名一下几个函数,移除一些代码的阻碍,产生几个常量来消除magic number,等等,你知道这样做至少不会让代码变得更糟糕。

第三阶段 – 再次绝望

但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事,改正这些事完全于事无补,你应该要做的事就是重写所有的东西。但是你却没有时间这么干,而这些代码剪不乱理还乱,耦合得太多,让你再一次绝望。所以,你只能部分重写那些不会花太多时间的部分,这样至少可以让这些老的代码能被更多的重用。虽然不完美,但是至少可以试试。

第四阶段 – 开始乐观

在你试着部分重构这个模块几天之后,随着重构了几个单元后,虽然你发现改善代码的进度太慢了,但此时,你已知道代码应该要被改成什么样,你在痛苦之后也锁定了那些那修改的类。是的,虽然你的时间预算已经超支,虽然要干的事比较多,但你还是充满希望,觉得那是值得的。你胸中的那团火又被点燃了。

第五阶段  - 快速了结

在这个时候,你发现你已花了太多的时间,而情况越来越复杂,你感到你所面对的情况越来越让你越到不安,你明白你自己已经陷入了困境。你原本以为只需要一次简单的重构,然而现在你要面对的是重写所有的东西。你开始意识到原因是因为你是一个完美主义者,你想让代码变得完美。于是你开始在怠慢你文档,并想找到一个捷径来重写老的代码,你开始采用一些简单而粗暴,快速而有点肮脏的方法。虽然不是很完美,但你就是这样去做了。然后,你开始运行测试做UT,发现UT报告上全是红色,几乎全都失败了,你恐慌了,于是快速地fix代码,然后让UT 能工作。此时,你拍拍自己胸口,说到,没问题 ,于是就把代码提交了。

第六阶段 – 修改大量的Bug

你的重写并不完美,虽然其过了测试,但是那些UT测试对于你的新的代码有点不太合适,虽然他们都没有报错,但是他们测试得范围太小了,没有覆盖到所有的情况和边界。所以,在这以后,你还需要几周或是更长的时间不得不来修正越来越多的bug,这使得你的设计和代码在每一次quick-fix后就变得越来越难看。此时,代码已经不像你所期望的那样完美了,但你依然觉得他还是比一开始要好一些。这个阶段可能历经几个月。

第七阶段  - 觉悟

经过了6个月,你重写的模块又出了一个比较严重的bug。这让你重构的那个模块变得更难堪。你发现出的这个问题是和当初的设计不一致,你还发现被你重构掉的那段老的代码并不是当初看上去的那么坏,那段老的代码确实考虑到了一些你未曾考虑到的事情。这个时候,你团队里有人站出来说这个模块应该被重构或是重写,而你却不动声色地一言不发,并希望那个站出来的人能在几个月后能觉悟起来。

——————

不知道这是不是你的经历,我经历过很多次这样的事。对于很多维护性质的项目,我犯过的错误让我成了一个实实在在的保守派,我几乎不敢动,那怕看到代码很不合口味。当然,那些从来没有写过代码的敏捷咨询师一定会说用TDD或是UT可以让你的重构更有效也更容易,因为这样会让他们显得更我价值,但我想告诉你,这种脱离实际的说法很不负责任,这就好比说—— 我在杀猪的时候遇到了一些麻烦,因为我对猪的生理结构不清楚,或是这本来就是一头畸形的猪,导致我杀的猪很难看,而伟大的敏捷咨询师却告诉我,要用一把更快更漂亮的刀。软件开发永远不是那么简单的事,杀猪也一样。

相关文章

相关 [重构 代码 阶段] 推荐:

重构代码的7个阶段

- 风子 - 酷壳 - CoolShell.cn
你曾去想重构一个很老的模块,但是你只看了一眼你就恶心极了. 文档,奇怪的函数和类的命名,等等,整个模块就像一个带着脚镣的衣衫褴褛的人,虽然能走,但是其已经让人感到很不舒服. 面对这种情况,真正的程序员会是不会认输的,他们会接受挑战认真分析,那怕重写也在所不惜. 最终那个模块会被他们重构,就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样.

代码重构

- - ITeye博客
随着程序的演化,我们有必要重新思考早先的决策,并重写部分代码. 代码需要演化;它不是静态的事物. 重写、重做和重新架构代码合起来,称为重构.    当你遇到绊脚石  ---  代码不在合适,你注意到有两样东西其实应该合并或是其他任何对你来说是"错误"的东西  -------- . 如果代码具备以下特征,你都应该考虑重构代码:.

代码重构总结

- - 开源软件 - ITeye博客
重构:对软件内部结构的一种调整,目的是在不改变软件之可察行为前提下,提高其理解性,降低其修改成本. 创建一个新方法,命名以它做什么来命名,而不是怎么做来命名. 如果只是简单的委托,可以将方法内联. 被子类继承的方法不能内联. 如果一个临时变量只被简单的表达式赋值一次,就可以将它内联. 将这个临时变量申明为final.

代码坏味道——重构

- - CSDN博客推荐文章
1.    Duplicated Code(重复的代码). 臭味行列中首当其冲的就是Duplicated Code. 如果你在一个以上的地点看到相同的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好. 最单纯的Duplicated Code就是[同一个class内的两个函数含有相同表达式(expression)].

代码重构方向原则指导

- - 外刊IT评论
提示:如果您在阅读器里点击订阅本站的文章链接时发现有一个中转页,这说明你的订阅地址有误,本站的订阅地址(RSS)是:. http://www.aqee.net/feed/,请及时纠正. 重构是一种对软件进行修改的行为,但它并不改变软件的功能特征,而是通过让软件程序更清晰,更简洁和更条理来改进软件的质量.

代码重构:HTML与语义化

- - 标点符
在前端开发过程中,很多人谈到“模块化”,很少人特别关注“语义化”,简单的说大多数人更关注功能的实现,而忽视了实现的细节. 所谓HTML语义化,就是尽可能的理解要表达的内容,选择适合的HTML标签,将内容转换成浏览器认识的语言,通过浏览器传达信息给用户. 目前很多的前端书籍取名就叫精通DIV+CSS,让人感觉DIV可以搞定一切,但是DIV标签仅代表一个块状标记,HTML的每个标签都有它特定的意义,而语义化就是让我们在适当的位置用适当的标签,以更好的让人和机器(机器可理解为浏览器可理解为搜索引擎)都一目了然.

降低代码重构的风险

- - InfoQ cn
重构是每一个开发人员都要面对的功课,Martin Fowler将其定义为“在不改变软件外部行为的前提下,对其内部结构进行改变,使之更容易理解并便于修改”. 技术专家Paul在 博客中讨论了重构的风险,并提出了降低风险的措施. 重构代码是危险的,代码的变化会导致测试的压力很大. 除非有必要的理由,否则不要轻易重构.

提升代码质量的 6 个重构方法

- - 蓝飞技术部落格
在过去做了不少代码走读,发现了一些代码质量上比较普遍的问题,以下是其中的前五名:. 臃肿的类:类之所以会臃肿,是因为开发者缺乏对最基本的编码原则,即“单一职责原则”(SRP)的理解. 这些类往往会变得很臃肿,是由于不同的且在功能上缺少关联的方法都放在了相同的类里面. 长方法:方法之所以会变得很长主要是有以下几个原因:.

Fix Bug的五个阶段

- Sirius - 酷壳 - CoolShell.cn
下面的文章和《各种流行的编程方式》有异曲同工,请你不要理解错了. 一个非常严重和困难的bug,能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯. 经受这种考验的创伤程度,相当你受到了一次严重的身体伤害,离婚,或是家庭成为的离世. 研究人员在研究了计算机编程心理学后,得出了一个程序员们在解决一个困难的bug时的心路里程.

逆境心理五阶段

- 冬虫夏草 - 科学松鼠会
原作:http://buttersafe.com/2010/05/20/the-five-stages/.