重构代码的7个阶段
2011年08月16日 陈皓 评论 77 条评论 32,336 人阅读
-----------------------------------------------------------------
你曾去想重构一个很老的模块，但是你只看了一眼你就恶心极了。文档，奇怪的函数和类的命名，等等，整个模块就像一个带着脚镣的衣衫褴褛的人，虽然能走，但是其已经让人感到很不舒服。面对这种情况，真正的程序员会是不会认输的，他们会接受挑战认真分析，那怕重写也在所不惜。最终那个模块会被他们重构，就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段，文章来自：The 7 stages of refactoring，下面的翻译只是意译。
第一阶段 – 绝望
在你开始去查看你想要重构的模块的，你会觉得好像很简单，这里需要改一个类，那里需要改两到三个函数，重写几个函数，看上去没什么大不了的，一两天就搞定了。于是你着手开始重构，然后当你调整重构了一些代码，比如改了一些命名，修理了一些逻辑，渐渐地，你会发现这个怪物原来体型这么大，你会看到与代码不符甚至含糊不清的注释，完全摸不着头脑的数据结构，还有一些看似不需要方法被调了几次，你还会发现无法搞清一个函数调用链上的逻辑。你感到这个事可能一周都搞不定，你开始绝望了。
第二阶段 – 找最简单的做
你承认你要重构的这个模块就是一个可怕的怪物，不是一两下就可以搞定的，于是你开始着干一些简单的事，比如重新命名一下几个函数，移除一些代码的阻碍，产生几个常量来消除magic number，等等，你知道这样做至少不会让代码变得更糟糕。
第三阶段 – 再次绝望
但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事，改正这些事完全于事无补，你应该要做的事就是重写所有的东西。但是你却没有时间这么干，而这些代码剪不乱理还乱，耦合得太多，让你再一次绝望。所以，你只能部分重写那些不会花太多时间的部分，这样至少可以让这些老的代码能被更多的重用。虽然不完美，但是至少可以试试。
第四阶段 – 开始乐观
在你试着部分重构这个模块几天之后，随着重构了几个单元后，虽然你发现改善代码的进度太慢了，但此时，你已知道代码应该要被改成什么样，你在痛苦之后也锁定了那些那修改的类。是的，虽然你的时间预算已经超支，虽然要干的事比较多，但你还是充满希望，觉得那是值得的。你胸中的那团火又被点燃了。
第五阶段 – 快速了结
在这个时候，你发现你已花了太多的时间，而情况越来越复杂，你感到你所面对的情况越来越让你越到不安，你明白你自己已经陷入了困境。你原本以为只需要一次简单的重构，然而现在你要面对的是重写所有的东西。你开始意识到原因是因为你是一个完美主义者，你想让代码变得完美。于是你开始在怠慢你文档，并想找到一个捷径来重写老的代码，你开始采用一些简单而粗暴，快速而有点肮脏的方法。虽然不是很完美，但你就是这样去做了。然后，你开始运行测试做UT，发现UT报告上全是红色，几乎全都失败了，你恐慌了，于是快速地fix代码，然后让UT 能工作。此时，你拍拍自己胸口，说到，没问题 ，于是就把代码提交了。
第六阶段 – 修改大量的Bug
你的重写并不完美，虽然其过了测试，但是那些UT测试对于你的新的代码有点不太合适，虽然他们都没有报错，但是他们测试得范围太小了，没有覆盖到所有的情况和边界。所以，在这以后，你还需要几周或是更长的时间不得不来修正越来越多的bug，这使得你的设计和代码在每一次quick-fix后就变得越来越难看。此时，代码已经不像你所期望的那样完美了，但你依然觉得他还是比一开始要好一些。这个阶段可能历经几个月。
第七阶段 – 觉悟
经过了6个月，你重写的模块又出了一个比较严重的bug。这让你重构的那个模块变得更难堪。你发现出的这个问题是和当初的设计不一致，你还发现被你重构掉的那段老的代码并不是当初看上去的那么坏，那段老的代码确实考虑到了一些你未曾考虑到的事情。这个时候，你团队里有人站出来说这个模块应该被重构或是重写，而你却不动声色地一言不发，并希望那个站出来的人能在几个月后能觉悟起来。
——————
不知道这是不是你的经历，我经历过很多次这样的事。对于很多维护性质的项目，我犯过的错误让我成了一个实实在在的保守派，我几乎不敢动，那怕看到代码很不合口味。当然，那些从来没有写过代码的敏捷咨询师一定会说用TDD或是UT可以让你的重构更有效也更容易，因为这样会让他们显得更我价值，但我想告诉你，这种脱离实际的说法很不负责任，这就好比说—— 我在杀猪的时候遇到了一些麻烦，因为我对猪的生理结构不清楚，或是这本来就是一头畸形的猪，导致我杀的猪很难看，而伟大的敏捷咨询师却告诉我，要用一把更快更漂亮的刀。软件开发永远不是那么简单的事，杀猪也一样。
------------------------------------------------------------------------
站在什么角度和立场去评判这件事情（重构超难的遗留代码），结论显然是不一样的。所以不说清楚立场，结论不免太片面。试着举例：
1、一个有洁癖希望锻炼自己TDD能力，不甚关心公司短期利益，过高估计自己的程序员：多好的一个重构的范例啊，我要尝试搞定它！（就如同一个新中医遇到疑难杂症用猛药似的）
2、一个伤了好多遍伤不起的老程序员：哈，这事儿谁动谁傻逼。看，新来的那个傻逼要蠢蠢欲动了，正好把我的bug的原因推给他，我好多休息下，我只管贴腐肉完成我的工作就行。老板看见我这么快，他那么慢一定会对我更倚重。反正这个产品已经老得不能进化了， 迟早要趁SOA概念火爆，重新开发一个新的，没必要为它吃力不讨好，背黑锅。
3、一个公司中层管理：我们的产品是够老，加新功能很难，但老功能能用，客户领导和我们关系很铁，而且YY公司的产品比我们更差劲儿~，客户领导不会因为我们烂而下台，因为对手更烂！ thank god!
4、客户中层领导：MD，这个XX公司的东西实在难用，想加一点儿简单的东西都推三阻四的。 哎管他呢，反正另外一家更烂，我不会有位置的危机，XX公司的销售对我还不错，就这样吧！
5、客户的老总：我们的效率比起国外同行来，还是有不少差距啊！不过我们有更多定价权，他们进来还受到限制：我们利润比他们高，这多亏了社会主义的优越性啊~
6、政府官员：现在民族产业还不够强大，全面开放的时机还不成熟，还需要大力扶持啊——政府扶持的钱不够？ 怎么会？ 多卖点儿地，多征点房产改名税，不就有了吗！
7、老百姓（程序员）： MD，税又高了，房价又涨了，省吃俭用吧也不够。 NND，不能干程序员啊， 看那个搞sales的，积累一些业界客户的关系，吃香的喝辣的，说不定榜上哪个老板~~ 哦不，， 老板的女儿，就少奋斗10年啦！重构这东西能当饭吃吗？都TM鬼扯淡！
….还可以推演更多，就不赘言了。
系统论给我的一个重要启发是： 很多时候在一个系统内部看不出问题，只要站在一个更大范围的系统去观察，说不定就会找到原因。 上述关于重构的故事的我的结论是： 在一个效率并非最重要竞争要素的市场机制里，单纯的纠结重构这样的效率手段应不应该做， 这样是不智的。 说到底是一个利益问题。
--------------------------------------------
重构这个事情，越早越好。最好是原班人马。不然就别干。或者想都不要想。
-----------------------------------------------
我们公司有一些代码，存在的时间超过了20年。在那个磁盘空间以MB来计算的年代下，代码里的函数名变量名极其精简且晦涩难懂。C风格的代码和后来新加的C++风格的混在一起。最恐怖的一个核心函数，里面只有一个switch/case但是有3000行之多。当我第一次看到这些代码时实在很难理解为什么这么多年没有人重构过，至少让代码的逻辑看起来清晰一些。但几年以后再看这些代码，几乎到处都有defect fix — 这不是说明代码烂，而是曾经有大量的QA和数百万的用户在20多年的时间里不断测试这些代码，把所有能碰到的极端情况都测到了，以至于那些貌似很丑陋的代码实际上极其稳定。
在这种情况下，如果还有人想去重构一把，那只能是脑筋秀逗。
