1、软件集成开发环境的技术债务管理研究 刘亚珺 李兵 李增扬 梁鹏 吴闽泉 武汉大学国际软件学院 武汉大学复杂网络研究中心 武汉大学计算机学院软件工程国家重点实验室 摘 要： 软件技术债务是运用经济学中“债务”的概念来描述软件开发中因项目短期利益而实施的技术折中。但从长期来看, 技术债务会影响软件的质量、成本和开发效率, 因此有必要对其进行有效管理。现有的技术债务管理工具数量少且存在各种局限性, 难以实现有效的管理。主流的软件集成开发环境功能强大且应用广泛, 可以为技术债务管理服务。以具有代表性的集成开发环境 Visual Studio 2015 企业版为研究对象, 通过 C#实例发现其管理 4
2、类与代码直接相关的技术债务的能力, 并将其与 4 种专门的技术债务管理工具进行对比, 为开发团队的日常实践提供技术债务管理支持。结果表明, Visual Studio 能够提供更好的技术债务管理功能, 并能应用多种方法对项目中存在的各类技术债务进行不同程度的管理。关键词： 技术债务; 技术债务类型; 技术债务管理活动; 技术债务管理工具; Visual Studio; 作者简介：刘亚珺 (1992-) , 女, 硕士生, 主要研究方向为技术债务与软件架构;E-mail:;作者简介：李兵 (1969-) , 男, 博士, 教授, 主要研究方向为网络化软件、面向服务的软件工程、复杂系统与复杂网络、
3、人工智能、云计算与大数据;作者简介：李增扬 (1982-) , 男, 博士后, 讲师, 主要研究方向为技术债务、软件架构、复杂系统与复杂网络;作者简介：梁鹏 (1978-) , 男, 博士, 教授, 主要研究方向为软件体系结构、需求工程;作者简介：吴闽泉 (1966-) , 男, 硕士, 高级工程师, 主要研究方向为计算机应用, E-mail: (通信作者) 。收稿日期：2016-10-21基金：国家重点研发计划 (2016YFB0800405) Study on Technical Debt Management of Integrated Development EnvironmentLI
4、U Ya-jun LI Bing LI Zeng-yang LIANG Peng WU Min-quan International School of Software, Wuhan University; State Key Laboratory of Software Engineering, School of Computer Science, Wuhan University; Abstract： Technical debt (TD) , a metaphor to financial debt, refers to technical compromises which are
5、 made to gain short-term benefits at the cost of long-term software quality.However, in the long run TD will negatively affect software quality as well as cost and productivity of software development.Thus, TD should be effectively managed.Existing dedicated TD management tools are rather limited an
6、d have various limitations.Hence, it is difficult to effectively manage TD using such tools.Mainstream integrated development environments (IDEs) are powerful and widely used, can serve to manage TD.In this study, we investigated Microsoft Visual Studio 2015 Enterprise Edition, a representative main
7、stream IDE, to explore its ability for managing four types of TD directly related to source code using a C# project.Then we compared Visual Studio with four dedicated TD management tools with respect to their capabilities in managing TD and their support for TD management of development teams in the
8、ir daily practices.The results show that Visual Studio provides better support for managing TD in terms of diversity of TD types and the range of TD management activities.In addition, with Visual Studio, specific TD instances can be managed to different extents in a variety of ways.Keyword： Technica
9、l debt; Technical debt type; Technical debt management activity; Technical debt management tool; Visual Studio; Received： 2016-10-211 引言技术债务 (Technical Debt, TD) 是一种反映技术折中的隐喻说法, 为了短期的利益而采取欠佳的技术决策, 可能会对软件系统的长期质量产生不良影响。该隐喻最早主要关注软件实现, 即软件的代码层, 现已逐渐扩展到软件架构、详细设计以及文档、需求和测试等方面1。早在 1992 年, Ward Cunningham就在
10、 OOPSLA 报告2中提出了技术债务的概念并指出了其对软件开发的影响, 但直至近几年, 技术债务才受到工业界和学术界的重点关注。在对技术债务的描述中, 同样使用了金融债务中的一些概念来进行类比, 如本金、利息、效益、风险等。本金即消除技术债务的成本;利息是在不解决技术债务的情况下对软件系统进行维护与扩展所需的额外成本;效益指引入技术债务后可获得的短期收益;技术债务也是软件项目风险的一类, 因为如果技术债务持续累积, 将影响系统的质量3。技术债务的产生有多种原因:可能是项目利益相关者为了获得短期利益而有意引入的, 比如项目团队为了尽可能获得更高的商业价值, 加快产品新特性的开发, 尽早将产品投
11、入市场2, 以帮助公司在竞争中取得领先;或者是由于产品开发受到预算的限制等, 只能相应地做出技术上的妥协。尽管在未来可能需要付出比当前更高的代价来解决这些技术债务, 但如果这种有意引入的技术债务的成本、利息及对系统的影响是已知的、可控的, 这样的妥协是可以接受的4。另一方面, 技术债务的引入可能是无意的, 项目经理和开发团队没有意识到它在项目中的存在和影响5, 如使用了旧的技术、工具或者标准;开发人员缺乏一定的专业知识6。如果技术债务是未知的, 且未得到解决, 将会不断累积, 进而给软件系统的后期维护和演化带来巨大挑战。为了改善软件系统的可维护性、可重用性、可理解性, 同时防止累积的技术债务对
12、软件质量造成难以逆转的损害, 无论是有意还是无意产生的技术债务, 对其进行相应的控制和管理是非常必要的7。试想如果在项目的某个组件中引入了技术债务, 之后又基于这个组件对项目不断地进行扩展, 若不能及时且有效地对技术债务进行纠正, 这样不断累积的技术债务将会使软件的维护和演化变得越来越困难, 从而增加更多的技术债务, 这种恶性循环在极端情况下可能会导致软件产品的“破产”和项目的终止。对技术债务的管理主要包括两个方面:1) 预防潜在技术债务 (有意的和无意的) 的产生;2) 对现有技术债务的处理 (识别、偿还等) , 使其变得可见和可控, 防止其在软件项目中的过度累积, 同时平衡软件项目的成本和
13、价值8。为了能有效地管理技术债务, 开发团队必须对技术债务的类型 (如代码 TD、设计 TD、架构 TD、测试 TD 等) 、产生原因以及影响等方面有足够的认识, 并了解技术债务管理的现状, 包括已被提出、开发、使用的技术债务管理方法和工具等。软件技术债务作为一个较新的研究领域, 在工业界和学术界的相关研究和应用正逐步兴起, 但能用于技术债务管理的工具十分有限。根据我们之前所做的技术债务管理方面的映射研究 (Systematic Mapping Study) 5发现, 现有的技术债务管理工具有 4 个方面的局限性:1) 仅针对一种或两种技术债务实例, 如Software maps tool9和
14、 SonarQube10等工具仅适用于管理代码技术债务;2) 仅支持特定技术债务管理活动, 大部分工具适用于识别技术债务, 如SonarQube 和 NDepend, 少数可用于度量技术债务, 如 Software maps tool;3) 支持的编程语言单一, 如 DebtFlag11仅支持 Java 语言;4) 工具需额外部署使用, 不能集成到主流开发环境中, 不利于开发人员的日常使用。考虑到与代码相关的技术债务 (如代码 TD、设计 TD) 会随着项目代码的演化而频繁地变更, 技术债务管理工具应尽可能促进开发团队的日常开发活动。现有集成开发环境没有提供专门管理技术债务的功能, 但集成开发
15、环境的某些功能可以为管理技术债务提供支持。因此, 探究目前使用广泛、功能强大的集成开发环境是否同样具有技术债务管理能力对于项目开发十分重要, 有利于开发者在开发功能的同时时刻关注并提升代码质量。Microsoft Visual Studio (VS) 作为目前最流行的集成开发环境之一, 被大量开发团队用于实现诸多类型和不同规模的软件项目, 能够支持 C#, C+, JavaScript, F#, Visual Basic, Python 等多种编程语言, 有较强的实用性。不同版本的 VS 产品中, VS 2015 企业版功能最为强大, 适用于具有高质量要求和扩展需求的各种规模的开发团队, 在测
16、试 (代码覆盖率、自动化单元测试等) 、体系结构与建模、代码分析等方面的功能完备性是其他版本不能比拟的。因此, 本文选择 VS 2015 企业版作为开发环境, 力求充分探究其作为主流集成开发环境对技术债务管理的支持程度。本文首先介绍技术债务按照软件生命周期的不同阶段进行的分类及每种技术债务的成因, 并概述技术债务管理过程所包含的各项管理活动 (如识别、度量、偿还) ;然后通过一个 C#项目实例, 具体分析 VS 可管理的与代码直接相关的技术债务类型及其实例, 以及支持的管理活动及具体实现方法, 并将 VS 与 4 种专门的技术债务管理工具进行比较分析。结果表明, 尽管 VS 不能对项目中具体技
17、术债务实例实现完整的管理过程, 但是相比已有的技术债务管理工具, VS 能够采取多种方法对项目中与代码直接相关的技术债务进行不同程度的有效管理, 从而更好地改善软件质量。本文第 2 节结合我们之前所做的技术债务映射研究5, 介绍按照软件开发生命周期中不同阶段划分的技术债务类型, 概述技术债务管理过程中的各项活动;第 3 节依据本文的研究目的, 提出研究问题, 设计研究过程;第 4 节展示 VS 管理技术债务能力的研究结果, 回答研究问题;第 5 节讨论技术债务管理对开发团队的指导意义, 指出 VS 在技术债务管理方面的优点与不足, 以及本文研究的局限性;最后总结全文并指出未来的工作方向。2 技
18、术债务管理本节主要根据软件生命周期的不同阶段和技术债务的成因, 对目前所了解的技术债务进行详细的分类并对分类结果进行呈现, 同时介绍技术债务管理活动和相应的管理方法。2.1 技术债务的类型对技术债务进行有效的管理, 首先要明确技术债务的具体类型以及成因, 了解在软件开发过程中不良的技术决策可能会引入的技术债务, 从而在软件项目中识别技术债务的存在, 并对其进行管理。技术债务的类型是指技术债务的一个特定分类 (如架构、设计、代码、测试) 以及进一步基于技术债务成因的一个子类 (如代码方面的技术债务可能是由重复的代码导致的) 。在我们之前所做的映射研究5中, 根据软件开发生命周期的不同阶段将具体技
19、术债务分为 10 类, 并依据技术债务的成因列举了几个子类。(1) 需求 TD:在领域假设和约束下, 最优需求规范和实际系统实现之间的差距。例如, 过度需求使系统变得复杂冗余, 同时缺陷产生的可能性增大, 不仅降低了系统的可维护性, 而且增加了实现成本。(2) 架构 TD:由架构决策导致的, 在诸如可维护性等内部质量方面做出的妥协。架构 TD 包括架构模块之间不良的依赖关系, 以及一些典型的架构坏味 (Architecture Smells) , 如连接器嫉妒 (Connector Envy) 12, 即组件覆盖了太多本应委托给连接器的交互相关功能 (通信、协调、转换、促进优化) , 这种耦合
20、了连接器功能的组件会降低系统的重用性、可理解性和可测试性。(3) 设计 TD:在详细设计中采取的一些技术妥协, 如复杂的类或方法。这些设计 TD 会降低系统的可理解性、可重用性13。(4) 代码 TD:编写欠佳的代码, 违反了编码最佳实践或编码规则。比如, 代码重复会加大软件系统更改的难度, 因为必须找到并更新多个代码片段。代码 TD是技术债务相关文献中最普遍提及的类型, 大部分工具也被用于管理代码 TD。(5) 测试 TD:测试中采取的一些捷径。比如, 缺少测试 (单元测试、集成测试等) ;低代码覆盖率, 即测试代码对被测试功能代码分支的覆盖程度低。(6) 构建 TD:软件构建系统中存在的,
21、 或是使软件构建过程过于复杂和困难的缺陷。如不良的构建依赖, 一方面, 构建并维护系统中不必要的依赖关系会降低系统整体的构建和测试速度;另一方面, 低层文件库在移除高层文件库中未声明的依赖时会丢失一些必需的依赖关系, 进而导致构建的破损14。(7) 文档 TD:软件开发中任何不充分、不完整或者过期的文档, 如过期的架构文档, 缺少代码注释等。(8) 基础设施 TD:与开发相关的过程、技术、支持工具等方面的次优配置。次优的配置 (如使用旧技术) 会降低团队开发高质量产品的能力。(9) 版本控制 TD:源代码版本控制的问题, 如不必要的代码分支15。(10) 缺陷 TD:软件系统中发现的缺陷、漏洞
22、或者故障。这一技术债务类型是根据已有文献归纳所得, 但对这一类型的技术债务存在争议。我们认为, 缺陷、漏洞和故障会直接影响到最终用户的使用体验, 不属于技术债务的范畴。明确的技术债务分类不仅有利于对技术债务进行有针对性的管理, 而且有助于不同角色的利益相关者 (如需求工程师、架构师、编程人员、测试工程师) 关注他们所参与的软件开发阶段中可能产生的技术债务。2.2 技术债务管理活动如不对技术债务加以管理, 将会对软件系统的开发和维护造成不利的影响, 包括降低软件产品的质量, 增加后期维护及更新的成本, 降低开发团队的工作效率等。因此, 管理控制软件系统中的技术债务是非常必要的。技术债务管理由一系
23、列可预防潜在技术债务的发生以及对现有技术债务进行处理以使其保持在合理程度的活动组成。下面将详细介绍技术债务管理活动, 并且针对不同的管理活动列举一些可用的方法, 为软件项目的开发者管理技术债务提供指导和支持。(1) TD 识别:通过特定技术, 检测软件系统中由欠佳的技术决策所导致的技术债务16。例如, 通过源代码分析方法识别出违反编码规则的部分;基于源代码计算软件度量值, 识别设计问题;通过分析不同类型软件元素 (组件、模块等) 之间的依赖性, 可识别诸如循环依赖等技术债务。(2) TD 度量:利用估算方法来量化软件系统中已知技术债务的效益和成本, 或者估量系统的整体技术债务水平。通过源代码的
24、度量值、数学方程和模型计算技术债务;依照经验和专业知识, 人为估计17技术债务。(3) TD 表示/文档化:以统一的方式表示和记录技术债务技术债务项, 进而引起特定利益相关者的关注。“技术债务项”是软件系统中的技术债务单元, 通常包含唯一 ID 标识、位置信息、偿还负责人、技术债务类型以及描述信息。(4) TD 优先级排序:依照某些预定义的规则对已识别的技术债务项排序, 以此来决定应优先偿还的技术债务项或可暂时搁置的技术债务项。技术债务优先级排序可使用成本/效益分析方法, 优先偿还具有更高的偿还成本/收益比的技术债务项, 即如果解决一个技术债务项可产生更高的效益, 则偿还该技术债务项18。(5
25、) TD 预防:目的是预防潜在技术债务的产生。可通过改善当前的开发过程来预防技术债务的引入;或使用架构决策支持方法, 即估计不同架构设计决策可能导致的潜在技术债务, 然后选择有较少潜在技术债务的决策19。(6) TD 监测:观察系统中尚未解决的技术债务以及它的成本和效益随时间的变化情况。可采用基于阈值的方法为技术债务的相关质量度量值设置阈值, 如未达到阈值则发出警告20;或根据系统所包含的技术债务以及组件之间的依赖关系, 跟踪技术债务的传播11。(7) TD 偿还:通过再工程或重构等方法, 彻底解决或减轻软件系统中的技术债务。重构是最常见的技术债务偿还方法, 即改善软件系统的内部质量, 对软件
26、的代码、设计或架构做出相应的改变, 以适应未来软件维护和发展的需要, 但是重构并不改变软件系统的外部行为;自动化也是一种技术债务偿还方法, 通过将需手动重复的工作 (如手动测试、手动部署) 自动化, 进而改进系统的可维护性, 提高了开发效率和质量。(8) TD 交流:使已识别的技术债务对利益相关者可见, 这样有利于开发团队的讨论和管理。如可视化代码度量值或依赖关系, 高亮显示组件中技术债务的位置。实际上, 技术债务管理的目标并不是项目零债务。好的技术债务管理是对商业目标和软件质量的平衡, 若一味追求质量上的完美, 可能会对软件开发的效率、可持续性, 甚至战略目标造成严重的阻碍。在有限的资源条件
27、以及竞争激烈的市场环境下, 系统存在技术债务是不可避免的。从商业的视角看来, 减少项目的技术债务、改善软件的内部质量, 只有在其能增加收益的情况下才是有效的。然而, 如果所累积的技术债务阻碍了软件新功能的增加, 可能会迫使公司暂时停止增加项目的商业价值, 转而投入全部的精力来维护系统的运营。简而言之, 如果不对技术债务加以管理, 企业在该项目上可能会停止获利21。3 研究设计本节主要阐述本文研究的目的, 并依据研究目的提出研究问题, 设计对 Visual Studio 管理技术债务能力的研究过程。3.1 研究目的和研究问题本文的研究目的是更好地理解技术债务管理的相关理论与实践, 以便在实际软件
28、开发中利用主流集成开发环境 VS 对技术债务的管理能力, 提高软件的质量和可维护性。这种能力主要体现在两方面:它能够管理的技术债务类型和具体实例的广泛性, 以及它对不同技术债务类型的管理程度, 包括可采取的方法和技术。基于该研究目标, 定义以下研究问题 (Research Question, RQ) 。RQ1:Visual Studio 支持对哪些技术债务类型的管理?通过此研究问题, 我们希望明确 VS 具备管理哪些类型的技术债务的能力;并进一步明确对于不同的技术债务类型, VS 可具体管理的技术债务实例。RQ2:Visual Studio 支持哪些技术债务管理活动?通过此研究问题, 我们希望
29、理解 VS 对技术债务管理的支持力度, 以及 VS 实现每个技术债务管理活动的具体操作。RQ3:Visual Studio 与专门的技术债务管理工具在技术债务管理能力上有何不同?通过此研究问题, 我们希望了解相比专门的技术债务管理工具, VS 在能够管理的技术债务类型和支持的技术债务管理活动方面所体现的优势和不足。3.2 研究过程对 VS 的实践研究所使用的案例是作者实验室一个现有的 C#项目。之所以选择编程语言为 C#的项目, 是考虑到 VS 的核心是基于.NET 框架开发的, 而 C#是由微软所开发的编写.NET 框架的程序设计语言。对于 C#项目, VS 所能提供的功能将会更加全面。我们
30、之前所做的映射研究5的结果显示:大部分相关文献所研究的技术债务类型集中于代码、设计和架构 3 个方面;同时, 由于 VS 集成开发环境主要适用于对代码的开发和管理, 并且提供了对项目较为完整的测试体系, 因此本文主要针对代码 TD、设计 TD、架构 TD 以及测试 TD 这 4 种类型来探究 Visual Studio的技术债务管理能力。为了实现上述目标, 将依照以下步骤对 VS 进行案例实践研究:首先, 在 VS 中打开该 C#项目, 并将其源代码作为输入;然后, 按从左至右、从上至下的顺序了解 VS 的每个菜单功能项, 重点关注能帮助改善代码质量以及开发过程的相关功能;接着, 在实际操作之
31、前, 先绘制一个二维的技术债务类型及其管理活动的对应表, 以便记录考查结果;最后, 对 C#项目依次运行每个功能项, 并对照已有的技术债务类型和管理活动来判断该功能是否适用于技术债务及其管理, 如果适用, 则在表中类型和活动相对应的位置详细地记录下运行结果、技术债务实例、使用管理方法或技术、VS 的功能操作。我们之前所做的技术债务映射研究5中总结了研究文献中所提出、使用或开发的可实现技术债务管理目的的工具。本文选择其中专门用于技术债务管理的 4种工具 (Software maps tool22, Technical Debt Evaluation plugin for SonarQube23,
32、 DebtFlag24, Sonar TD plugin25) , 分别探究它们能够管理且与代码直接相关的技术债务类型以及采取的相应管理活动, 将结果汇总并与 VS 的管理能力进行比较。在第 4 节的研究结果中, 将根据这些实验结果以及汇总数据具体分析并回答在3.1 节中所提出的与 VS 管理技术债务能力相关的研究问题。4 研究结果依照 3.2 节所描述的实验过程对 Visual Studio 管理技术债务的能力进行研究。4.1 节和 4.2 节分别展示 VS 支持的技术债务类型和管理活动, 对应回答了 3.1节提出的 RQ1 和 RQ2;4.3 节展示了 VS 与 4 种技术债务管理工具对比
33、汇总后的研究结果, 回答了 RQ3。4.1 VS 可管理的技术债务类型 (RQ1) 相比大部分工具是针对某种特定类型的技术债务, 本文探究到 VS 集成开发环境可以管理的具体技术债务种类较为广泛, 尤其对于项目中架构、设计、代码、测试等方面的技术债务。表 1 列出了 VS 所涉及的具体技术债务种类和实例。表 1 技术债务类型和实例 下载原表 下面对几种关键且难以理解的技术债务实例给予说明。(1) 不良的依赖关系VS 中可以通过创建代码图将代码元素 (如类、程序集) 之间的依赖关系可视化, 帮助开发者理解代码结构, 同时可以发现结构中不良的依赖关系, 这对于大型复杂项目的开发和维护尤其重要。通过
34、代码图不但可以查看整体依赖关系, 还可以对指定元素查看更深层次的代码依赖关系, 直到类和成员级别。利用 VS 提供的代码图分析器, 能识别出代码中可能存在的循环依赖、依赖项过多、无依赖项这 3 种潜在的技术债务。出现循环依赖或依赖项过多的代码段不利于更改、测试和重用, 需要考虑对其进行重构。对于无依赖项, 需要判断它是必需的代码段还是无用的代码段。为本文的 C#项目创建代码图, 分别检测在项目的不同层次 (架构、设计) 上是否存在不良的依赖关系。图 1 给出了 VS 创建的代码图以及运行的依赖关系分析器。由于本项目中不存在循环依赖, 因此代码图中没有呈现。除了代码图, 代码度量值中类耦合度、继
35、承深度亦可帮助识别并度量代码中存在过度依赖关系的设计 TD, 本文将在 4.2 节的代码度量值部分具体介绍。图 1 代码图及分析器 下载原图(2) 代码与预期架构冲突VS 的层关系图是对软件项目中的高级结构 (模块、组件或功能单元) 及其相互作用的展示。通过层关系图可以自动检验项目的代码是否与设计的系统架构冲突。如果存在冲突, 则提示验证错误以及错误出现的原因, 如无效的依赖关系、依赖于禁止的命名空间等。导致冲突的原因有很多, 例如, 修改设计的架构时未对相应的代码做出一致的更改, 将系统组件分配到错误的层, 与预期设计相冲突的依赖关系等。使用层关系图验证系统架构, 有利于架构设计师和开发者在
36、开发过程中尽早发现潜在的架构技术债务, 进而通过重构或重写等方法更新代码以使其符合预期的架构。(3) 编码规则冲突编码规则是为了增强代码的稳定性、可读性、可维护性并提高编码质量与效率而设置的标准。VS 中可自行选择一系列内置的编码规则集, 通过运行代码分析, 能检测并以列表形式标识出在应用程序中与编码规则冲突的问题, 并给予一些修复建议。例如, 在 VS 的编码规则集中, “基本的设计准则规则”能识别项目中存在的一些影响可理解性和可维护性的缺陷, 如标示符的不规范拼写、意义不明确的命名等。图 2 是对 C#运行代码分析后识别出的编码规则冲突。图 2 编码规则冲突 下载原图(4) 重复代码重复代
37、码是项目中经常存在的一种代码技术债务, 降低了代码的可变性和重用性。在 VS 中, 通过“分析代码克隆”可检测部分范围或整个项目中的重复代码, 结果依据相似性程度展示。图 3 给出了“分析克隆代码”功能检测到的 C#项目中的重复代码。VS 能查找到的代码重复不仅限于完全相同的代码段, 还包括改写程度不超过 40%的相似代码段, 如插入、删除或重新排列部分语句, 更改变量以及参数的命名。图 3 重复代码检测 下载原图在对代码进行更新或修复前, 检测其是否存在重复片段, 以避免由于不一致的更改而造成错误;同时, 开发者可以考虑是否对重复代码进行重构或清理。4.2 VS 实现的技术债务管理活动 (RQ2) VS 实现了对技术债务的识别、度量、优先级排序、预防、监控、偿还和交流, 已经很大程度地突破了大部分工具的局限。对某些类型的技术债务不仅可以定性地管理, 还可以定量地检测和分析, 如识别并度量不良的依赖关系。表 2 列出 VS 中可用于技术债务管理的具体方法。
