论文部分内容阅读
摘要:软件重构对软件项目开发来说已经变得越来越重要,也是目前软件工程领域研究的热点问题。重构是在不改变行为的条件下对软件的内部结构所做的一种改变,从而使软件更容易理解,便于修改。主要讲述重构技术的基本概念,论述架构重构的问题、难点和发展趋势。
关键词:软件重构重构价值重构能力
中图分类号: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.
关键词:软件重构重构价值重构能力
中图分类号: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.