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