现在，在 2.0 版中，Mylyn（以前称为 Mylar）通过将任务无缝集成到 Eclipse 中并在工作时自动管理任务上下文，提高了效率。Mylyn 项目主管 Mik Kersten 更新了他撰写的分两部分的 Mylyn 使用指南。第 1 部分 介绍 Mylyn 的任务管理功能和它与 Bugzilla 之类的储存库的集成。本文为第 2 部分，解释当在 Eclipse 中处理大型应用程序时，Mylyn 的上下文管理功能如何简化多任务处理以及如何减少信息超载。
在 本文的前半部分 中，我解释了 Mylyn 的任务管理功能如何轻松地聚焦与给定工作日或工作周相关的任务。一旦任务成为您的 Eclipse 体验中的集成部分，您很可能会注意到许多重复性行为都是以所处理的任务的上下文 为中心的。多任务处理是当今知识工作中很普遍的一部分，它常常需要创建和重新创建与当前任务相关的上下文。任务的上下文是指在处理任务时需要引用的所有文件、搜索结果和其它相关信息。例如，在编程时，可能只想看到与正在修复的 bug 相关的 Java™ 元素。当完成修复时，您可能希望以独立于当天处理的其它任务的方式提交这些更改。或者，希望通过只运行与对任务作出的更改相关的测试来节省时间。
 |
什么使 Mylyn 变得 “灵巧” 呢
尽管 Mylar 经常被称作灵巧的用户界面，但它本身并没有任何灵巧之处：它只不过是利用了您的智慧。Mylyn 通过利用这样一个事实做到这点：与每个任务涉及的细节相比，组成工作的各个部分（即您所处理的任务）更加容易检索。它以一种可预测的方式自动捕捉您所处理的所有细节，使您无需再经历重新检索或重新查找的繁琐过程。Mylar 上下文是您同系统元素及关系进行交互的一种可预测的投影，它并没有使用难于预测和理解的知识型模型。这种模型十分灵活，正逐渐被扩展到广泛的知识工作工具中。请参阅 参考资料 小节，了解更多关于 Mylyn 内部原理和架构的信息，以及为项目扩展 Mylyn 的更多细节。
|
|
正如 Mylyn 可以帮助您聚焦工作周所包含的任务一样，它可以使 Eclipse 工作区聚焦与当前任务相关的工件上。安装 Mylyn 的 Task-Focused UI 之后，只需指出活动的任务，您所使用的所有文件都将自动添加到该任务的上下文中。管理上下文是为了精确地表示出对所从事的各种工件的聚焦程度，即使对长期运行的任务也是如此。当切换任务时，上下文将被保存，这使您可以通过一次单击进行多任务处理，并且轻松地与其他人共享特定于任务的知识。
本文解释了 Mylar 如何无缝地将其置于 Eclipse UI 之上来凸现编程任务的上下文。本文首先解释 Mylyn 管理上下文的机制，然后介绍兴趣修饰、视图过滤、编辑器管理和上下文驱动的单元测试套件等 UI 工具。在文章的最后，展示了如何综合运用 Mylar 的任务管理和上下文管理来协助团队协作。
图 1 中的编号区域显示了 Mylyn 的一些上下文管理功能：
- 单击 Focus on Active Task 按钮可以使 Eclipse Package Explorer 只显示活动任务的上下文中的元素。
- 可以通过 Task List 切换活动任务。
- 切换后，Eclipse 视图和编辑器将聚焦于新激活的任务的上下文。
- 更改集将被自动管理，以反映任务上下文中的更改。
- 折叠功能和上下文可以帮助视图聚焦相关的元素。
图 1. 将 Eclipse 聚焦于任务上下文
单击 这里 查看全图。
以任务为中心的编程
设想一下，假设您正在将更改封装到新功能里，来应对迫近的代码冻结期限。在工作中，创建此功能时，构建了关于所有修改过的类和方法以及所有访问过的 API 的颇有价值的知识。由于在使用 Mylar，这个知识会自动地在任务上下文中获取到。任务要完成时，却出现了一个严重的 bug，需要立即给予注意。
您通过单击激活 bug 报告，并开始调查该问题。在 Mylar 的富任务编辑器中浏览该 bug 加了超链接的堆栈跟踪，新的任务上下文被探查和诊断结果所填充。当单击 Mylyn 的自动化 Context Test Suite（该套件运行与已创建的任务上下文结构相关的单元测试）时，您发现这个 bug 位于一个同事的代码中，而不在您的代码中。由于 Mylyn 提供了对任务的修改历史的链接，您可以立即查看该同事的任务，它对应于出现问题的更改。通过再一次单击，将该 bug 再分配给同事并共享由您的诊断得出的任务上下文。完成这些都未离开 Eclipse，所以通过单击 Task List 的 Back 按钮可以立即回到之前任务的上下文。同时，您的同事也恰在您停止的地方拾起该 bug 报告。这只是程序员使用 Task-Focused UI 轻松工作和协作的场景之一。
|
支持的工具
类似于需要使用连接器 与任务储存库集成，Mylyn 使用桥接器（bridge）将它的上下文模型与特定于域的工具集成。Mylyn 附带了用于 Eclipse SDK 的一组核心的桥接器，其中包括对 Java 代码、JUnit、Plug-in Development Environment (PDE)、Ant 和纯文本文件的支持。为了获得完全集成的体验，Mylyn 需要一个用于所有要使用的工具和语言（例如 Ruby 和 JSP）的桥接器。如果缺少特定于您所使用的编程语言或其它文件类型的桥接器，Mylyn 仍然会提供文件级别的聚焦，但是不能监视您与文件内部结构的交互（例如编辑特定的声明）。这意味着在 Package Explorer 中只能看到感兴趣的文件，但是不能执行细粒度的声明过滤（例如在 Outline 视图中）以及在编辑器中自动折叠声明，也不具备诸如任务 Context Test Suites 等高级特性。
为了提供 自动化更改集管理，Mylyn 还需要对版本控制集成进行某种扩展。Mylyn 附带了对 CVS 的支持，但是对 Subversion 等其它版本控制系统的支持则需要单独安装。请查看 参考资料 中的 Mylyn Extensions 清单，下载用于 Mylyn 的额外的桥接器和版本控制集成。
|
|
接下来的小节展示如何利用 Mylyn 的上下文管理功能以任务为中心的方式工作。虽然这里的例子基于 Java 开发，但其中的概念和大多数特性同样适用于可能使用的任何基于文件的工件。（请参阅 支持的工具，了解更多细节。）
兴趣等级模型
Mylyn 中的任务上下文管理基于这样的思想：开发人员与系统的交互可以转换为一个兴趣等级（degree-of-interest）模型，在该模型中，系统中的每个元素都根据其与手头任务的兴趣等级来衡量其权重。这种相关度加权形成了与任务相关的所有元素的上下文。然后，就可以通过突出最重要的元素、过滤无关紧要的元素以及允许在感兴趣的元素上执行操作（例如，只提交相关更改）来使任务上下文聚焦于 UI。任务上下文是在您工作时以一种可预测的方式构建的：当您激活一个任务时，您选择或编辑的每个元素 —— 例如文件或 Java 方法 —— 就成为任务上下文的一部分。和元素交互越多，该元素相对于任务的兴趣等级就越高。如果一个元素的兴趣级别足够高，那么它就成为一个里程碑（landmark），这是一个隐式创建的书签。每一次交互也导致组成任务的所有元素已积累的兴趣逐渐衰减，这样兴趣元素的集合就会同当前的兴趣相匹配，而不会无限制的扩张下去。
使任务上下文模型简单易用的关键特征是它具有可预测性并且一目了然：您期望看到的内容就显示在眼前，每当您开始处理一个元素时，就立即可以看到该元素填充了上下文。还可以直接操纵元素的兴趣等级，或者使元素变得不相关，或者显式地将元素标记为里程碑。换句话说，您已经熟悉的 bookmark/starring/tagging UI 没有任何损失。但是，一旦您习惯使用 Mylyn，您很可能会发现自己对那些手动管理任务上下文的机制的依赖性大大减少。
兴趣修饰和过滤
Mylyn 的上下文管理功能使用传统的 Eclipse 视图以一种新的方式来凸现信息。您只需通过一次单击激活任务，就可以使 Eclipse UI 聚焦于那个任务。然后，您与之交互的每个元素都成为任务上下文的一部分。Mylar 兴趣修饰器随后使用字体着色来高亮显示每个元素从交互中积累的兴趣等级。非兴趣元素以灰色显示，兴趣元素以黑色显示，里程碑为粗体。
尽管只高亮显示在减少信息过载方面有其局限性，但它还是一直应用于所有能看到诸如 Java 成员和文件等元素的视图中。这便于您在查看一长串的元素时快速挑选任务上下文中的元素。例如，当查看搜索结果时，可以立即发现最感兴趣的元素，因为它们以粗体修饰为里程碑形式（参见 图 2）。
仅仅使用修饰还不足以减少包含几十万个文件的大型工作区中的信息超载。一些结构化视图，例如 Eclipse 的 Project Explorer，在浏览大型层次结构内容方面已变得令人难以置信的高效。超载问题与那些视图无关，而应该归因于开发人员使用的巨大的信息系统并不匹配与任何给定编程任务相关的相对较少的信息。对于这种不匹配，最明显的表现是，大量时间浪费在反复滚动以及展开/折叠庞大的树视图以查找完成工作所需的信息。
|
技巧：不过滤子节点
为了减少需要关闭聚焦模式的次数，Mylyn 提供了 Alt+Click 机制，使您可以在树视图中暂时不过滤一个节点的子节点。例如，为了选择一个不可见的方法，可以按住 Alt 键并单击类，并选择那个方法，以便将它添加到任务上下文中。如果在视图中的空白处按住 Alt 并单击鼠标，则会显示所有的根节点（例如项目）。如果继续按住 Alt 键，可以快速地从一个项目节点导航到感兴趣的方法。
|
|
Mylyn 的目标是消除所有不需要的滚动和单击操作。为此， Task-Focused UI 提供基于兴趣的过滤和结构化视图管理。通过 Focus on Active Task 按钮激活后，这些功能可以过滤掉所有不感兴趣的元素，从而将相应的视图聚焦于活动任务的上下文。例如，聚焦模式确保 Package Explorer 只显示您正在处理的内容：属于任务的一部分的所有源文件、库文件和方法。除了过滤外，当应用聚焦时，Mylyn 还自动维护树视图的展开状态，所以您不需要手动地展开和折叠树节点就能看到感兴趣的元素。
开始在视图上使用聚焦模式后，您将注意到兴趣模型如何随着工作而演进。一个元素的被选中次数越多，元素的兴趣等级就越高，直到它变为粗体的里程碑。低兴趣的元素（如只选过一次的搜索命中结果）将在兴趣等级中衰减并从过滤过的视图中消失，这确保该视图不会被非兴趣元素所胀满。由于任务上下文在一种可预见的模式下被积极地管理，上下文只包括了有兴趣等级的元素，即使在长期运行的任务中也是如此。尽管设计 Mylar 的任务上下文模型是为了能够一直反映当前与任务相关的东西，但也可以手动地增加或减少元素的兴趣等级（例如，通过使用元素的上下文菜单行为或使用快捷键 Ctrl+Alt+Shift+ 向上/向下的箭头）。
以任务为中心的工作区
在深入探讨 Mylyn 提供的用于支持 Java 开发的高级集成之前，您需要大体了解在处理纯文本文件时，Task-Focused UI 对 Eclipse 工作区的关键贡献。图 2 演示了这些关键概念：
- 在左侧，Project Explorer 视图聚焦于活动任务，它只显示感兴趣的文件，并高亮显示里程碑。在这里，可以使用 Alt+Click 机制临时显示一个名为 presentations 的目录中的所有文件，以便选择其它感兴趣的文件。
- 在右侧，Task List 显示一个活动任务。当该任务停止活动时，Package Explorer 视图上的焦点被关闭，当前打开的所有文件被关闭。如果一个新的任务被激活，则重新应用焦点，用于处理那个任务的所有打开的编辑器立即恢复。
图 2. 以任务为中心的工作区
本文后面的内容以 Java 开发为例，较详细地阐述如何以以任务为中心的方式工作。但是，任务激活、视图聚焦和编辑器管理等概念是使用 Mylyn 的最值得注意的关键方面。您只需理解任务激活的概念，就可以开始使用以任务为中心的方式工作。这种小但重要的工作方式的改变会立即使您获益：当您切换任务时，您在工作中建立起来的所有有价值的上下文不再会丢失。
在 Java 开发中使用 Mylyn
将 Mylyn 用于 Java 编程的开发人员常常使 Package Explorer 处于聚焦模式。因此，默认情况下，当激活一个任务时，Focus on Active Task 按钮自动打开，当将一个任务变为不活动时，该按钮自动关闭。当该功能打开时，只能看到上下文中的 Java 元素。当选择一个 Java 类时，不管是通过浏览还是通过常用的 Open Type 机制（Ctrl+Shift+T），这种类型就成为上下文的一部分，并显示在过滤后的 Package Explorer 中。您选择和编辑的每个方法都被添加到任务上下文中，因此会显示在 Package Explorer 中。图 3 显示聚焦模式下的 Package Explorer。注意 Package Explorer 和 Debug 视图中 Java 元素的基于兴趣的修饰和活动过滤。
图 3. 使 Java 元素视图聚焦于任务上下文
当视图在聚焦模式时，Eclipse 用于打开元素的工具运行良好（使用 Ctrl+Shift+T 打开一个类型，使用 Ctrl+Shift+R 打开一项资源，Ctrl+O 用于就地打开大纲，Ctrl+T 用于就地打开层次结构）。为使在 Open Type 对话框中选择类型更加简单，感兴趣的类型被自动放在列表的最上面。当切换任务时，列表中包含新任务感兴趣的类型。当没有活动任务时，该列表恢复为最近使用类型的 Eclipse 全局列表。
如果使用 Java Browsing 透视图，请使用窗口的工具栏按钮，通过单击将三种 Java 元素视图设为聚焦模式，而不必逐个聚焦每个视图。
|
技巧：快速视图
如果使用没有可见导航视图的透视图（例如 Debug 视图），或者将编辑器区域最大化，那么仍然可以从 Navigate > Quick Context View（快捷键为 Ctrl+Shift+Alt+右箭头）导航上下文。和 Quick Outline (Ctrl+O) 等其它快速视图一样，这种弹出视图的优点是允许您输入，以导航到感兴趣的文件或元素。
|
|
自动折叠和内容辅助排序
Eclipse 成熟的 Java 编辑器使您可以在编辑器中处理大多数结构导航。此外，Mylyn 还提供了自动折叠和内容辅助排序，以帮助 Java 编辑器聚焦与当前任务相关的元素。如果打开窗口工具栏中 Mylyn 的 Automatically Fold Uninteresting Elements 按钮，那么在编辑器中只有感兴趣的元素被展开。这可以增加编辑器的信息密度，并且更易于导航大型文件中的声明，而不必打开 Outline 视图。当选择一个元素时，它立即成为任务上下文的一部分，并且被展开。注意，在图 4 中，大多数元素都是折叠的，因为它们没有被选择或编辑过；同时，活动元素是打开的，左边的编辑器装订线提示它是一个里程碑：
图 4. 自动折叠和内容辅助排序
与视图中的过滤相似，Mylyn 还根据兴趣等级对 Java 内容辅助建议进行排序。在兴趣分隔符下的所有条目都使用 Java Development Tools 的标准排序试探法进行排序。这意味着，只需按几次向下箭头键就可以选择感兴趣的建议。如果在选择建议前开始输入，该列表会恢复为典型排序。还应注意到，在图 4 中，诸如 getTask() 等感兴趣的方法在编辑器中也是展开的。公开元素兴趣等级的各种机制间的一致性有助于 Focused UI 变得可预见且易于使用。
自动编辑器和透视图管理
Mylar 也使用任务上下文来动态地管理和任务相关的打开编辑器的数目。当文件中的元素从兴趣等级中衰减，该编辑器会自动关闭。当停用一个任务时，它所有的编辑器都会关闭，任务激活时重新打开。减少元素的兴趣等级会关闭其编辑器，且反之亦然，关闭一个文件也会减少其兴趣等级。这可能需要一点时间才能适应，但是这意味着您不再需要自己管理打开的编辑器的状态，并且打开的编辑器的数量也不至于太多。确保所有打开的编辑器与感兴趣的元素相对应，这还使您可以使用 Eclipse 的编辑器导航功能在感兴趣的文件之间导航。例如，如果 Package Explorer 之类的导航视图不可见，可以使用 Ctrl+E 和 Ctrl+F6 方便地在编辑器之间切换。
同样，Mylar 也能通过恢复上次完成一项任务时激活的透视图（通过单击 Window > Preferences > Mylyn > Context 启用）来管理 Eclipse 的透视图。当不同的任务对应于 Eclipse 提供的不同视图（例如，有些任务对应于 Java 开发，有些任务对应于 PHP 开发）时，这一点很有用。当使用 Mylyn 的 Planning 透视图时，该功能特别管用。如果在没有活动任务时切换到 Planning 透视图，那么当停止要处理的下一个任务时，就会自动切换到那个透视图。使用 Planning 透视图可以更容易地发现接下来要处理哪个任务，因为这个透视图会将任务编辑器和 Task List 的区域最大化。
使用 Ant、PDE 和其它源文件
Mylyn 的聚焦功能可以应用于所有在 Eclipse SDK 中显示上下文的视图：Package Explorer、Navigator、Project Explorer、Outline、Problems、Tasks、Debug、Packages、Types 和 Members。任何树视图的聚焦模式，如 Project Explorer 都添加了兴趣修饰、过滤和展开管理。在聚焦模式下，列表视图，例如 Problems，也会按照兴趣等级分类。由于这种通用的支持，即使定制的桥接器不支持您的工具（见 支持的工具），仍然可以将 Mylyn 用于非 Java 项目，例如 PHP 开发。本节简要地概述如何将 Mylyn 用于使用其它语言和工具的编程。要了解更多信息，请访问 参考资料 中的 Mylyn Extensions 链接。
例如，考虑使用 Ant 和 PDE 开发一个应用程序。在这个场景中，Eclipse 工作区看上去和图 5 类似，其中有多个视图被打开，并显示上下文：
图 5. 使通用 IDE 视图聚焦于任务上下文
|
技巧：清理 to-do 标记
与 Mylyn 的 Task List 视图相比，Eclipse SDK 的 Tasks 视图显示 to-do 标签等标记，这种标记指示与一个资源有关的本地问题，类似于编译器警告。与 Mylyn 的任务相比，这些标记的粒度要小得多，因为它们对应于数行源代码，而一个 Mylyn 任务可能包含多个标记。由于 Tasks 视图很快会发生超载，因此使用聚焦模式可以很方便地提醒开发人员在提交前清理 to-do 标记。
|
|
注意，图 5 中的 Project Explorer 视图只显示任务上下文中的文件，这里包括一些图像和 XML 文件。打开的文件是 build.xml，该文件由数十个 Ant 声明组成。在 Outline 视图中，只能看到您正在处理的声明，而不是许多不感兴趣的声明。Problems 视图也聚焦于活动任务，只能看到感兴趣的东西（如所有的错误及警告或任务上下文中其他的元素标记），而不是被数百条无关的警告堆满而超载。最后，Eclipse Tasks 视图也处于聚焦模式，因而将只看到与任务上下文相关的标记，而不会看到数百条不会立即去做的 to-do 标记。
Context Test Suite
在以任务为中心的方式下编程更易于频繁运行单元测试。通常来说，单元测试实践让您为一个或多个当前正在从事的枯燥测试创建一个新的测试启动程序。其他的测试方案是：在一个项目上运行所有测试，这会错过一些相关测试；或运行一整套测试，这很慢。为解决这些问题，Mylar 在任务上下文中自动维护了元素的单元测试套件 —— 称为 Context Test Suite（见图 6）—— 并在操作任务时使重复运行测试变得很简单（用快捷键 F11）：
图 6. Context Test Suites
要启用该特性，为 JUnit Plug-in 测试或普通 JUnit 测试创建一个 Context Test Suite。Context Test Suite 被自动更新，以包括当前活动上下文中的所有测试用例。
将上下文用于协作
协作性工具都是关于共享信息的，任务上下文能聚焦于该信息而阻止信息超载和分散。开发人员不断来回发送电子邮件、即时消息及文件，来交换执行日常任务所需的必要消息。尽管 Mylar 仍没有排除对即时消息或电子邮件的需要，但它能够通过将它们锁定在任务周围来简化一些协作活动。由于任务定义了清晰、易于理解的工作单元，且任务上下文定义了与工作相关的信息，所以用单击来共享任务上下文的功能能够减少协作通信负担。
在 第 1 部分 中，我演示了 Mylyn 的任务管理如何将基于 Web 的储存库（如 Bugzilla）集成起来，从而提供了您期待从电子邮件客户机中得到的那种协作集成程度和响应程度。这一节则解释 Mylar 对跟踪更改集和任务活动的自动支持（联合了对上下文共享的支持）是如何进一步便利了团队工作及获取专门技术的。通常，您可以根据需要以及 Mylar 同源文件及任务存储库集成的程度挑选要使用的功能。
自动化的更改集
|
技巧：更改集模式
Eclipse 有两种更改集模式，3.2 版中新出现的基于模型的更改集和标准更改集。尽管这些模式实际上很难辨别，但是基于模型的模式较为可取，因为它同时显示引入和传出的更改。要了解关于在这两种模式之间切换的详细信息，请参阅 Mylyn FAQ（参见 参考资料）。
|
|
更改集 是一项用于对资源分组的内置的 Eclipse 工具，可以在 Synchronize 视图中对其进行操作，以提交、更新或创建补丁。除非在一个静态的项目中工作，否则手动管理更改集常常得不偿失。Mylar 通过自动管理更改集便利了对源存储库的操作。一旦激活一项任务，该任务的更改集即被添加，并随后显示在 Synchronize 视图（见图 7）中。操作该任务时做出的更改被添加到该更改集中。可以使用位于视图的 Change Set 节点的上下文菜单来覆盖、提交或创建一个补丁。由团队成员做出的更改按照任务分组显示，可以通过右键单击一个引入的更改集来打开相应的任务。如果有了更改，但任务停用，更改集不变，使您可以同时操作多项传出更改。Mylar 确保在上下文和更改集之间的一对一映射，所以如果将一份文件手动地添加到更改集中（通过 Synchronize 视图中的上下文菜单），该文件也会被添加到上下文中。当前支持的源存储库是 CVS 和 Subversion（包括 Subclipse 和 Subversive）。
图 7. 更改集管理并将其映射到任务
|
技巧：将项目与任务储存库关联
为了对文本和 Java 编辑器的引用启用超链接，例如对于 Bugzilla 的 “see bug 123”，或者对于 JIRA 的 “ABC-123”，必须将与资源对应的项目与一个任务储存库相关联。为此，可以右键单击项目，选择 Properties，然后选择 Task Repository。每当 Mylyn 解析资源中对任务的引用时，都要使用项目到任务储存库之间的这种关联，所以这种关联对于 History 或 Team Annotation 超链接也是必需的。如果项目是共享的，可以将该设置放入版本控制中。
|
|
尽管一开始效果也许不明显，Mylar 使用上下文将任务和资源绑到一起的方法将对您工作的方式产生根本性影响。例如，对于 Mylar 项目本身，不需要编写提交消息，因为它们是由 Mylar 的更改集集成（使用 Window > Preferences > Mylyn > Team 页面编辑用于生成自动提交消息的模板）自动生成的。这使我们能够通过单击从 History 视图导航至与修订相对应的任务，这节省了跟踪更改及修订至原始任务的时间。相反地，这也使得可以通过 CVS 日志查询所有针对一个特定任务更改过的文件。这个功能与 Eclipse 用于显示 Team Annotations 的功能和 Mylyn 的普通超链接（见图 8）相结合，意味着您将大量减少花费在查找与一个更改相关的 bug 或任务上的时间，因为通常只需一次单击即可完成。（注意，为了在弹出的文本编辑器中显示超链接，必须按下 Ctrl 键，如果要将弹出窗口放在最前面，需要按 F2 键）。
图 8. 超链接和团队注释
共享上下文
任务上下文获取执行任务时创建的知识。重新激活一个任务会立即将您带回到该任务的上下文，而不是迫使您恢复与该任务相关的那部分系统。如果半途将任务移交给团队成员，任务上下文会为他或她提供一个起点。由于上下文是从交互中创建的，而不仅从更改中创建，每个任务上下文都包含了相关信息，如处理该任务时访问过的 API 以及引用过的文档。为支持这个及类似的协作场景（如结对编程），上下文能被轻易地共享。可以通过 Task List（如图 9）中的上下文菜单或通过单击任务编辑器中相应的复选框来激活上下文共享：
图 9. 通过任务附件进行上下文共享
当使用支持附件的任务存储库连接器时，可以将任务上下文附加在 bug 报告中来轻易地实现共享。当获取一个共享上下文时，可以从所有可用的上下文中选择（如果当前有多个上下文的话）。例如，在 Mylar 项目中，我们将上下文附在每一个解决了的 bug 报告中，并且要求每一个贡献的补丁都要附上上下文。这种通过上下文共享专门技术的方法使应用补丁、与团队成员协作处理 bug 报告、在结对编程会话结束后清理代码变得更加简单。所有已解决的 bug 都存储了一个上下文，这一事实意味着只要 bug 被重新打开或类似的错误发生，我们都能立即恢复并使用过去的技术。
结束语
|
性能方面如何？
Mylyn 的设计确保它的上下文管理功能不影响 Eclipse 的性能。无论您使用的系统大小如何，Mylyn 都可以做到这一点，因为任务上下文只与您所做的少量交互对应，而与您使用的系统的大小没有关系。Mylyn 对内存或速度的任何明显影响都被视作一个 bug，都应该作为严重问题进行报告。而且，当没有活动任务时，Mylyn 的任务上下文管理是完全休眠的。要了解关于 Mylyn 性能的更多信息，请参阅 Mylyn FAQ（参见 参考资料）。要打开 Eclipse 的内存监视器，可以使用 Window > Preferences > General > Show Heap Status。
|
|
在这个由两部分组成的文章中，我介绍了如何用 Mylar 进行以任务为中心的编程。我展示了 Mylar 是如何通过将任务作为 Eclipse 中头等重要的部分对待而让您日常的工作变得相当地简单。我也介绍了 Mylar 如何使用 Eclipse 视图来帮助您聚焦于手边的任务，并为个人及团队的使用凸现这些任务的上下文。
Mylar 背后的哲学是少就是多。它将集成的任务管理和自动上下文管理工具结合使用，使您能够在不丢失上下文的情况下进行多任务处理，并确保您只需要查看感兴趣的信息。一个针对于将 Mylar 用于日常工作的业内开发人员所做的现场用户的研究已经验证了 Mylar 的任务上下文模型（参见 参考资料）。根据统计，这些用户的生产率有了显著的提高。而且，由于进行了数千个 bug/增强报告，Mylyn 2.0 很快成熟起来，满足其快速增长的用户社区的需要。自从在 2004 年 8 月创建 0.1 原型以来，我一直将 Mylyn 用于我的所有工作。和很多其它 Mylyn 用户一样，我已经无法想象还要手动寻找并识别工作中的相关信息的情景了。我完全依赖 Mylyn 来管理工作中的大量以任务为中心的交互和多任务处理。
如果 Mylar 支持您的任务存储库，它能使您的日常工作变得更加简单、更加有效且更加专注。如果它不支持您的任务存储库，您可以试着用它来完成个人任务。不管何种情况，都请使用 Bugzilla 集成来给出回馈并为您愿意看到被支持的其他连接器投票。（参见 参考资料）。您的贡献将帮助我们进一步改进 Mylyn，因为它将持续围绕严密的回馈机制快速发展，该工具本身允许我们通过用户社区建立这种回馈机制。其他 Mylyn 提交者和我一样，都期待收到您的回馈。
致谢
Mylyn 能获得成功并且走到现在，很大程度上得益于大量的用户参与，他/她们报告 bug 并贡献补丁。正是这种协作让 Mylar 从一个研究原型发展成为了 Eclipse 用户在日常工作中所依赖的一个重要部分。
Athen O'Shea、Robert Elves、Gail Murphy 和 Ducky Sherwood 对本文提供了有帮助的回馈。