ACM通信
实践
使用代码映射进行软件开发
Oahu代码地图表明，单个地图可以以一种对团队中所有开发人员都有意义的方式表示整个软件项目。
软件开发人员经常为他们的系统绘制图表。为了了解图表如何适合开发人员的日常工作，考虑下面这个虚构的但具有代表性的故事:
Jane是一名开发人员，她在自己的团队中工作了很长时间，以至于大家都称她为团队历史学家。由于该产品几周前刚刚发布，Jane终于开始着手做一些她计划多年的代码清理工作，即放弃对不再受支持的库的依赖。Jane使用她的开发环境搜索她的产品使用不受支持的库的所有地方。她一个接一个地单击结果并阅读代码以了解它如何使用库。当她在代码库中跳跃时，她在记事本上画了一个类图，以捕获她发现的体系结构依赖性。
在这个代码理解任务进行到一半时，有人敲门。是乔，我们队的新成员。他正在处理一个bug，对产品的一个特性是如何实现的感到困惑。作为团队的历史学家，简已经习惯了这类问题。他们看着简电脑旁边墙上钉着的一张建筑图，开始了对话。为了深入了解细节，Jane在白板上画了一个版本的图表，只画了架构的相关部分，但比打印出来的图表更详细。当她向Joe讲解用例时，她用箭头覆盖了图，以显示系统的不同部分如何交互。她不时地在开发环境中提出相关代码，以便将图与代码关联起来。
几分钟后，Joe确信自己理解了设计，并返回了他的办公室。简继续做她自己的工作。在探索搜索结果和回答Joe的问题之间，Jane的开发环境现在有几十个打开的文档。简试图继续她的工作，但在所有的混乱中找不到她停下的地方。她关闭所有打开的文档，重新发布最初的搜索，在搜索结果中找到自己的位置，并继续探索对不受支持的库的依赖。
这个故事说明了绘图实践的广泛范围。图表的质量范围从草图到高质量的海报;在形式上，从特殊的涂鸦到定义明确的符号;在寿命方面，从单个任务的持续时间到整个发布周期;在观众中，从单独使用，到固定对话，到与整个团队或用户社区交流。
尽管在这个故事中说明的实践是广泛的和有用的，有一些缺点，软件可以改进。首先，图表通常不与代码绑定。从架构级到代码级的讨论需要转换工具，例如，从白板到开发环境。这种分离还会导致较差的任务支持。例如，Jane的代码搜索和记事本图没有以任何方式联系在一起。这两者很容易不同步，不能一起存储或检索，就像Jane的图表在任务恢复期间可用，但她的搜索结果不见了。
其次，在团队级文档和特定于任务或特定于对话的图之间没有转换。例如，Jane必须在白板上复制海报的部分内容，以便回答Joe的具体问题。第三，Jane在面对所有打开的文件时，失去了帮助她处理茫然感的机会。
在庞大的代码库中迷失方向太容易了。代码由成千上万的符号组成，几乎没有视觉地标来引导眼睛。当开发人员导航代码时，她遵循超链接，比如从方法调用者跳到被调用者，而没有显示跳转到何处的可视化转换。她浏览的越多，文档标签的堆积就越多。这些导航步骤不仅仅用于编辑代码。软件开发人员在他们的编程任务中也经常需要信息。7，8为了找到答案，他们浏览代码和其他文档，这将向环境的工作集中添加相关和不相关的文档。有了这么多不连续的导航，开发人员很容易迷失方向。
在开发环境中更好地支持代码图可以支持代码理解和通信，并可以作为“地图”帮助保持开发人员的定向。软件可视化社区之前已经探索了不同类型的地图，比如可缩放的框线图9城市风光,10用于诸如程序理解和分析项目数据等任务。这些映射通常用于补充标准开发环境。我们的目标是将地图集成到开发环境中，这样开发人员就可以在地图中执行大多数任务。
为了解决这些问题，使用以用户为中心的方法，我们正在为开发环境设计一个交互式代码映射。在为我们的初始设计做准备时，我们在微软公司进行了一系列实地研究。我们采访了开发人员，以了解他们如何以及为什么要绘制代码图表，并在此过程中收集了许多示例图表。3.我们还直接观察工作中的开发人员，观察他们的信息寻求行为，并对他们的信息需求进行分类。7最后，我们对基于纸张的代码映射进行了参与式设计，以允许开发团队设计其内容和外观，并见证它如何支持他们的对话。1利用这三项研究的见解，我们正在积极地创建Code Canvas的原型，这是一个Microsoft Visual Studio插件，它用可缩放的代码映射替换选项卡文档。5
如何和为什么开发图表
为了更好地理解专业软件开发人员如何使用代码的可视化表示，我们采访了微软的9名开发人员，以确定常见的场景，然后调查了400多名开发人员，以便更深入地理解这些场景。3.最常被提及的三个场景是:
- 理解现有的代码。检查源代码及其行为以发展对它的理解。
- 设计/重构。计划如何实现新功能，修复错误，或使程序结构更好地匹配其功能。
- 临时会议。请同事解释现有的代码，审查一个决定，或帮助解决一个问题。
开发人员将这三项列为对他们的工作功能最重要的。超过一半的受访者表示，图表在这些场景中很重要。大多数临时会议规模很小，只有两个人或最多五个人参加。虽然通常是单独完成，但理解现有代码和设计/重构通常需要结对或小组。
在开发环境中更好地支持代码图可以支持代码理解和通信，并可以作为“地图”帮助保持开发人员的定向。
在另一项研究中，我们试图了解开发人员在执行开发任务时的信息需求。7我们观察了微软17名开发人员每人大约90分钟的时间，一分钟一分钟地手动记录他们的活动，并将这些日志编码为334个信息寻求行为实例。从这些数据中，我们确定了21个一般信息需求，并将其归类为7个工作类别。与之前的研究一致，我们发现他们的很多信息需求都属于理解执行行为而且推理设计,请参阅表1．
在我们的观察中，与同事的特别沟通是解决各种信息需求的常用方法。表2显示通过与同事交谈最经常解决的信息需求。这种对与同事交谈的依赖与临时会议图解研究中的情景。
从这两项研究中，我们知道开发人员在试图理解现有代码和计划代码更改时有频繁的、特定的信息需求，并且他们在寻找答案时经常使用图表。这表明代码映射可以直接或通过交互满足这些需求。我们还知道开发人员经常向同事寻求他们需要的答案，他们创建图表来补充他们的对话。这表明代码映射应该在团队成员之间共享，以便他们有一个共同的空间参考框架。
设计代码图
问题仍然存在，代码映射应该是什么样子?我们收集了许多开发人员代码可视化表示的例子，并确定了他们使用的可视化约定。3.从白板上的草图到用绘图工具精心绘制的图表。我们还研究了开发人员在表示代码时使用的可视化约定。2框-箭头图是迄今为止最常见的表示方式，其中每个框表示某种软件实体，每个箭头表示两个实体之间的关系。盒子通常会被标记，但箭头几乎从不被标记。
其中一些图随意地使用了可视化符号，例如UML(统一建模语言)，但这并不常见。邻接关系有时用来表示两个实体之间的关系。通常情况下，盒子的排列是为了使关系以一种或多或少有序的方向流动，从上到下或从左到右。高级别分组用周围的方框或曲线表示，或用分界线表示。这些可视化约定为代码映射的设计提供了一个起点。
有了这些常识，我们与一个叫做Oahu(化名)的软件开发团队密切合作，开发了一个代码图的纸上原型。2瓦胡岛团队由几十人组成，致力于一个大约75,000行c#的孵化项目。我们首先让每个开发人员分别在一张大纸上勾画瓦胡岛项目的草图。其中四幅草图显示在图1．接下来，我们将草图中出现的共同特征和有趣的例外合成为一个主图。在接下来的几周里，我们每天都重复着这样的循环:打印这张图，把它挂在开发人员的办公室里，采访团队成员的变化和他们如何使用它的报告，然后根据他们的反馈修改这张图。在他们的要求下，我们使用我们为此开发的工具，从他们的代码中反向工程了类型和方法签名。
通过这个过程，我们得到了一个设计(图2)以一种对团队有意义的方式表示代码。最终的设计基本上是一个体系结构层图，其中点缀着包含方法签名的类型(白框)。它非常符合我们在早期研究中发现的视觉惯例。它还包括一些在架构图中不典型的特性，例如计划的，但不存在的代码的表示(例如，移动电话下面的空白框)，着色的标识符片段来帮助可视化搜索(我们称之为关键词彩色化概念)，以及代表跨越建筑层的垂直带。
从这些研究中我们了解到，从一组简单的可视化约定设计代码映射是可能的。Oahu代码地图表明，单个地图可以以一种对团队中所有开发人员都有意义的方式表示整个软件项目。该团队对这张地图的反应褒贬不一。瓦胡岛团队的两名新员工在“入职”过程中广泛使用这张地图，经常对它进行研究和注释。其他团队成员有一些批评，都源于缺乏互动。他们希望根据讨论的需要调整细节级别和元素位置，以更改任务的内容(例如，向映射添加调用图)。我们能够在我们的Code Canvas中解决所有这些问题。
位于开发环境中心的地图
我们已经将这些研究的见解整合到Microsoft Visual Studio的原型用户界面中，称为Code Canvas，它使代码映射成为开发体验的中心隐喻。5code Canvas将项目的所有文档(代码文件、图标、用户界面设计等)放在一个平移、缩放的代码图上，而不是依赖于选项卡文档和分层的概览来导航和编辑代码。用户可以缩小以获得项目结构的概述，放大以查看或编辑代码和其他文档。(代码画布的视频可在http://www.youtube.com/watch?v=tsFfyli2Y9s．)
我们根据与Oahu团队的经验设计了Code Canvas地图的外观。图3显示了加载到Code Canvas中的Oahu项目，特别是UI层的左上角(在中用虚线矩形表示的区域)图2)．使用来自Oahu地图的可视化约定，Code Canvas地图将类型显示为白盒，使用概念关键字着色标记标识符，并将类型组织为标记带(弹出菜单、提醒等)。类型和概念框以与Oahu地图相同的布局放置在Code Canvas中。
来自瓦胡岛研究的一个重要教训是，开发人员为代码的空间布局赋予意义。因此，Code Canvas采用了一种混合的初始布局方法。用户可以通过直接操作在地图上放置任何盒子，但Code Canvas也使用MSAGL(微软自动图形布局)引擎(http://research.microsoft.com/msagl)为新的代码映射提供初始布局，并在用户对布局进行后续更改时防止遮挡和维护关系。
代码画布使用一种称为语义缩放在不同的缩放级别上显示不同的细节级别。在10%的缩放级别下，代码本身是不可见的，因为它的大小每行不到一个像素，但是类型名和成员名以可读的大小显示。的插图编号图3显示100%级别的缩放，其中使用标准编辑器显示代码文件本身，该编辑器提供常用的语法格式化和着色以及代码完成等标准编辑器功能。在中间缩放级别，代码变得可见，首先是一个骨架形式(在Seesoft的风格中，6从20世纪90年代早期开始，这是一个著名的软件可视化工具)，然后是可读文本。
为了了解Code Canvas的特性，让我们重播最初的故事。
Jane的开发环境显示了整个项目的概览图，称为HOME画布。它的布局对她来说就像她的家乡一样熟悉，因为她多年来一直在这两个地方搬家。要开始了解项目对不支持的库的依赖关系，她需要搜索库的使用情况。搜索结果覆盖在地图上的黄色方框中(如图3)，并在一个单独的窗口中列出。她立即看到了依赖于库的两部分代码。她将镜头放大到其中一个，以便更仔细地查看具体涉及哪些类，然后单击单个搜索结果查看代码本身。
在探索了一段时间后，她决定只关注相关的代码，因此她在一个新选项卡中创建了一个新的“过滤画布”，其中包含包含搜索结果的代码子集，保持空间关系以帮助她保持方向。与HOME画布上一样，筛选过的画布上的代码显示在表示相关类和接口的框中。这个过滤过的画布就像Jane以前在她的记事本上画的类图一样，只不过这里的搜索结果和类图自动保持同步并保存在一起。
乔敲门问了简一个问题。她点击到HOME画布标签，缩小，并指向它的部分来支持她所说的内容。HOME画布在所有团队成员之间共享，正是为了提供团队可以进行讨论的公共基础。为了解释这个让Joe困惑的特性，Jane设置了一个调试器断点并运行程序。当到达断点时，Code Canvas使用一系列红色的执行箭头显示调用堆栈，如图3．然后Jane创建第二个过滤过的画布，重点关注这个调用堆栈。她将镜头缩小，向Jim介绍了该特性中涉及的代码部分。当Joe询问关于算法的详细问题时，Jane将相关代码放大。当与Joe的对话结束后，Jane只是关闭了新的标签并返回到她正在工作的那个标签，它看起来和她离开时一模一样。
简而言之，Code Canvas通过多个画布提供显式的任务支持，并使用稳定的空间布局来保持面向用户。布朗大学的Code Bubbles项目也分享了这些设计目标。1Code Bubbles的策略是从一个空画布开始，并在用户搜索和浏览项目时添加项目。相比之下，Code Canvas从概述开始，并允许用户向下筛选感兴趣的项目。在我们未来的工作中，我们将探索这两种方法的混合。
结论
根据我们在现场研究中观察到的工作实践，我们相信以开发环境的用户界面为中心的代码映射可以减少迷失，回答公共信息需求，并锚定团队对话。今天的软件开发人员很少使用空间记忆和推理。在基于实验室的代码映射设计的前一个版本的评估中，我们展示了开发人员在90分钟的编程任务会话中形成了一个可靠的代码映射空间记忆。4通过利用这些认知资源，代码映射将允许开发人员更好地理解代码，无论是单独工作还是协作工作。我们相信这将从根本上改变和改善软件开发体验。
相关文章
在queue.acm.org
代码山洞探险回来的
乔治诉Neville-Neil
http://queue.acm.org/detail.cfm?id=1483108
可视化系统延迟
布伦丹·格雷格
http://queue.acm.org/detail.cfm?id=1809426
ide的困境
杰夫拉斯金)
http://queue.acm.org/detail.cfm?id=864034
参考文献
1.A. Bragdon, Reiss, S.P, Zeleznik, R.， Karumuri, S.，张，W.， Kaplan, J.， Coleman, C.， Adeputra, F.， LaViola Jr.， J.代码泡沫:重新思考集成开发环境的用户界面范式。在第32届软件工程国际会议论文集(2010)。
2.Cherubini, M.， Venolia, G.， DeLine, R.构建生态有效的、大规模的图表，以帮助开发人员在他们的代码中保持导向。在IEEE可视化语言和以人为中心的奶牛计算研讨会论文集(2007年9月)。
3.Cherubini, M.， Venolia, G.， DeLine, R.， Ko, A.J.让我们进入白板:软件开发人员如何以及为什么使用绘图。在计算机系统中的人为因素SIGCHI会议论文集(2007年5月)。
4.DeLine, R.， Czerwinski, M.， Meyers, B.， Venolia, G.， Drucker, S.， Robertson, G.代码缩略图:使用空间内存导航源代码。在IEEE可视化语言和以人为中心的计算研讨会论文集(2006)。
5.DeLine, R.， Rowan, K.代码画布:向更好的开发环境迈进。在软件工程国际会议论文集(新思想和新成果)。2010年5月。
6.Eick, s.c.， Steffen, j.l.， Sumner Jr.， E.E.， 1992。Seesoft:用于可视化面向行的软件统计信息的工具。软件工程汇刊， 11(1992)， 957968。
7.Ko, a.j.， DeLine, R.， Venolia, G.配置软件开发团队中的信息需求。在第29届软件工程国际会议论文集(2007年5月)。
8.J.西利托，G. C.墨菲，De Volder, K. 2008。在编程更改任务期间询问和回答问题。软件工程汇刊。
9.Storey, m.a.， Best, C.， Michaud, J.， Rayside, D.， Litoiu, M.， Musen, M.虾视图:信息可视化和导航的交互环境。在计算机系统中的人为因素会议论文集(2002年5月)。
数据
图2。通过团队参与设计的瓦胡岛代码地图，并以全分辨率显示地图。虚线矩形是如图所示的地图区域
图3。瓦胡岛地图的Code Canvas版本，主要集中在UI层的左上角。该映射包含两个覆盖:以黄色显示的搜索结果和以一系列红色箭头显示的执行跟踪。该调用显示放大到一个方法以编辑其代码的结果。
©2010 acm 0001-0782/10/0800 $10.00
允许为个人或课堂使用本作品的全部或部分制作数字或硬拷贝，但不得为盈利或商业利益而复制或分发，且副本在首页上附有本通知和完整的引用。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，需要事先获得特定的许可和/或付费。
数字图书馆是由计算机协会出版的。版权所有©2010 ACM, Inc。
评论
肯尼斯·赫兹
未提及:项目级需求/规范系统和相应的系统/项目级测试。您的开发环境中是否有这样的文档?您能将需求映射到代码吗?代码映射能帮助您看到需求变更的影响吗?
显示1评论