架构重构趋势谈

近几年,我专职从事为软件企业提供咨询和培训服务的工作,所以得以近距离观察众
多一线软件研发团队的喜怒哀乐。其中,重构已经成为目前软件研发的关键环节,本文谈
“架构师就是设计架构的人”,这种理解太简单化了,没有反映出不同背景的软件企业、
不同发展阶段的软件企业所重点关注的“主战场”的不同。我用一张图来刻画架构师的几个
“主战场”(如图1所示),以辅助我们更准确地“定位”架构重构在架构师工作中的位置。
随着不同产品的推出、不同版本的发布,需要维护的遗留代码越来越多,重构也就在所
难免。关于架构重构能力之于软件企业的意义,可用八个字概括:难点、痛点、未来热点。
难点。不少软企都有架构重构的意愿,但经常是一拖再拖不敢实施。进行了架构重构之
后,也有企业发现没效果——架构质量没有得到改善——这相当于架构重构失败了。这是因
痛点。困难就不干呗?可是不行。加个Feature很“难”,改个Bug很“绕”,软件工程师
们被加班搞得很“惨”……软企管理层也倍感压力,因为维护成本日益呈现攀升趋势,“加快
问题单响应速度”目标的达成也越来越遥远。“如何把架构重构好”,成了大家共同的痛。
未来热点。既然是不好对付的“难点”,又是影响软企切实利益的“痛点”,架构重构领域
对个人而言,重构能力影响着研发人员的工作业绩、职业发展,是不折不扣的“核心竞
争力”。因为当前业界越来越重视对遗留代码、第三方代码、开源代码的利用,掌握重构能
力的研发人员能在竞争中脱颖而出。相反,不能自由掌控代码的程序员,加班不少、业绩不
高;对现有不满意的架构“力不从心”的架构师,工作也处处被动,高薪但不开心。如图2所
而软件企业,早已有意无意地开始了“重构人才争夺战”,不断在招聘广告中打出如下要
●对框架本身的体系有较为深厚的理解和应用经验,对框架本身有过开发或重构者可
同时,大型软件企业也已越来越关心开发骨干重构能力的培养,我从2006年专职从事
咨询和培训以来的服务经历已证明这一点。其中,2010年我帮助大型软件企业提升重构能
软企面临的实际问题以及相应的实践探索,是推动未来发展的根本原因。如图3所示,
当前,对不同层面重构的明确认识还不普及,有很多错误观点在流行。例如,诸如“架
构重构和《重构》书里说的代码重构差不多”等观点,是不切实际的。更专业的认识,是将
“不同重构技能混为一谈”造成的危害,在软件企业中相当常见。其中,软件研发人员们
“小重构不屑做,大重构不敢做”的表现,是最令研发管理者头痛的。你们公司,有吗?
更进一步,“重构的3个问题,2.5个亟待发展”是我们的基本判断,即:代码重构发展
不错但还将继续延展,模块重构和架构重构发展则严重不足。具体观点分别在下面的趋势2、
当前的代码重构成例的总结,总的来说多在OO方面。但通过分析一些大型软件企业
的领域特点和代码现状,我们发现大量遗留代码甚至是十年之前的,既有C语言编写的结
构化代码、又有C++编写的结构化设计思想的代码(只有成员变量或成员函数的类大量存
在)。因此,未来必然有更多、更具针对性的重构成例在软企的维护一线复杂条件的重构成例地图
例如,在和大量软企及其结构化代码的接触过程中,我们总结和“部分原创”了下列“复
过去,模块重构和架构重构发展严重不足,一线实践往往找不到可参照的方法,多靠摸
索来实践。例如,有架构重构方法提出,首先进行的是“重构计划制定阶段”,这种方法在软
未来3—5年,这一块将有突破,从领先的实践中孕育出切合实际的模块重构方法和架
虽然架构比较抽象,但“借助架构文档等进行架构重构”的做法是不务实的。现实是,代
码中有随处可见的“贴膏药”式的特殊情况处理,有时更是“补丁摞补丁”——这些都是文档中
没有覆盖的。这些“膏药”和“补丁”恰恰是现存系统正确处理业务的“宝”。所以,我们的架构
另一方面,又不能陷入代码泥潭。我们的应对理念是“基于7种接口风格的模块任免”,
有经验的架构重构实践者会发现,架构重构非常可观的工作量,是用于进行核心模块的
重构。根据我们的经验,模块重构最终经常会落实成几十正规买球的网站个代码重构(Refactoring),但
这绝不意味着模块重构就是代码重构的简单累加——设计重构的方向在哪里?模块重构设
ARCT方法是我们逐步实践成型的一种模块重构方法论(如图6所示),已多次用于大
模型逆向(R)是纽带。从代码级思维跳到设计级思维,抽象出当前的设计模型。
设计构想(C)是关键。例如,为了获得更好的可扩展性等,新设计要重构成什么样呢?
设计拷问(T)是保证。回归代码层面进行设计可行性、合理性的主动质疑。可以工作
吗?可以正确处理那些散落在代码各处的特殊处理吗?适应了各种场景带来的可扩展性、可
温昱,软件架构专家,资深咨询顾问,实战型架构培训专家,ADMEMS 架构实践体系

上一篇
