重构之法

     再写重构是在CSDN上看到了一篇关于重构软件并不会改善代码质量的文章。一笑了之之后，还想再谈谈个人对重构的看法。

     在我的职业生涯中，有很多重构的经历，最后也都得到了很好的效果，因此，本人谨以自己的经历为例，从重构的法与度两个方面进行一些总结。至于重构的作用与学习思路，可以参见我4年前的两篇文章《在代码重构中蜕变》《再谈对“重构”的学习》。

     本文主要谈重构的方法，另成一文谈重构的度量。

     方法，为达到目的而采取的方式、手段、行为方式。

     提到方法，必须得说，Martin Fowler著的《重构，改善既有代码的设计》是必读的经典。正是这本书，把重构的概念广而传播，让我们认识了什么是重构以及重构的数十种基本方法。那么问题来了，既然大师已经把方法都写得如此清晰了，我们又谈什么方法呢？我们要谈的是重构在敏捷开发过程中的组织与实施。

     现在很多团队都在用敏捷开发，不停的迭代着，如何在这样的开发模型中进行重构，这是我们接下来要探讨的问题。

     为了把这个问题说清楚，我们还要对重构的概念细分为两个层次。一个层次是以代码和模块为对象的小范围重构，我们估且称之为代码重构；另一个层次是以更大范围的架构为对象的重构，下文我们称之为架构重构。

     先来看代码重构。代码重构其实与迭代的关系不大，我更喜欢把代码重构与工程师的个人能力与素养结合在一起。优秀的工程师，骨子里头流淌的都是代码。只要看到代码，就能敏感的闻到那些“坏味道”，就为此坐立不安，就自然而然的要把这些“坏味道”消灭。他们随手改一些意义不明确的类名、方法名、变量名，重新调整类的职责分配，复杂代码进行函数提取，用小函数替换长的表达式或复杂的逻辑运算……，任何一个小的修改，都让代码的可读性趋向更好，这就是方法。无论是否采用敏捷模型，这种代码重构都应该随时发生。不需要进行方法指导，只需要培养这种意识就好。要知道，勿以善小而不为，溪流可以成江海，勿以恶小而为之，蚁穴可以溃坝堤。正是这样随手而为，代码就能保持在较好的水平，而任何的小混乱，都可能让代码走向深渊。一句话，对代码质量的高标准严要求就是方，团队中所有的人都是同一标准，代码重构就会发生于无形。当然，这样的重构也并不能100%的改善代码质量，并不是见到所有的switch case语句都用子类化处理就是恰当的，质量改善与否与重构本身无关，而是与进行重构的人有关。

     再来看架构重构。一涉及到架构，自然而然的就会发生在对项目有重大影响的问题上了。对于敏捷模型，由于其强调的是少预先架构，拥抱变化，所以都或多或少的存在架构重构。比如项目早期采用了按功能划分模块的做法快速上线了功能，但随着功能增多，出现了公共部分，为了减少重复劳动，会引入层次结构。这样的变化，往往需要时间、人员的资源投入，会为发版速度带来影响，所以实践起来相对会困难得多。还有些时候是为了性能优化进行架构调整，这个的目标是性能优化而不是架构调整，只是架构影响了性能而已，不可混为一谈。

     架构重构要想执行得好，需要关注以下几个要素。

     一是目标清晰，架构方案明确。要重构什么，重构成什么样子，会带来什么好处，会引入什么风险，大约需要多少资源……。只有目标清晰，才能进行决策。看到过一些用重构提高性能，用重构锻炼队伍的例子，最后不仅结构没好转，反而走向进一步的混乱，最终进行演变成重写。如果是进行架构重构，就要把这种目标确定下来，充分评估必要性、可行性，明确结果。比如在我的一项重构中，为了支持更多功能的加入，减少公共部分的重复，将纵向结构重构为横向结构，然后设计好新的架构并在团队当中达成共识。

     二是方案一致性。软件开发是复杂的，架构关系到参与的每一个人，架构师一定要让方案得到共识，形成一致性的理解，否则在实施过程中会发生偏离，增加成本和风险。给团队成员讲清楚吧，真的不是每个人都能理解。

     三是合理计划。架构重构往往会跨迭代进行，在少影响版本发布节奏的前提下进行，这就要把重构计划按挫代分解，合理规划，控制节奏。比如我们的每个迭代都要有版本上线，这样就必须得跨迭代重构，不仅要分解，还要能与迭代中正常的功能开发结合到一起，是需要与产品团队、开发团队、测试团队共同规划的。架构重构是个长期的多轮的过程，要注意何时启动一轮，何时停止。

     四是架构师参与。架构师不是画图用的，在架构重构中，必须参与代码，即使不亲自写代码，也要每天关注代码的实现，防止与架构设计出现较大差异。这是能够按预期方案实现的关键。

     

     总结一下，对于代码重构，要用代码质量为标准，作为日常的一种编码方法和习惯加以强化。对于架构重构，要以架构师为主导，慎思笃行。

     

——欢迎转载，请注明原文出处 http://blog.csdn.net/caowenbin ——
——欢迎关注微信号“曹文斌的软件思考”，共同探讨软件人生——