2010年7月4日
第8卷，第7期

代码地图在软件开发中的应用

那些无处不在的手绘代码图会成为过去式吗？

Robert DeLine、Gina Venolia 和 Kael Rowan，微软研究院

软件开发人员经常绘制其系统的图表。为了了解图表绘制如何融入开发人员的日常工作，请考虑这个虚构但具有代表性的故事

简是一位开发人员，她在团队工作的时间太长了，以至于每个人都称她为团队历史学家。由于产品几周前才刚刚发布，简终于可以着手进行她计划已久的代码清理工作了——即删除对不再支持的库的依赖。简使用她的开发环境搜索产品中使用不受支持的库的所有位置。她逐个点击结果，并阅读代码以了解它如何使用该库。当她在代码库中跳转时，她在笔记本上草绘了一个类图，以捕捉她发现的架构依赖关系。

在这项代码理解任务进行到一半时，有人敲门。是乔，团队的最新成员。他正在处理一个错误，并且对产品功能的实现方式感到困惑。作为团队历史学家，简已经习惯了这类问题。他们首先查看贴在简的电脑附近的墙上的一张架构图开始对话。为了更具体，简在白板上绘制了该图的一个版本，只草绘了架构的相关部分，但比印刷图更详细。当她向乔讲解一个用例时，她在图上叠加箭头，以显示系统的不同部分如何交互。她不时地在她的开发环境中调出相关的代码，将图表与代码联系起来。

几分钟后，乔觉得自己理解了设计，然后回到自己的办公室。简回到自己的工作。在探索搜索结果和回答乔的问题之间，简的开发环境现在有几十个打开的文档。简试图恢复她的任务，但无法在所有混乱中找到她离开的地方。她关闭了所有打开的文档，重新发出原始搜索，在搜索结果中找到她的位置，并继续探索对不受支持的库的依赖。

这个故事说明了图表绘制实践的广泛性。图表的质量从草图到高质量海报不等；形式从独特的涂鸦到定义明确的符号不等；寿命从单个任务的持续时间到整个发布周期不等；受众从个人使用到锚定对话，再到与整个团队或用户社区沟通不等。

尽管故事中说明的实践是广泛且有用的，但在软件可以改进的地方仍然存在一些缺点。首先，图表通常不与代码关联。从架构级别到代码级别的讨论需要切换工具——例如，从白板到开发环境。这种分离也导致了较差的任务支持。例如，简的代码搜索和笔记本图表没有以任何方式联系在一起。两者很容易不同步，并且不能一起存储或检索，就像简的图表在任务恢复期间可用，但她的搜索结果已消失一样。

其次，团队级文档和特定于任务或对话的图表之间没有过渡。例如，简必须在白板上重现海报的部分内容，才能回答乔的具体问题。第三，在帮助处理简在恢复任务时面对所有打开的文档而感到迷失方向方面，存在错失的机会。

在一个大型代码库中迷路太容易了。代码由成千上万个符号组成，几乎没有视觉地标来引导视线。当开发人员浏览代码时，她会跟随超链接，例如从方法调用者跳转到被调用者，而没有视觉过渡来显示跳转的落点。她导航得越多，文档选项卡的堆积就越多。这些导航步骤不仅仅是为了编辑代码。软件开发人员在编程任务期间也经常需要信息。^8,9 为了尝试找到答案，他们在代码和其他文档中浏览，这会将相关和不相关的文档都添加到环境的工作集中。由于如此多的不连续导航，开发人员很容易变得迷失方向。

开发环境中对代码图表的更好支持可以支持代码理解和沟通，并且可以充当“地图”来帮助开发人员保持方向。软件可视化社区之前已经探索了不同类型的地图，例如用于程序理解和分析项目数据的可缩放框线图¹⁰ 和城市景观，¹¹。这些地图通常旨在补充标准开发环境。我们的目标是将地图集成到开发环境中，以便开发人员可以在地图中执行大多数任务。

为了解决这些问题，我们采用以用户为中心的方法，正在为开发环境设计交互式代码地图。在我们的初步设计准备阶段，我们在微软公司进行了一系列实地研究。我们采访了开发人员，了解他们如何以及为什么绘制代码图，并在此过程中收集了许多示例图。³ 我们还直接观察了开发人员的工作，以观察他们的信息寻求行为，并对他们的信息需求进行分类。⁸ 最后，我们对基于纸质的代码地图进行了参与式设计，以允许开发团队设计其内容和外观，并见证它如何支持他们的对话。¹ 利用这三项研究的见解，我们正在积极原型化 Code Canvas，这是一个微软 Visual Studio 插件，它用可缩放的代码地图替换了选项卡式文档。⁵

开发人员如何以及为何绘制图表

为了更好地理解专业软件开发人员如何使用代码的可视化表示，我们采访了微软的九位开发人员，以确定常见的场景，然后调查了 400 多位开发人员，以更深入地了解这些场景。³ 最常提及的三个场景是

理解现有代码。 检查源代码及其行为，以发展对其的理解。
设计/重构。 计划如何实现新功能、修复错误或使程序结构更好地匹配其功能。
临时会议。 请同事解释现有代码、审查决策或帮助解决问题。

开发人员将这三个场景评为他们工作职能中最重要的场景。超过一半的受访者表示，图表在这些场景中很重要。大多数临时会议规模都很小，涉及两人或最多五人。虽然理解现有代码和设计/重构通常是单独完成的，但令人惊讶的是，它们经常涉及两人或小组。

在一项单独的研究中，我们试图了解开发人员在执行开发任务时的信息需求。⁸ 我们观察了微软的 17 位开发人员，每人约 90 分钟，手动记录了他们每分钟的活动，并将这些日志编码为 334 个信息寻求行为实例。从这些数据中，我们确定了 21 个一般信息需求，分为七个工作类别。与之前的研究一致，我们发现他们的许多信息需求都属于理解执行行为和推理设计类别，总结在表 1 中。

表 1. 与图表绘制行为相关的信息需求

理解执行行为	推理设计
什么代码可能导致了这种行为？什么静态地与这段代码相关？什么代码导致了这种程序状态？	这段代码的目的是什么？程序应该做什么？这段代码为什么以这种方式实现？这种更改的含义是什么？

在我们的观察中，与同事进行临时沟通是解决各种信息需求的常用方法。与同事交谈最常解决的信息需求包括以下内容

我的同事们一直在做什么？
这种更改的含义是什么？
这个问题值得修复吗？
程序应该做什么？
这种故障在什么情况下发生
我依赖的资源发生了什么变化？
什么代码可能导致了这种行为

这种对与同事对话的依赖与图表绘制研究中的临时会议场景相符。

从这两项研究中，我们知道开发人员在尝试理解现有代码和计划代码更改时，有频繁、特定的信息需求，并且他们经常在使用图表寻找答案时。这表明代码地图可能很有用，它可以直接或通过交互来回答这些需求。我们也知道，开发人员经常求助于同事来找到他们需要的答案，并且他们会创建图表来补充他们的对话。这表明代码地图应该在队友之间共享，以便他们拥有共同的空间参考框架。

设计代码地图

问题仍然存在，代码地图应该是什么样子？我们收集了许多开发人员代码可视化表示的示例，并确定了他们使用的视觉约定。³ 这些范围从白板上的草图到使用绘图工具精心制作的图表。我们还研究了开发人员在表示代码时使用的视觉约定。² 框箭头图是迄今为止最常见的表示形式，其中每个框代表某种软件实体，每个箭头表示两个实体之间的关系。框通常被标记，但箭头几乎从不标记。

其中一些图表随意使用了视觉符号，例如 UML（统一建模语言），但这并不常见。邻接有时用于指示两个实体之间的关系。通常，框的排列使得关系以或多或少有序的方向流动，从上到下或从左到右。高级分组由周围的框或曲线或分隔线指示。这些视觉约定为代码地图的设计提供了起点。

有了这些一般知识，我们与一个名为 Oahu（化名）的软件开发团队紧密合作，开发了代码地图的纸质原型。² Oahu 团队由数十人组成，致力于一个大约 75,000 行 C# 代码的孵化项目。我们首先让每位开发人员分别在一张大纸上草绘 Oahu 项目。图 1 显示了其中四个草图。接下来，我们将草图中出现的共同特征和有趣的例外情况综合成一张主图。在几周的时间里，我们重复了一个每日循环，我们在其中打印这张图，将其挂在开发人员的办公室里，采访团队成员以了解他们的更改和使用报告，然后根据他们的反馈修改图纸。应他们的要求，我们使用为此目的开发的工具，将从他们的代码中逆向工程的类型和方法签名纳入其中。

图 1. Oahu 系统的四个图表

通过这个过程，我们得到了一个设计（图 2），它以对团队有意义的方式表示代码。最终设计基本上是一个架构层图，点缀着包含方法签名的类型（白色框）。它密切遵循了我们在早期研究中发现的视觉约定。它还包括一些在架构图中不常见的特征，例如计划但不存在的代码的表示（例如，移动电话下方的空白白色框）、彩色标识符片段以帮助视觉搜索（我们称之为概念关键字着色）以及表示跨越架构层的概念的垂直条带。

图 2. 通过团队参与设计的 Oahu 代码地图

标注显示了全分辨率下的地图。虚线矩形是图 3 中显示的地图区域。

从这些研究中，我们了解到可以从一组简单的视觉约定设计代码地图。Oahu 代码地图表明，单个地图可以以对团队所有开发人员都有意义的方式表示整个软件项目。团队对地图的反应褒贬不一。Oahu 团队的两名新员工广泛使用该地图作为其“入职”过程的一部分，经常研究和注释它。其他团队成员提出了一些批评，所有这些批评都源于缺乏交互。他们希望根据讨论的需要调整细节级别和元素位置，以更改任务的内容（例如，向地图添加调用图）。我们能够在我们的 Code Canvas 中解决所有这些问题，如下所述。

以地图为中心的开发环境

我们将这些研究的见解融入到 Microsoft Visual Studio 的原型用户界面中，称为 Code Canvas，它使代码地图成为开发体验的中心隐喻。⁵ Code Canvas 没有依赖选项卡式文档和分层概述来导航和编辑代码，而是将项目的所有文档（代码文件、图标、用户界面设计等）放置在可平移、缩放的代码地图上。用户可以缩小以获得项目结构的概览，并放大以查看或编辑代码和其他文档。（Code Canvas 的视频可在此处观看：此处。）

我们根据我们在 Oahu 团队的经验设计了 Code Canvas 地图的外观。图 3 显示了加载到 Code Canvas 中的 Oahu 项目，特别是 UI 层的左上角（图 2 中用虚线矩形指示的区域）。使用 Oahu 地图的视觉约定，Code Canvas 地图将类型显示为白色框，标识符使用概念关键字着色进行标记，并将类型组织成标记的条带（PopupMenu、Reminders 等）。Code Canvas 中类型和概念框的位置与 Oahu 地图中的布局相同。

图 3. Oahu 地图的 Code Canvas 版本

该地图的焦点位于 UI 层的左上角，并包含两个叠加层：黄色的搜索结果和一系列红色箭头的执行跟踪。标注显示了放大到方法以编辑其代码的结果。

从 Oahu 研究中获得的一个重要教训是，开发人员为代码的空间布局赋予了意义。因此，Code Canvas 采用混合主动布局方法。用户可以通过直接操作在地图上放置任何框，但 Code Canvas 也使用 MSAGL（Microsoft 自动图布局）引擎为新代码地图提供初始布局，并在用户随后更改布局时防止遮挡和维护关系。

Code Canvas 使用一种称为语义缩放的技术，以在不同的缩放级别显示不同的细节级别。在 10% 的缩放级别，代码本身是不可见的，因为其大小小于每行一个像素，但类型名称和成员名称以可读的大小显示。图 3 中的标注显示了 100% 的缩放级别，其中代码文件本身使用标准编辑器显示，标准编辑器提供常用的语法格式和着色以及代码完成等标准编辑器功能。在中间缩放级别，代码变得可见，首先以骨架形式（以 Seesoft⁶ 的风格，Seesoft 是 1990 年代早期一种著名的软件可视化工具），然后以可读文本形式可见。

为了了解 Code Canvas 的功能，让我们重播一下最初的故事。

简的开发环境显示了整个项目的概览地图，称为 HOME 画布。它的布局对她来说就像她的家乡一样熟悉，因为她多年来一直在两者之间移动。为了开始她理解项目对不受支持的库的依赖的任务，她搜索了库的使用情况。搜索结果以黄色框叠加在地图上（如图 3 所示），并列在单独的窗口中。她立即看到了代码中依赖于该库的两个部分。她放大其中一个部分，以更仔细地查看究竟涉及哪些类，然后单击单个搜索结果以查看代码本身。

以这种方式探索了一段时间后，她决定只关注相关的代码，因此她在新选项卡中创建了一个新的“过滤画布”，其中包含搜索结果的代码子集，保持空间关系以帮助她保持方向。与 HOME 画布一样，过滤画布上的代码显示在表示相关类和接口的框内。本质上，此过滤画布充当简之前在笔记本上绘制的类图，但在此处，搜索结果和类图会自动保持同步并持久保存在一起。

乔敲门并向简提问。她点击 HOME 画布选项卡，缩小，并指向其中的部分内容以支持她所说的话。HOME 画布在所有团队成员之间共享，正是为了提供团队可以围绕其进行讨论的共同基础。为了解释乔感到困惑的功能，简设置了一个调试器断点并运行程序。当达到断点时，Code Canvas 使用一系列红色执行箭头显示调用堆栈，如图 3 中的箭头所示。然后，简创建了第二个过滤画布，专注于此调用堆栈。她缩小以向乔介绍该功能中涉及的代码部分。当乔询问有关算法的详细问题时，简会放大相关的代码。当与乔的对话结束后，简只需关闭新选项卡并返回到她正在工作的选项卡，该选项卡看起来与她离开时完全一样。

简而言之，Code Canvas 通过多个画布提供显式任务支持，并使用稳定的空间布局来保持用户定向。这些设计目标与布朗大学的 Code Bubbles 项目共享。¹ Code Bubbles 的策略是从一个空画布开始，并在用户搜索和浏览项目时添加项目。相比之下，Code Canvas 从概述开始，并允许用户过滤到感兴趣的项目。在我们未来的工作中，我们将探索这两种方法的混合。

结论

根据我们在实地研究中观察到的工作实践，我们相信使代码地图成为开发环境用户界面的中心有望减少迷失方向，回答常见的信息需求，并锚定团队对话。空间记忆和推理在今天的软件开发人员中很少使用。在我们之前版本的代码地图设计的基于实验室的评估中，我们表明开发人员在 90 分钟的编程任务会话中形成了可靠的代码地图空间记忆。⁴ 通过利用这些认知资源，代码地图将使开发人员更好地扎根于代码中，无论是单独工作还是协作工作。我们相信，这将从根本上改变和改善软件开发体验。
问

参考文献

Bragdon, A., Reiss, S. P., Zeleznik, R., Karumuri, S., Cheung, W., Kaplan, J., Coleman, C., Adeputra, F., LaViola Jr., J. J. 2010. 代码气泡：重新思考集成开发环境的用户界面范例。载于第 32 届国际软件工程会议论文集。
Cherubini, M., Venolia, G., DeLine, R. 2007. 构建生态上有效的大型图表，以帮助开发人员在他们的代码中保持方向。载于IEEE 视觉语言和以人为中心的计算研讨会论文集（9 月）。
Cherubini, M., Venolia, G., DeLine, R., Ko, A. J. 2007. 让我们去白板：软件开发人员如何以及为什么使用绘图。载于SIGCHI 人为因素计算系统会议论文集（5 月）。
DeLine, R., Czerwinski, M., Meyers, B., Venolia, G., Drucker, S., Robertson, G. 2006. 代码缩略图：使用空间记忆来导航源代码。载于IEEE 视觉语言和以人为中心的计算研讨会论文集。
DeLine, R., Rowan, K. 2010. 代码画布：朝着更好的开发环境迈进。载于国际软件工程会议（新思想和新兴成果）论文集（5 月）。
Eick, S. C., Steffen, J. L., Sumner Jr., E. E. 1992. Seesoft：一种用于可视化面向行的软件统计信息的工具。IEEE 软件工程汇刊 18(11): 957-968。
Kersten, M., Murphy, G. C. 2006. 使用任务上下文来提高程序员生产力。载于 第 14 届 SIGSOFT 国际软件工程基础研讨会论文集：1–11。
Ko, A. J., DeLine, R., Venolia, G. 2007. 协同软件开发团队中的信息需求。载于第 29 届国际软件工程会议论文集（5 月）。
Sillito, J., Murphy, G. C., De Volder, K. 2008. 在编程更改任务期间提出和回答问题。IEEE 软件工程汇刊。
Storey, M. A., Best, C., Michaud, J., Rayside, D., Litoiu, M., Musen, M. 2002. SHriMP 视图：用于信息可视化和导航的交互式环境。载于人为因素计算系统会议论文集。
Wettel, R., Lanza, M. 2007. 将软件系统可视化为城市。载于 IEEE 软件可视化理解与分析国际研讨会论文集。

喜欢它，讨厌它？请告诉我们

[email protected]

Robert DeLine (http://research.microsoft.com/~rdeline) 是微软研究院的首席研究员，致力于软件工程和人机交互的交叉领域。他的研究小组以用户为中心的方式设计开发工具：他们对开发团队进行研究，以了解他们的工作实践并原型化工具以改进该实践。

Gina Venolia (http://research.microsoft.com/~ginav) 是微软研究院人机交互编程组的高级研究员。她的研究重点是构建使知识在人与人之间更自由流动的系统。她正在研究分布式软件团队，并开发利用空间记忆来支持导航和团队意识的系统。

Kael Rowan (http://research.microsoft.com/~kaelr) 是微软研究院的高级研究软件设计工程师，专注于下一代软件开发，包括软件可视化和源代码的空间布局。他的背景涵盖从操作系统内部和形式化软件验证到现代用户界面和 HCI。

最初发表于 Queue 第 8 卷，第 7 期—
在数字图书馆中评论本文

更多相关文章

David Crandall, Noah Snavely - 使用互联网照片集建模人和地点
本文介绍了我们使用在线照片集重建关于世界及其居民在全球和本地范围内信息的工作。这项工作是由社交内容共享网站的显着增长推动的，这些网站创建了大量的用户生成视觉数据在线集合。仅 Flickr.com 目前就托管了超过 60 亿张由超过 4000 万唯一用户拍摄的图像，而 Facebook.com 表示其每天增长近 2.5 亿张照片。

Jeffrey Heer, Ben Shneiderman - 用于可视化分析的交互式动态
数字数据规模和可用性的增加为公共政策、科学发现、商业策略甚至我们的个人生活提供了非凡的资源。然而，为了充分利用这些数据，用户必须能够理解它：追求问题、发现感兴趣的模式以及识别（并可能纠正）错误。与数据管理系统和统计算法相结合，分析需要针对领域特定意义的背景化人类判断，这些判断关于数据中发现的集群、趋势和异常值。

Brendan Gregg - 可视化系统延迟
当 I/O 延迟以可视化热图的形式呈现时，可能会出现一些有趣而美丽的模式。这些模式提供了对系统实际运行情况以及最终用户应用程序体验到的延迟类型的深入了解。在这些模式中看到的许多特征仍然不为人所知，但到目前为止，它们的分析揭示了以前未知的系统行为。

Jeffrey Heer, Michael Bostock, Vadim Ogievetsky - 可视化动物园巡览
由于传感、网络和数据管理方面的进步，我们的社会正在以惊人的速度产生数字信息。据估计，仅在 2010 年，我们将生成 1200 艾字节——是美国国会图书馆内容量的 6000 万倍。在这场数据洪流中，蕴藏着关于我们如何开展业务、政府和个人生活的宝贵信息。为了充分利用这些信息，我们必须找到有意义地探索、关联和交流数据的方法。