软件重构的研究

摘要：软件重构对软件项目开发来说已经变得越来越重要，也是目前软件工程领域研究的热点问题。重构是在不改变行为的条件下对软件的内部结构所做的一种改变，从而使软件更容易理解，便于修改。主要讲述重构技术的基本概念，论述架构重构的问题、难点和发展趋势。

关键词：软件重构重构价值重构能力

中图分类号：TP311文献标识码：A文章编号：1007-3973（2012）004-080-02

1引言

随着计算机硬件和网络技术的不断发展，软件的功能越来越多，几乎涉及到各行各业，软件的复杂度也在不断上升，尤其是一些比较复杂的业务处理，往往需要非常缜密的逻辑处理来满足业务需要。而且在研发和维护过程中，往往需要对软件进行不断的修改和完善，导致代码越来越难以维护，甚至到无法修改的程度。软件开发首先已经根据当时的需求做了系统设计和架构设计，但是开发过程中代码没有明确的注释和说明，或者注释比较陈旧，导致在维护过程中给修改工作带来极大的不便。很多人认为，原来的系统既然不能重新开发，而且已经在运行，就让它去吧。于是，程序员怀着消极的心态增加的代码变成下一个程序员咒骂的对象。依次下去，后面的程序员更会加剧这种心态，而且为了快速修改，往往不加思索的从类似的功能中粘贴相关代码，应付了事。最后软件的代码与最初的设计以及完全脱离开了，所谓的设计以及看不到了。最后，事情发展到我们意料之内而且又无可奈何的地步，代码无法理解，修改难度很大，成本非常高。

这是在软件开发领域内程序开发人员一直想解决的问题。软件重构技术的研究正是因为以上出现的普遍现象而被人们关注。

2软件重构定义

软件重构是指在不改变软件的功能和外部可见性的情况下，为了改善软件的结构，提高清晰性、可扩展性和可重用性而对软件进行的改造。简而言之，重构就是改进已经写好的软件的设计。

重构是代码维护中的一部分，既不修正错误，又不增加新的功能性。而是用于提高代码的可读性或者改变代码的结构和设计，使其在将来更容易被维护。特别是，在现有的程序的结构下，给一个程序增加一个新的行为会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。

3难点、痛点和未来热点

架构师不能说就是是设计架构的人，否则，这种理解太简单化了，没有反映出不同背景的软件企业、不同发展阶段的软件企业所重点关注的“主战场”的不同。这里用一张图来刻画架构师的几个“主战场”，以辅助我们更准确地定位架构重构在架构师工作中的位置。

随着不同产品的推出、不同版本的，需要维护的遗留代码越来越多，重构也就在所难免。关于架构重构能力之于软件企业的意义，可用八个字概括：难点、痛点、未来热点。

难点。不少软企都有架构重构的意愿，但经常是一拖再拖不敢实施。进行了架构重构之后，也有企业发现没效果——架构质量没有得到改善——这相当于架构重构失败了。这是因为，架构“重构”是难点，它比架构“设计”更难。

痛点。困难还不能不做。加个特征很“难”，改个Bug很“绕”，软件工程师费时费力，事倍功半，同时软企管理层也倍感压力，因为维护成本日益呈现攀升趋势，“加快问题单响应速度”目标的达成也越来越遥远。如何把架构重构好，成了大家共同的痛.

未来热点。既然是不好对付的“难点”，又是影响软企切实利益的“痛点”，架构重构领域就必然是“未来热点”了。

4重构能力的价值体现

下面简要阐述一下重构能力价值体现的种种情况。对个人而言，重构能力影响着研发人员的工作业绩、职业发展，是不折不扣的“核心竞争力”。因为当前业界越来越重视对遗留代码、第三方代码、开源代码的利用，掌握重构能力的研发人员能在竞争中脱颖而出。相反，不能自由掌控代码的程序员，加班不少、业绩不高；对现有不满意的架构“力不从心”的架构师，工作也处处被动，高薪但不开心。而软件企业，对“重构人才”已经开始重视起来，对这类人才的要求如下：

(1)对已有系统进行重构和优化；

(2)对组件的重用、重构有丰富的经验；

(3)能够熟练运用各种重构方法；

(4)熟悉Linux系统重构、Bootloader移植；

(5)察觉实现问题，提出改进（重构）方案；

(6)对框架本身的体系有较为深厚的理解和应用经验，对框架本身有过开发或重构者可优先考虑。

同时，大型软件企业也已越来越关心开发骨干重构能力的培养，从2006年专职从事咨询和培训的服务业绩经历已证明这一点。

5未来趋势分析

软企面临的实际问题以及相应的实践探索，是推动未来发展的根本原因。如图2所示，是未来3—5年具体趋势。

趋势1：认识更趋于专业。当前，对不同层面重构的明确认识还不普及，有很多错误观点在流行。例如，诸如“架构重构和代码重构差不多”等观点，是不切实际的。更专业的认识，是将重构分为代码重构（Code Refactoring）、模块重构（Module Refactoring）、架构重构（Architecture Refactoring）三大类。从重构的次数来说，代码重构比较频繁，其次是模块重构和架构重构；从重构的技术角度说，架构重构对人的能力要求较高，其实是模块重构和代码重构。

不同重构技能混为一谈造成的危害，在软件企业中相当常见。其中，软件研发人员们“小重构不屑做，大重构不敢做”的表现，是最令研发管理者头痛的。

更进一步，“重构的3个问题，2.5个亟待发展”是我们的基本判断，即：代码重构发展不错但还将继续延展，模块重构和架构重构发展则严重不足。

趋势2：代码重构—往特定领域纵深发展，当前的代码重构成例的总结，总的来说多在OO方面。但通过分析一些大型软件企业的领域特点和代码现状，我们发现大量遗留代码甚至是十年之前的，既有C语言编写的结构化代码、又有C++编写的结构化设计思想的代码（只有成员变量或成员函数的类大量存在）。因此，未来必然有更多、更具针对性的重构成例在软企的维护一线出现。

趋势3：模块重构成为软企能力建设“热点”。

趋势4：架构重构是—切实有效的架构重构方法。

过去，模块重构和架构重构发展严重不足，一线实践往往找不到可参照的方法，多靠摸索来实践。例如，有架构重构方法提出，首先进行的是“重构计划制定阶段”，这种方法在软企中是没法用的。未来的突破，从领先的实践中孕育出切合实际的模块重构方法和架构重构方法。

趋势5：五年内将出现专职“设计重构师”职位。

6提高重构能力的建议

这里本文给两点建议。

(1)架构重构，必须重视代码。

(2)关键模块的重构，可以基于ARCT方法论，迭代式开展。

虽然架构比较抽象，但“借助架构文档等进行架构重构”的做法是不务实的。现实是，代码中有随处可见的“贴膏药”式的特殊情况处理，有时更是“补丁摞补丁”——这些都是文档中没有覆盖的。这些“膏药”和“补丁”恰恰是现存系统正确处理业务的“宝”。所以，我们的架构重构“不得不”依靠代码。另一方面，又不能陷入代码泥潭。我们的应对理念是“基于7种接口风格的模块任免”。

有经验的架构重构实践者会发现，架构重构非常可观的工作量，是用于进行核心模块的重构。根据本文的经验，模块重构最终经常会落实成几十个代码重构（Refactoring），但这绝不意味着模块重构就是代码重构的简单累加——设计重构的方向在哪里？模块重构设计师必须有能力解决这个问题。

ARCT方法逐步实践成为一种模块重构方法论。

代码分析（A）是基础。从代码入手。

模型逆向（R）是纽带。从代码级思维跳到设计级思维，抽象出当前的设计模型。

设计构想（C）是关键。例如，为了获得更好的可扩展性等，新设计要重构成什么样呢？

设计拷问（T）是保证。回归代码层面进行设计可行性、合理性的主动质疑。可以工作吗？可以正确处理那些散落在代码各处的特殊处理吗？适应了各种场景带来的可扩展性、可维护性的压力了吗？模块重构时，必须适时思考这些问题。

参考文献：

[1]Peter Eeles,Peter Cripps.架构实战：软件架构设计的过程[M].机械工业出版社,2010.

[2]Diomidis Spinellis,Georgios Gousios.架构之美[M].机械工业出版社,2010.

[3]杨春辉.软件架构师教程[M].清华大学出版社,2009.

[4]房晓溪,梁慧林.游戏架构教程[M].水力水电出版社,2011.

[5]张春祥.软件体系结构理论与实践[M].中国电力出版社,2011.