编者按：本系列文章是关于Oracle用户生产力套件（UPK）的，共分两部分。本文为原文中的第二部分，主要关注程序库和在线编辑器的使用。第一部分介绍了介绍定义标准和保证内容安全的实践方法。

　　程序库的使用

　　在开始开发之前，要设计好程序库的结构，并与团队就如何使用该库达成一致。让所有团队成员知道如何有效地使用程序库非常重要，这是为了有效地存储文档，把它们存储到它们该放的地方。另外，对程序库设计和使用进行文档化说明也很重要。这可能是你开发策略的第二部分。

　　在设计你的库结构时，越简单越好。就像使用互联网一样，你一定不希望必须点进去十层链接才能得到你想要的或你需要的东西。这一点在这里同样成立。我们要尽量减少文件夹层的数量。最好是三次或者更少次数的点击就能得到我们需要的内容。过于复杂的结构会令人困惑和沮丧。为你们自己设计可用的结构，但要保持简单。

　　你可以以任意方式组织你们的库，按项目、作者、模块、角色、文档类型或者任何方式都可以。重要的一点是，在你们开始开发前，要花时间考虑所有选项并为你的项目设计最好的结构。

　　一旦你的设计确定了，要分配专人管理程序库的结构。这个人应该负责库中机构的创建与维护。对库的维护与设计一样重要。如果你不根据你们的设计维护该库，文档会丢失并会带来一些返工。此外，监视并纠正损坏的链接也很重要，当有人从库里删除文档时就可能发生链接损坏。你可以使用“取消链接”功能帮助检查。

　　如果你想从另一个库导入内容，导入功能会处理待导入内容中的结构。但它并不会接受待导入文件的库结构。因此，在导入前调整你的库结构，使之保持一致，导入时就会更轻松和清晰。

　　最后，请使用你们自己的命名规则。结构和标准为你的团队提供了舒适性和安全性；如果你遵守定义好的结构、命名规则以及其它标准，它们就会一直保持良好组织，想找的文档就能很快找到，返工会最少。

　　大纲编辑器的使用

　　在创建大纲结构时脑子里要想着最终结果。考虑一下你想怎么样发布你的文档或者你想怎么样把它们打包给受众，即大纲编辑器中建立结构的框架。有许多种方式来做，按模块、角色、功能等等。另外，这里不存在绝对正确或者错误的答案。只要按照你最终想交付给受众的形式来组织就好了。

　　许多人都想知道在哪里完成工作最合适，在大纲编辑器中还是在库里。这真的是一个有争议的问题。

　　使用大纲编辑器时，指向其它文档的链接是自动创建的。而在库中，你必须手动创建从你的文档到其它文档的链接。我的建议是使用大纲编辑器，这样一来我就不必考虑如何链接我的文档，或者如果我从大纲编辑器中删除了一个文档该怎么处理，因为我的链接是自动创建的。我在删除一个文档之后，总会回去重新检查一下我的链接，这是为了确保没有其它与删除文档有关的问题链接。你也可以在删除之前使用解除链接功能。

　　记住，如果你从大纲编辑器中删除了文档，该工具不会从库中把它删除，该文档仍然留在库里。因此，如果它链接到了多个文档，其它链接仍然可用。如上所述，必须检查并确保其它链接没有问题。

　　内容的发布

　　你可以根据需要决定是否发布内容。第一次创建文档时，你若准备好生成输出，就可以发布你的资料。在发布过程中，可以随意选择你想要的输出方式。你可以全选或者只选择一部分。一旦发布了，就不需要再次发布，除非你更新了主题。下面是一些建议：

• 指定一个或两个“发布器”负责发布所有内容
• 创建一个正式的变更请求（维护和支持）流程
• 出于维护原因，需要时可以重新发布

　　UPK项目的筹划

　　为您的项目建立规则和标准很重要，更重要的是确保这些规则有相应的问责制。确保团队中的每个成员都理解这些规则和标准，监控工作并确保所有与多用户环境协作的成员都能坚持遵守。否则，你没理由花大量时间进行规划。

　　建立适合公司的安全路径。你可以根据实际情况判断是否需要限制开始还是可以收紧限制。你可以随时根据需要调整安全性。关键是要给其中投入一些想法，并设计你的安全路径，这样个体成员就可以有效和高效地履行他们自己的工作。

　　适当使用检入和检出功能也能使员工有效和高效地工作。它还有助于查看还有谁可能对某个文档有输入，同样你也能看到谁对文档有检出。此外，管理员们还可以查看检入和检出历史。

　　在建立大纲和库结构时，要尽量保持简单。不要设置太多结构,让布局过于复杂。很多时候，少则得，多则惑。

　　最好是在开发之前就做好计划。你的计划越完备，实施起来就越井然有序；你的工作越井然有序，整个团队就越高效。开发工作有很多事情要考虑准备。只要记住，如果你有一个团队，不管所有成员是不是在同一个办公室，你都可以在多用户环境中使用最佳商业实践，使大家有效地协作。

　　扩展阅读：

　　Oracle用户生产力套件(UPK)最佳实践第一部分