PDF将协作构建到 IDE 中
LI-TE CHENG，IBM 研究院
CLEIDSON R. B. DE SOUZA，加州大学欧文分校和巴西帕拉联邦大学
SUSANNE HUPFER，IBM 研究院
JOHN PATTERSON，IBM 研究院
STEVEN ROSS，IBM 研究院
编辑>编译>运行>调试>协作？
软件开发很少是单人编码工作。更常见的情况是协作过程，由开发团队共同设计解决方案并生成高质量代码。这些紧密团队的成员经常查看彼此的代码，集体制定后续计划，甚至在必要时修复彼此的错误。然而，团队合作并不止于此。扩展团队可能包括项目经理、测试人员、架构师、设计师、文案和其它专家，以及其它编程团队。程序员还与组织外部的开发者社区互动，以获取建议、代码片段，以及对哪些方法有效和哪些方法无效的总体理解。
尽管协作有诸多好处，但它也可能耗时且存在问题。研究表明，不断增加的会议、电子邮件、讨论、源代码控制管理任务和其它协调工作使得真正编码的工作时间不足一半。但是，我们不能简单地避开会议，关闭电子邮件，然后躲在自己的小隔间里。我们不能忽视全球互联互通日益紧密的趋势，开发团队分布在全球各地。事实上，软件开发中的一个主要问题是开发者之间沟通和协调的崩溃。
有一些方法可以应对这些问题：更好的管理流程、团队建设培训、细致的架构设计、有条理的协同编码方法以及敏捷软件开发实践可以提供显著帮助。（有关协作和软件开发的更多信息，请参阅本期第 xx 页的“资源”部分。）工具可以帮助我们进行协作，而无需被拖到会议室。示例包括配置管理和缺陷跟踪系统，以及电子邮件。SourceForge1 等网站将这些工具集成到一个集成的在线体验中，并成为许多分布式开发项目的中心。
从个人开发者的角度来看，IDE（集成开发环境）是编码发生的地方，也是许多不同开发工具的家园。如果编码是一项团队工作，那么为什么不将协作功能添加到 IDE 工具集中，与编辑器、编译器和调试器并列呢？在本文中，我们将探讨将协作集成到 IDE 中的概念。
为什么要集成协作？
电子邮件和即时消息 (IM) 等协作工具长期以来一直存在于 IDE 之外。那么，将这些工具整合到 IDE 中的回报是什么呢？让我们通过配置管理、屏幕共享和电子邮件/IM 的示例来考察这一点。
配置管理。 CVS（并发版本系统）等工具是软件开发团队的中央存储库。它们也是非常结构化的协作工具：它们允许开发者以协调的方式交换、修改、标记和合并文件。虽然功能强大，但这些工具很复杂，尤其对于大型开发项目而言。通过将配置管理集成到 IDE 中，我们消除了执行共享文件管理操作的额外步骤。良好的集成将使开发者产生一种错觉，即使用配置管理并不比使用本地文件系统管理本地文件更困难。此处的收益类似于将调试器和链接器等工具集成到同一 IDE 中的好处：集成节省了花费在切换到其它工具上的时间和精力，并降低了学习曲线，只需要熟悉同一 IDE 中的新功能，而不是学习全新的独立工具。Grady Booch 和 Alan Brown 将此称为减少软件开发过程中的摩擦。2
屏幕共享。 在开发者的日常工作中，常见的情况是请同事过来帮忙解决一些代码问题。虽然这通常涉及大量的解释和讨论，但最终结果是代码的修复效率比程序员独自研究问题更高。获取他人的观点已在代码审查、结对编程以及更大规模的开源软件开发等实践中得到规范。VNC（虚拟网络计算）等屏幕共享工具已被用于促进分布式团队的此类咨询。
如果屏幕共享集成到 IDE 中，开发者可以通过跳过查找队友的 IP 地址、配置屏幕共享服务等通常的启动开销来“减少摩擦”。更有趣的是，集成的解决方案可以将屏幕共享会话（以及随附的 IM 聊天或电话的电子记录）与感兴趣的文件一起保存到代码存储库中。因此，集成的另一个回报是上下文：协作在操作发生的地方（在 IDE 中）启动、运行和保存，并且协作产物可以立即与我们关心的代码相关联。上下文中的对话永远不会离开 IDE，始终专注于参与者之间的团队合作，并且可以在未来从其发生的上下文中访问。
电子邮件和 IM。 将上下文再提升一个层次，电子邮件和 IM 等临时通信工具经常用于开发。消息可能是关于最新签入到源代码控制系统的公告，或者是关于特定错误的讨论。消息可能包含项目特定的引用（例如，URL、包和文件名、代码存储库位置）或粘贴的代码片段。在集成电子邮件和 IM 的 IDE 中撰写此类消息可以自动将开发者的非正式讨论与正式源代码和存储库分支联系起来。因此，仅仅复制和粘贴代码就可以在关于代码的讨论与相互关联的项目文件和文档网络之间形成双向链接。因此，集成的第三个回报是可追溯性：关于一段代码的疑问和解答，通常会隐藏在电子邮件服务器上或丢失在瞬态 IM 中，将成为代码注释的一种形式，补充正式文档。两个团队成员之间的电子邮件或聊天讨论通常可能对整个团队都有利。当新开发者在没有文档的遗留代码中探索时，这种非正式的“墙上留言”可能很有帮助。代码行也可以与讨论它们的人相关联，这在追踪线索时非常宝贵。
挑战
将协作功能集成到 IDE 中对于简化程序员的开发活动具有巨大的潜力。这种集成引入了许多技术和设计挑战。主要问题包括
- 构建可扩展性、互操作性和灵活性
- 选择和设计“正确”的协作功能集
- 支持个人工作和团队工作之间的转换
让我们看看这些挑战。
构建可扩展性、互操作性和灵活性。 集成软件通常不是一项简单的任务，并且集成协作功能存在一些特殊的挑战。首先，如果正在扩展的 IDE 本身就具有支持可扩展性的架构，则会有所帮助。许多商业系统都是可扩展的，目的是为第三方供应商打开大门，他们的组件可以增加 IDE 的价值。能够轻松地将协作扩展插件到 IDE 中有助于减少工具开发者的摩擦。
然而，集成协作功能以实现上下文和可追溯性的好处，需要在 IDE 中使用比仅仅使扩展显示在 IDE 的用户界面中更深层次的扩展机制。上下文和可追溯性需要访问 IDE 底层的模型：文件系统、编译器和语法检查机制、网络以及源代码控制系统。为了协助解决与开发者相关的问题，集成的协作工具需要理解开发者在 IDE 中使用的模型和工件。IDE 的扩展应该是第一等公民，并且与 IDE 附带的任何功能一样强大和灵活。例如，使聊天（和聊天记录）能够正确突出显示代码语法并超链接到源代码模块，需要访问 IDE 用于管理其语法和模块的机制。
与此要求相关的另一个考虑因素是，IDE 的搜索工具应具有足够的可扩展性，以包含协作插件生成的任何工件。您只需注意到搜索新闻组、讨论区和网站以获取其他开发者的提示和技巧是多么有用，就可以意识到此功能将有多么强大。将 IDE 搜索与协作工件搜索集成可以减少摩擦（基于文件的搜索和基于知识的搜索变得相同）。如果与 IDE 的核心功能紧密集成，搜索可以变得更加情境化和可追溯。例如，单击编辑器中的单词或文件查看器中的文件将弹出搜索上下文菜单，以查找相关文档和讨论。
互操作性是另一个需要考虑的问题。开发者使用不同供应商的工具，即使在同一 IDE 中也是如此。此外，协作 IDE 可能不仅用于在同一组织内进行交互，还用于与外部团队或客户进行交互。互操作性问题可能出现在供应商中立的服务器端协作服务（例如，IM、电子邮件、源代码控制、屏幕共享、名称目录）和 IDE 提供的抽象 API（应用程序编程接口）中。开放标准和协议在这里很有帮助，否则开发团队必须就同一套消息传递和协作协议达成一致。IDE 的供应商需要提供灵活且可扩展的 API（不与任何特定实现绑定），以便访问服务。例如，从 IDE 内部访问源代码控制系统在理想情况下应在供应商中立的 API 中虚拟化。
构建灵活性是另一个不应忽视的挑战。IDE 的协作插件本身应可由外部贡献者（理想情况下是使用它们的开发者）扩展。任何开发团队的规范、实践和需求都会有所不同，并且会随着时间的推移而变化。因此，协作功能需要像团队的社会结构一样灵活。例如，可以链接到 IDE 中源代码的聊天可能还需要链接到存储在运行项目管理系统的外部服务器上的设计需求。定制可以来自用户偏好，当然，但可能会出现超出协作插件范围的情况。记录在案的 API，最好与 IDE 的 API 一致，将会有所帮助。
增强协作功能的 IDE 需要某种支持网络基础设施。设计此类基础设施会引发前面提到的互操作性问题（例如，对目录服务的支持、消息传递标准等）。此外，支持协作的软件必须足够灵活，以包含特定于 IDE 环境的工件和模型。例如，将源代码与电子邮件链接的元数据需要存储在某处，可能是使用特殊的标头字段或 URL。协作工件的存储位置是另一个问题：您可以尝试处理多个存储（例如，一个用于电子邮件，一个用于源代码，一个用于论坛，一个用于聊天记录，一个用于缺陷跟踪等），或者您可以尝试将所有内容整合到一个存储中（例如，源代码控制存储库）。前者可能会使此类系统的管理和配置复杂化。因此，后一种情况非常吸引人，但问题是单个存储的灵活性和可扩展性如何，以及当开发团队开始与外部组织互动时，它是否会成为可接受的解决方案。
选择和设计协作功能。 选择要与 IDE 集成的“正确”协作功能集是一项艰巨的任务。开发组各具特色，并以独特的方式工作，具有自己的方法论、流程和约定。不同的组会发现不同的协作功能很有用，因为每个组都有自己的历史、文化、工作风格和组织需求。例如，组织中的一个特定组可能采用使用聊天来传达某些类型的信息，而使用电子邮件来传达其它类型信息的做法。一些团队可能使用 CVS 进行源代码控制，而另一些团队可能使用 IBM 的 Rational ClearCase。团队的需求和开发流程也会随着时间的推移而变化，他们的协作需求也会发生变化。
协作功能的选择也可能因组织要求和外部影响而改变。例如，如今越来越多的软件开发组织正在寻求 ISO 9001 和 CMM（能力成熟度模型）等认证，这意味着软件的变更必须经过记录、审查和授权，然后才能集成到代码中。其基本思想是变更必须具有可追溯性。这会影响协作功能的选择和/或使用。例如，在需要可追溯性的此类组织中，记录聊天对话可能是强制性的。
因此，开发团队及其企业的个性化表明了向 IDE 添加协作功能的一些指导原则。理想情况下，这些协作功能应
- 避免嵌入或强制执行对“正确”开发流程的僵化概念，因为这因团队而异，也因企业而异。相反，这些功能应适应各种流程，包括正式流程和非正式流程。
- 提供开发者可以协作的各种灵活方式，以便团队可以选择在特定情况下使用的功能。
- 可由开发者自己配置和扩展。
虽然不是详尽的列表，但以下功能可以灵活地适应程序员协同工作的许多方式
- 提供对其他程序员及其活动的周边感知（谁在围绕我们的代码，特别是你依赖的代码做什么）。
- 支持各种通信机制（文本、语音、视觉）。
- 与团队的源代码控制系统和缺陷跟踪系统集成。
- 支持“情境中”通信，包括同步通信（聊天、屏幕共享）和异步通信（代码注释、持久聊天、团队文档）。
- 支持搜索保存的团队工件和开发历史记录。
支持个人工作和团队工作之间的转换。 任何协作工作的一个重要方面是，它通常由个人和协作活动的网络组成。在软件开发环境中，这种区分是可取的，并且实际上通常通过正式实践和工具来强制执行。例如，开发者可以选择在源代码控制存储库的私有分支中工作，并且仅在集成里程碑时才贡献于主开发流。因此，私有分支成为个人实验和测试的“沙箱”，与团队繁忙的“外部世界”隔绝。
个人工作和协作工作之间这种区分的自然结果是需要支持这些方面之间的转换，即协助决定何时以及如何从个人活动转向协作活动，反之亦然。这些转换尤为重要，因为任何软件开发工作都存在固有的相互依赖性。事实上，已经为这些转换提供了一些工具支持，例如，通过源代码控制工具的合并机制，该机制允许轻松集成由不同开发者修改的同一文件的多个版本。然而，这些工具基于语法信息（代码行），并且无法处理语义信息；它们在帮助软件开发者理解个人工作对整个团队的更大协作工作的影响方面提供的支持有限。在此处捆绑不太正式的协作工具提供了允许开发者协调和缓解此问题的机制。
支持个人工作和团队工作二分法的另一个挑战与注意力管理、中断和信息过载有关。如果协作功能过于分散注意力，它可能会干扰日常工作而不是支持日常工作，并且可能会被开发者断然拒绝。每个用户都需要完全控制功能应如何传递警报、如何指定中断的适当时间，以及如何快速从不相关信息中过滤和排序相关信息。协作工具需要考虑到开发者有时会感觉更容易被打断和协作，而另一些时候会“进入状态”并希望屏蔽所有干扰。
JAZZ：案例研究
将协作集成到 IDE 中的一个工作示例是 Jazz，这是一个 IBM 的研究项目，专注于 Eclipse IDE 的一组特定协作功能。3 目标是培养“直接团队”开发者成为蓬勃发展的社交群体，同时捕获团队的工件，为沟通提供有用的背景和上下文。
在 Jazz 增强的 IDE 中，团队中的每个人都是环境中的一等成员，与文件、文件夹和库处于同等地位。我们提供类似于 IM 好友列表的功能，以监控谁在线以及是否在编码（见图 1）。IM 状态消息可以自动包含上下文信息，例如开发者当前正在处理的文件。开发者可以发起聊天，这些聊天可以保存为代码注释或保存到论坛中，或者使用其它通信模式，如屏幕共享和 VoIP（网络电话）电话，而无需任何额外的设置开销（即，设置服务器、配置 IP 地址等）。因此，这些功能通过在编码环境中随时可用而减少了摩擦，并通过使开发者能够围绕代码进行对话并将消息和状态信息与代码工件链接起来而提供上下文和可追溯性。
Jazz 还提供以资源为中心的感知。如图 2 所示，文件查看器中的文件和其它资源用彩色图标装饰，以指示其它开发者对其文件的本地副本所做的操作（例如，指示文件正处于焦点并且正在被编辑，或者文件已在本地保存但尚未签回到代码存储库）。资源上的工具提示显示谁负责这些更改。将这些指示器合并到 IDE 的文件查看器中，通过避免开发者必须到 IDE 外部手动挖掘此类信息来减少摩擦。这些指示器为开发者提供了与团队所有成员都在附近工作时可用的相同的团队其他成员活动的外围感知。此外，这些指示器出现在上下文中，即开发者通常管理文件的位置，并且此附加信息与通常与文件关联的提示（例如，文件大小、上次修改日期）混合在一起。此外，一目了然地发现谁负责更改的能力融入了可追溯性。
有关 Jazz 的更多信息，请参阅我们在 OOPSLA 2003 的 Eclipse 技术交流研讨会上发表的研讨会论文“使用协作工具为 Eclipse 增添活力”。4 有关与 Eclipse IDE 集成的协作功能的更多示例，请转至本期 Queue 文章第 47 页的“Eclipse：IDE 中协作工具的示例”。
经验教训
我们在 Jazz 项目中的经验指出了一些在将协作集成到 IDE 中时需要牢记的有趣的实现问题。以下是我们学到的主要教训
开放或标准化协议增加了选择并简化了部署。 为了在 Jazz 中实现屏幕共享，我们选择集成 TightVNC 客户端和服务器；5 此屏幕共享软件使用 VNC 中使用的标准 RFB（远程帧缓冲）协议。6 考虑到这种选择，我们可以尝试插入不同品牌的 VNC 客户端和服务器。非 Jazz 用户甚至可以主持与 Jazz 成员的屏幕共享会话，或加入 Jazz 内发生的会话。例如，在不同软件测试环境中工作的质量保证分析师可以与在 IDE 中工作的开发者协作。IM 也可以从使用开放标准的灵活性中受益：开发者可以在其 IDE 内以及与 IDE 外部的经理和其它人员聊天。如果 IDE 的 IM 系统与公司现有的消息传递基础设施协同工作，部署将变得更加容易。
开放、可移植、可扩展的 API 允许超出 IDE 规范的定制。 在我们的 TightVNC 服务器示例中，我们使用的是 Windows DLL（动态链接库）。尽管遵循 VNC 协议，但此组件无法立即移植到不同的语言和平台。如果 TightVNC 社区发布用于屏幕共享的开放 Java API，那么将我们基于 JNI（Java 本机接口）的屏幕共享功能移植到备用平台（例如，Linux）的工作将容易得多。
API 可以分为两个级别“开放”：开源（开发者可以直接读取源代码）或开放 API（开发者可以轻松访问可扩展的 API）。在 Jazz 的案例中，我们很幸运 Eclipse 具有这两个属性。IDE 制造商可能无法预测集成协作（或某些其它不可预见的功能）的开发者的所有需求，但他们可以通过提供可扩展的 API 来提供帮助。
考虑一下我们添加到 Jazz 中的以资源为中心的感知：Eclipse 允许我们为文件装饰器定义扩展（通常用于在文件管理器中的文件上放置编译错误标记等指示器），这使我们可以在文件上放置彩色图标以指示开发者正在对它们做什么。检查开源代码的能力证明甚至更有帮助：Eclipse 为源代码控制提供了通用 API，但对于我们实现资源感知的目标来说，它太有限了。然而，由于我们可以读取源代码，因此我们能够找到通用 API 的 CVS 实现，并且它偶然提供了满足我们所需功能的公共 API。
当我们在编辑器中围绕选定的源代码触发聊天时，开源代码也发挥了救援作用。使用上下文菜单 API，我们能够简单地添加一个新的右键单击菜单项，以围绕选定的代码行开始聊天。但是，当我们想要在从主菜单级联的子菜单中动态显示可能的聊天伙伴列表（以启用“一键式”聊天）时，我们发现 API 不支持动态菜单。在这种情况下，我们检查了代码编辑器的源代码，发现了我们可以获取实际菜单句柄的位置，然后插入代码以形成我们的动态菜单。再次，可扩展的 API 使我们能够“入门”，而开源使我们能够更进一步，所有这些都没有打扰 IDE 的原始开发者。
为 IDE 插件构建无缝用户体验。 这些示例中的大部分工作都与 IDE 的 UI（用户界面）模型相关（例如，使项目出现在上下文菜单中或在文件资源管理器中的文件上放置图标）。UI 模型对开发者公开得越好，实现这些 UI 功能就越容易，用户体验也就越流畅。对于用户而言，这些新的协作贡献应该感觉像是 IDE 的原生功能；它们应该易于使用，并且不需要心理上的上下文转换。
无缝用户体验的一个示例是我们的“Jazz Band”或好友列表。标准 IM 好友列表可以在桌面上占用任意大的空间，也可以最小化地驻留在系统托盘中。在空间有限的 IDE 中，开发者可能希望列表尽可能紧凑。我们的解决方案是构建 Jazz Band UI，以便它根据用户为其分配的空间量自动显示更多（或更少）详细信息。这比典型的独立应用程序具有更连续、更精细的 UI 粒度级别：名称、图像、状态消息和装饰器根据可用空间出现、缩放或消失。
不同协作功能的用户 ID 需要协调。 考虑到协作涉及人员互动，因此主要的技术障碍不足为奇地是协调不同协作工具之间的用户 ID。这在 IDE 中尤其复杂，因为您要混合和匹配许多工具：IM、源代码控制、电子邮件和屏幕共享都可能使用不同的 ID 集。我们在实现对使用共享资源的个人的感知时遇到了这个问题；我们选择在客户端将 IM 用户 ID 映射到/从源代码控制用户 ID 映射，因为所有用户信息都存储在本地。这可能不适用于所有系统，因此在其它情况下，统一目录（如 LDAP（轻型目录访问协议））很有用。
来自多个协作工具的多个用户 ID 也意味着多个密码和登录机制。理想情况下，登录应保持自动，或者至少只提示用户 ID 和密码一次。同样在 Jazz 中，登录数据在本地可用，但这对于依赖于中央用户名或用户域的其它系统来说变得更加复杂。
此外，IM 等协作工具可能由同一用户在 IDE 内外同时使用，因此需要适应来自不同上下文的同一用户的多次登录。这些 IM 会话需要协调并和谐运行。在 Jazz 的案例中，我们避开了这个问题，因为我们有自己的 IM 系统。IM 系统需要支持同一帐户在同一机器上的并行登录，或者支持角色概念，即用户 ID 可能有多个角色代表不同的上下文，或者 IM 系统集中来自不同上下文的请求。这个问题似乎特定于 IM 和屏幕共享等同步应用程序。
实时感知需要对基于推送的通知的支持。 我们的实现早期暴露的一个要求是需要可以向客户端发出状态更改信号的服务器。在集成来自源代码控制系统的信息的情况下，我们发现 CVS 无法通知客户端；我们被迫使客户端定期轮询服务器，以确定存储库中是否发生了任何相关更改。我们充分利用了我们的消息传递系统的信令能力。事实上，IM 系统通常会发出状态更改信号，但电子邮件和基于 Web 的系统等其它协作存储通常依赖于来自客户端的自动甚至手动轮询；这与我们旨在在 IDE 中实现的实时感知的概念不太吻合。
在部署之前解决软件开发者的顾虑。 为了评估我们原型中的潜在问题，我们在 2003 年夏季对 IBM 的 14 位专业软件开发者进行了访谈。虽然我们的原型仍在开发中，但我们使用了带有模拟屏幕截图的故事板（我们之前在规划设计时使用过这些故事板）作为访谈期间的谈话内容。信息过载是一个重要的顾虑，它浮出了水面。尽管记录聊天作为记录重要设计决策（否则这些决策将丢失）的一种手段听起来非常有用，但一些开发者指出，某些对话（例如，短暂的对话）不应记录，因为这样做会使在 Jazz 中查找相关信息变得困难。隐私是软件工程师在访谈中提出的另一个顾虑。一些用户表示担心，以资源为中心的感知功能可能会被不道德的经理用来监控他们的工作，而不是用作避免冲突更改的协调辅助工具。这些顾虑将在我们对 Jazz 的持续工作中得到解决。
结论
协作在软件开发中发挥着不可或缺的作用，开发者可以从将协作功能与 IDE 集成中获益匪浅。虽然协作工具当然可以与 IDE 并行使用，但集成带来了减少开发过程中摩擦、增强上下文意识以及在协作工件和代码工件之间实现即时可追溯性的回报。将协作集成到 IDE 中引发了许多挑战，包括对可扩展性、访问 IDE 的底层模型、互操作性和网络基础设施的要求。需要仔细选择协作功能以满足团队的需求，并应考虑到个人与协作工作的问题。虽然我们的讨论集中在编码上，但协作工具也可以为开发的其它方面做出贡献，包括项目管理、建模、测试和文档编制。
参考文献
1. SourceForge：参见 http://www.sourceforge.net。
2. Booch, G. 和 Brown, A. 协作开发环境。《计算机进展》59（2003 年 8 月）。
3. Eclipse IDE：参见 http://www.eclipse.org。
4. Cheng, L., Hupfer, S., Ross, S. 和 Patterson, J. 使用协作工具为 Eclipse 增添活力。 OOPSLA 的 Eclipse 技术交流研讨会（2003 年 10 月）。
5. TightVNC：参见 http://www.tightvnc.com。
6. VNC：参见 http//www.realvnc.com/docs/rfbproto.pdf。
LI-TE CHENG 是 IBM 研究院协作用户体验组的研究科学家。他目前正在从事 Jazz 项目，对人机交互、移动计算和增强现实感兴趣。他的背景是计算机视觉、图形学、图像处理、人工智能和软件设计。Cheng 拥有纽芬兰纪念大学多媒体通信实验室电气工程博士学位。
CLEIDSON R. B. DE SOUZA 是加州大学欧文分校信息与计算机科学学院交互和协作技术组的博士生，研究兴趣领域是计算机支持的协同工作在软件工程中的应用。他的重点是了解软件工程师如何协同工作来开发软件，他们在日常工作中遇到什么问题，以及哪些工具可以提供帮助。Cleidson 目前休假于巴西帕拉联邦大学信息学系，他在那里担任教员，并拥有加州大学欧文分校和巴西坎皮纳斯大学计算研究所的计算机科学硕士学位。
SUSANNE HUPFER 是一名研究工程师，在 IBM 研究院的协作用户体验组从事 Jazz 工作。在加入 IBM 之前，她与他人共同创立了耶鲁大学的技术衍生公司，该公司基于 Lifestreams，这是一个率先推出桌面隐喻替代方案之一的系统。她的兴趣包括用于信息管理和协作的新型软件架构和界面，以及分布式系统。她拥有耶鲁大学计算机科学博士学位，专注于松耦合分布式编程和用于协调的软件。Hupfer 与他人合著了《JavaSpaces 原理、模式与实践》（Addison-Wesley，1999 年）。
JOHN PATTERSON 是 IBM 研究院协作用户体验组的杰出工程师。他在 Lotus/IBM 的研究涵盖了一系列群件项目，包括用于同步群件的基于互联网的状态同步功能以及 Lotus Notes 的替代可视化。他目前正在指导 Jazz 项目，将协作工具引入 Eclipse 应用程序开发环境，以努力了解情境协作以及实现情境协作所需的组件。Patterson 获得了密歇根大学实验心理学博士学位，并在 Decisions & Designs、贝尔实验室、Bellcore 和 SunSoft 担任过研发职位。
STEVEN ROSS 是 IBM 研究院协作用户体验组的高级技术人员。在从事 Jazz 工作之前，他是一个使用语音识别和合成技术开发对话式用户界面的项目的首席架构师。他还曾在 Lotus 1-2-3 电子表格中担任多年架构师。他是 Reasonix 的创始人之一，在那里他从事高度优化的 Fortran 编译器和混合主动专家系统的工作，并且是 Verbex 的软件工程师。Ross 拥有麻省理工学院计算机科学的 S.M. 和 S.B. 学位。
Eclipse：IDE 中协作工具的示例
将协作功能添加到 IDE 中并不是一个全新的想法。商业产品、开源和研究工作已经存在并不断发展。Eclipse (http://www.eclipse.org)、NetBeans (http://www.netbeans.org) 和 IntelliJ (http://www.intellij.com) 等 IDE 无缝集成了配置管理工具，这是软件开发者在不同上下文中用于协调其工作的协作工具的一个示例。在此，我们回顾与 Eclipse 相关的技术，以了解集成在 IDE 中的协作工具的示例。
商业项目
CodeBeamer 和 CodePro Studio
增强 IDE 协作功能（如消息传递、项目管理和共享数据）的商业产品。
http://www.intland.com/
http://www.instantiations.com/codepro/
开源
星群
一个由 IBM 研究院主导的开源项目，它引入了细粒度的源代码控制——与活动的概念相关联——以简化协作，并让团队成员了解变更。它具有轻量级的活动编写和文件关联功能，使开发人员能够管理相关工作，通知团队他们当前的工作，了解与其自身活动相关的变更，并为持久对话提供上下文。
http://www.eclipse.org/stellation
研究项目
GILD (Groupware-enabled Integrated Learning and Development)
一个研究项目，旨在研究协作式 IDE 如何更有效地帮助学生学习编程。
http://gild.cs.uvic.ca/docs/overview/innovate.pdf
Hipikat
一个研究项目，将 Eclipse 的搜索与新闻组和 Bugzilla 信息相结合。
http://www.cs.ubc.ca/labs/spl/projects/hipikat/
插件
感谢其可扩展的架构，Eclipse IDE 拥有一个蓬勃发展的协作插件社区。 Eclipse 3.0 里程碑在编辑器中集成了一个 “CVS blame” 功能：开发人员可以选择编辑器中的一行代码，并找出是谁编写了这行代码。
Sangam
一个插件，具有用于结对编程的共享编辑器和聊天功能。
http://sangam.sourceforge.net
Composent
一个插件，提供各种协作功能，包括群组聊天、文件共享、协同浏览和团队意识。
http://composent.com/code/eclipsesite/
Koi
这个项目正在为 Eclipse 应用程序构建协作基础设施。
http://www.eclipse.org/koi
资源
软件开发中的协作领域已经进行了大量研究。 这里是与本文讨论相关的少量入门文章示例。
架构、协调和距离：康威定律及其他
J. Herbsleb 和 R. Grinter
IEEE Software (Sept.-Oct. 1999), 63–70.
报告了对 Lucent 公司各个分布式软件开发团队的研究结果，其中有趣地讨论了非正式沟通的作用，以及分布式多站点软件开发中的文化因素。
打破代码：协作软件开发中在私有和公共工作之间切换
C. de Souza, D. Redmiles 和 P. Dourish
Proceedings of the GROUP (Nov. 2003).
描述了软件开发团队成员采用的一组正式和非正式工作实践，以最大限度地减少个人工作在提供给其他团队成员时产生的影响。
协作开发环境
G. Booch 和 A. W. Brown
Advances in Computers 59 (Aug. 2003)
介绍了协作开发环境的总体动机，包括 “减少摩擦” 的概念。 还调查了软件开发团队合作的各种解决方案。
大型系统软件设计过程的现场研究
B. Curtis, H. Krasner 和 N. Iscoe
Communications of the 31(11) (Nov. 1988), 1268–1287.
描述了作者确定的大型软件系统设计的三个主要问题，即：应用领域知识的薄弱传播、波动和冲突的需求，以及沟通瓶颈和中断。
人员、组织和流程改进
D. E. Perry, N.A. Staudenmayer 和 L.G. Votta
IEEE Software 11(4) (July-Aug. 1994), 36–45.
介绍了一项研究，衡量开发人员在编码与非编码活动上花费的时间，并描述了诸如不愿使用电子邮件等可能影响开发过程的问题。
Palantir：提高配置管理工作空间之间的意识
A. Z. Sarma, A. Noroozi 和 A. van der Hoek
Proceedings of the ICSE (May 2003), 444–453.
介绍了一个工具 Palantír，它使用有关软件开发团队其他成员的信息来增强个人配置管理工作空间，从而促进协调并减少冲突的变更。
使用配置管理工具协调软件开发
R. E. Grinter
Proceedings of the COOCS (1995), 168–177.
描述了配置管理系统在协调软件开发团队中发挥的关键作用。
最初发表于 Queue vol. 1, no. 9—
在 数字图书馆 中评论这篇文章
更多相关文章
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
对跨异构存储技术的分布式事务的支持要么不存在，要么在操作和性能特性方面表现不佳。 相比之下，OLEP 越来越多地用于在这些设置中提供良好的性能和强大的 一致性保证。 在数据系统中，日志通常用作内部实现细节。 OLEP 方法有所不同：它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。 传统数据库仍然被使用，但它们的写入来自日志而不是直接来自应用程序。 使用 OLEP 不仅仅是开发人员的实用主义，而且它还提供了许多优势。
Andrew Leung, Andrew Spyker, Tim Bozarth - Titus：将容器引入 Netflix 云
我们相信我们的方法使 Netflix 能够快速采用容器并从中受益。 虽然细节可能特定于 Netflix，但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法，对于任何希望采用容器的组织来说都可能是一种成功的策略。
Marius Eriksen - 规模化函数式
现代服务器软件在开发和操作方面要求很高：它必须始终在所有位置可用； 它必须在毫秒内回复用户请求； 它必须快速响应容量需求； 它必须处理大量数据甚至更多流量； 它必须快速适应不断变化的产品需求； 在许多情况下，它必须容纳一个庞大的工程组织，其众多工程师就像一个又大又乱的厨房里的谚语厨师。
Caitie McCaffrey - 分布式系统的验证
Leslie Lamport 因其在分布式系统方面的开创性工作而闻名，他曾说过：“分布式系统是指即使您不知道存在的计算机发生故障也可能导致您自己的计算机无法使用的系统。” 鉴于这种黯淡的前景和大量可能的故障，您甚至如何开始验证和确认您构建的分布式系统正在做正确的事情？
© 保留所有权利。