评论专栏: Joey Bernal：您的门户项目是健壮的还是脆弱的？

新项目，老问题

最近，我在一次婚礼上遇见了一位同事，当谈到他当前的项目时，他告诉我他的团队中有一些开发人员总是犯那些最简单的错误。尽管我们一边喝着香槟酒一边笑谈这个问题，但冷静下来思考一下，作为一个行业，我们应该避免出现这样的情况。有趣的是，该团队中的其他开发人员资历较深，如果他们能够认真地检查资历较浅的成员所编写的代码，他们就可以轻松地将自己的一些知识和智慧传递给后者，帮助提高团队的整体水平，并改进最终代码的质量。

有一点非常重要，团队在开发过程中所作出的决定（以及悬而未决的问题）可能在项目的开始阶段看上去很合理（或者甚至不合理），但随着项目的推进可能会产生很大的影响。这对于任何人来说都算不上什么新闻，但我总是发现一些项目仍然面临着许多的问题，尤其是对于门户项目，它们开始时一切正常，但很快地驶入了“无人地带”，所得到的是一堆支离破碎的并且没有经过检查的代码、版本散乱的组件，并且导致环境崩溃或失去控制。

我所提供的大多数意见和建议，无论是在相关的文章和报告中还是在我的博客中，从本质上说都是概要性的，所以这些观点通常适用于各类读者。然而，我认为专业人员常常在从理解概念到实现这些概念的过程中碰到障碍。也许是因为并没有真正地理解问题，或者完全不赞同某些建议。遗憾的是，很难为广大读者提供详细而精确的建议。在大多数情况下，对于详细而精确的建议，会出现“不是所有情况都适用同一模式”的问题，它可能对某个项目来说是最佳的，但却完全不适合于另一个项目。

然而有一个不争的事实，要避免可能出现失控状态的基本项目问题，最好的方法是找出适合于您的团队的最佳实践和指导原则。通常，充实这类的细节内容并不是很难。但需要一些规则来创建这些指导原则，并且需要相应的规则来强制实施它们。然而这样做，通常会对您的项目和环境产生直接的和积极的影响。

我所指的是什么类型的最佳实践和指导原则呢？在我们更深入地研究细节内容之前，如果您能够关于您的门户项目或环境向自己提出下列问题，那么将会对您有所帮助：

1. 当出现问题的时候，您要花多长时间才能够诊断出这些问题？
2. 您是否清楚应用程序的下一个版本或发行版将会对生产环境产生什么样的影响？
3. 新的开发团队是否清楚如何在您的环境中创建合适的应用程序，您对此是否满意？
4. 在出现了应用程序或后端故障时，是否能够快速恢复运行？

要进行全面的评估，可能还需要添加更多的问题，但这已经足够了解基本的情况。请注意，在第一个问题中，我并不是指找出产生问题的根本原因。我认为这通常是一个目标或要求，即通过管理产生更多的工作，然后取得相应的效果。我将更关注于最佳实践和周而复始的组织性规则，甚至反复地讨论它，直到我认为所有人都能够认识到这个问题，然后再继续其他重要的主题。随着一群新的门户开发人员开始构建新的项目，似乎这个周期又从头开始了。

回页首

管理或被管理

当谈到脆弱的门户时，一时很难得到准确的答案。要产生积极的影响，管理和规则是非常重要的。项目团队往往过多地寻求这些问题的技术解决方案，虽然工具可以提供更好的静态分析和概要分析功能，但仍然需要相应的规则以便更有效地使用这些工具。如果没有人负责检查或将这些结论贯彻到底，那么即使使用世界上最优秀的工具也无济于事。因此，要更好地利用该工具所提供的方法，最好将精力用在进行其他的活动上，比如可视代码检查。

在检查项目计划时，通常主要的任务之一是进行单元测试，而这类工作人们往往谈论得很多，但事实上很少有人能够真正地去执行，或能够完整地或很好地执行。当我更深入地了解团队如何安排进行单元测试的计划时，常常得到各种不足以令人相信的回答。您可以看一下我的博客，我以前曾详细地讨论过关于在门户中进行单元测试的思想。通常在项目超过时间限度的情况下，人们之间的交流主要集中于将现有的行式项目作为缓冲。

相反，项目计划中似乎并没有涉及到进行代码检查。我很喜欢将它们称为代码“走读 (walkthrough)”，而不是听起来更正规的代码“检查 (review)”。这样可以减少对单词“检查”可能带来的工作的恐惧，而不会降低其重要性。显然，这是项目活动中最基本的内容之一，但事实上却是最少被执行的任务之一。根据我的推测，出现这种情况往往是因为下列的原因：

• 时间。时间或缺少时间看起来是进行代码检查的主要障碍。在有些情况下，检查工作可能是多余的，但通常这个借口是站不住脚的，您可以想一下不进行检查将会带来的后果。

• 技能和认识。我认为，不进行检查在很大程度上与我们的建筑设计师文化有关。较高级别的架构师可能看到自己深奥的技术技能逐渐削弱，但仍然希望（或者可能只是试图）维持技术专家的身份。这里给出一个建议，您不需要成为所有领域的专家，并且也不可能做到。无论您是否了解如何编写代码（无论开发团队是否了解这一点），您都可以成为一个真正的领导者，并帮助简化开发过程。让团队去完成领域标识的工作，以实现简化代码的目的。

• 来自开发人员的阻力。没人喜欢自己的工作遭受批评。是的，至少我不喜欢，但这是整个过程中一个重要的部分。我曾见过这样的开发人员，他们对进行检查工作非常抵触，但有时候，要顺利完成项目必须强制进行这种工作。开发人员需要记住，这不是您自己的代码，它属于整个团体或者某个用户。这里谈一下我个人的体会，有一次，我有意地逃避检查团队中某个开发人员的代码，因为这个人非常难以相处。结果项目截止期限临近，却没有写出可用的代码，这可把我吓坏了。当我最终强迫自己进行检查时，我才发现这段代码正是罪魁祸首，因此不得不对其中的大部分内容进行重写。

有关代码检查的更多信息，developerWorks 的门户项目系列中的第 5 篇文章提供了示例门户开发标准文档。该文档概述了代码走查的思想，以及如何在项目进行的过程中执行这项工作。

还有另一个问题需要问您，对于改进代码库的质量、提高开发人员的技能级别、并向团队中的新成员传递更多关于不同组件的知识，假设您只能够采取一种措施，那么究竟应该做什么呢？最近在一次会议上，我为许多门户专业人员做了一个报告，我的核心建议之一就是代码检查的思想。我甚至建议，项目经理制定计划并管理团队，以确保这些工作的执行。有一些听众显然很关心这个思想，有的人可能不具备执行这项任务的专业技能，或者开始这项任务的执行并不是他们的责任。他们是正确的，这项任务应该由架构师以及其他技术负责人来承担，但是如果他们没有（或没有能力）这样做，那么其他的人应该主动地承担这项任务。

回页首

组织中的标准

除非设立了相应的标准对其进行度量，否则代码检查可能无法起到很大作用。如果您把大量的时间用在创建用例和体系结构的决策上，而并没有拟定开发人员需要遵守的基本规则，那么代码检查将毫无作用。最近，我开始宣传使用 Wiki 来创建和维护组织标准的思想。我认为 Wiki 非常适合于团体中的成员用来定义和细化相关的标准，而各个团队都可以使用这些标准。考虑到代码检查，您必须形式化相关的标准并推广它们，这样才能真正地实施这些标准。IBM® 本身也广泛地使用了 Wiki。（尽管我们内部的内部网标准没有采用 Wiki 的方式，但是很容易通过 Web 获得所有的这些标准。）例如，IBM 内部曾尝试使用这种方法帮助创建消息传递组件的各个组在全局范围内定义消息传递标准。必须确保不同的组件能够正确地理解这些消息，而这些组件可能由两个（或更多）完全不同的团队创建。这种方法非常适合于帮助多个团队轻松地获得相关标准，并可以根据需要对其进行更新。

事实上作为一个行业，我们在这个领域中往往很失败。我们经常将软件开发与其他类型的工程实践相比，但是您能够指出另一个不具有统一的规范、标准和检测过程的行业吗？尽管已经开始进行一些尝试以便使得我们能够走上正确的方向，但还需要付出更大的努力。我的目标是在门户模式站点中添加一个新的部分，这部分内容将重点关注于门户开发标准。

回页首

最佳实践是什么？

这是任何人都真正希望弄清楚的。要使自己的项目取得成功，哪些事情是我应该做的，哪些事情是不应该做的呢？这也是最难回答的问题之一。“不是所有情况都适用同一模式”，还记得我的这个观点吗？有许多通用的最佳实践，但并没有具体地针对不同情况的特点。如果对许多项目团队常常问我的问题进行一下总结和改写，所得到的是“请告诉我什么地方可能出现错误！”认真地考虑一下，对于这个问题，您能够得到一个可靠的答案吗？即使我能够列举出所有潜在的问题，大家会阅读并遵循这些指导原则吗？

人们进行了一些工作以列举简单的技术指导原则。Stefan Hepper 发表了一些指导性的文章，其中列举了在门户应用程序中特定的应该做的和不该做的事情。Tim Hanis 和我就这个主题进行过几次讨论，尝试确定如何最好地充实我们的建议，并使之能够直接应用于新的项目。Tim 在他的 Portlet 开发手册中讨论了许多这方面的主题。在特定的项目中作出战术性的决策，以及在整个组织的范围内作出战略性的决策，我往往在这两者之间作出抉择。如果一个项目团队要我给出直接的建议，我可能会建议使用 log4j 或 Commons Logging。同时，这可能会与碰到类似问题的其他团队之间产生直接的竞争，这将在以后导致混乱。这个示例清楚地解释了，为什么总是强调要为您的项目和组织作出正确的选择。

我承认，有时基于技术工具的解决方案可以帮助解决许多问题。事实上，我最近曾碰到过一些情况，技术解决方案是可行的。但对于大多数情况，这类解决方案仍然需要一些自定义的代码，以处理组织中特定的问题，实际上将其转换成了服务类型的解决方案。我的观点是，对于解决您的环境中的问题，增加规则并不总是完整的答案。我相信，某些规则是需要的，并且在完成了预先的努力之后，要真正实施该规则也并不是非常困难的。

回页首

最后的建议

我最后的建议是尽可能不断地进行改进。我在婚礼上碰见的那位同事认为团队的技术负责人不愿意进行代码检查，是因为时间不够，或者因为他们对自己在该技术方面的专业技能并不自信。我要重申一下，这并不能成为不进行检查工作的原因，一个更明智并且正确的方法是，吸收一位能够进行独立代码和体系结构检查的技术专家。目标是在开发阶段中尽可能早地进行这项工作，以便及时地实现所做的更改，并且定期地重复这项工作，从而能够得到持续的改进。即使是微小的改进也能够对性能和可维护性产生积极的影响，并在某些异常的项目周期中使您保持理智。如果时间紧张，那么即使是在项目快结束的时候也需要进行这类活动，这样可以避免出现尴尬的局面，以及强行投入到生产环境中却无法取得成功所带来的潜在的成本。

如果在检查过程中没有发现明显的错误，那么您可以继续展开后续的工作，并可以确信项目将会顺利地进行。

对了，想知道我对那位朋友的离别赠言吗？请记住，“这应该是充满乐趣的”！