如果没有坚定的基础，那么 Enterprise JavaBeans（EJB）项目肯定会杂乱无章。Scott W. Ambler 说明了为什么应在开发的早期阶段定义环境，并且提供了定义环境的技巧。
在项目早期，如果遵循 Rational Unified Process (RUP) 或
Enterprise Unified Process
(EUP)，那么通常在考虑环境工作流的问题时，您需要定义项目小组的技术环境。这包含了选择、然后安装项目小组将使用的相应标准、指南和开发工具。
要在这一阶段取得成功，您必须考虑以下因素：
-
承认工具、标准和指南一直在改善。今天您选择的工具在明天可能会被其竟争对手所取代。那是否意味着您要换工具？很可能不会，因为购买、安装工具以及再次培训整个小组的成本也许会超过该工具新功能带来的好处。此外，工具供应商会很快发布工具的新版本，以使工具不被淘汰，那最后您就会在开发环境之间犹豫不决：如果那样的话，您就永远不会开始考虑真正的工作
― EJB
软件开发。更改工具，特别是在项目中期，可能会是一个危险且代价昂贵的过程。如果您发现工具达不到您的期望，那么应该考虑放弃它，如果有新版本，就应考虑升级它。但如果工具适用，那么就应该坚持用下去。对于标准和指南也应这样。 - 尽可能在项目早期建立项目环境。项目环境为开发小组如何共同工作打下基础，因此需要尽早打下这个基础。将工具选择留到最后一刻的小组会发现他们没有足够的时间来培训每个人以使他们有效地适应环境。将标准和指南的选择留到项目后期会导致前后矛盾的工作、小组内的冲突、失败的评论，有时严重到甚至需要重做。
-
产品评论非常有用，但不是盖棺定论。当您在网上快速搜索时，可以找到许多独立的产品评论
― 尤其是在杂志中，如JavaPro, Java Report和
Software
Development（请参阅参考资料）―
这些评论可以向您详细介绍每种工具可以做什么。评论有助于您缩小选择范围，但您仍需要在您自己的环境中评估这些工具以便做出最终选择。您还应该考虑雇一个顾问来帮助您定义项目环境并确保您做出了最适合自身情况的选择。而且，特定工具的新闻组或门户网站，如
The Server Side（请参阅参考资料）很好地说明了什么工具可以真正起作用。
- 项目环境必须反映方法／过程。当项目环境和软件过程不一致时，您的小组会很快发现需要花大量精力以便能保持进度（因为需要解决不足的项目环境造成的难题）。例如，如果采用迭代和递增式的方法进行开发，那么就需要高度支持回归测试的测试工具。否则，就要手工制作自己的回归测试套件。此外，如果您已经选择使用用例驱动的方法，那么您显然需要支持用例开发的工具。
- 根据需要选择项目环境。如果不知道要购买什么，那么为什么要买呢？例如，在选择测试工具之前，需要首先鉴别要执行的测试类型。
- 不要评估每个类别中的每一项。Java
开发人员可以使用几百种开发工具，但您在项目中只使用其中少数几种开发工具。将选择范围缩小到几种候选工具，找一些关于这些工具的评论，测试这些工具的性能，选择环境，然后接着前进。请记住
KISS 原则：把事情简单化，傻瓜！（Keep It Simple,
Stupid!） -
仅当从某个工具中得到好处时才使用它。如果每个开发人员都能够最大限度地利用工具，那么为每人购买价值
3
千美圆的工具是很划算的。但是，如果开发人员只使用工具能力的一小部分，而某些更简单且更便宜的工具也能提供这样的能力，那么这就是笔非常糟糕的买卖。此外，请记住，只要稍做搜索，就可以在网上找到许多免费工具。 -
期待培训。您不能将某个工具、标准文档或软件过程放到某个人的桌上，并期望他们立即精通它。有关这方面的信息，请参阅上周的
tip on EJB
training。（还请注意，下一周的技巧文章将探讨进一步的培训问题。） - 采用现有标准、指南和工具。虽然尝试编写自己的开发指南、构建自己的工具或亲自集成几种工具通常都很诱人，但是应该在不费什么精力的情况下才这样做。否则，最好采用尽管不够完美但却非常好的项目环境，继续进行实际的开发软件工作。
注：本技巧文章摘录自将在 2001 年 8 月出版的 Mastering
Enterprise JavaBeans, Second Edition
。
