风险6: 不了解你的提供商

　　项目阶段：

　　提供商选择

　　影响阶段:

　　提供商选择阶段后面的所有阶段：设计、开发、稳定化/负载测试、成熟化

　　对系统的影响:

　　可维护性、可伸缩性、性能

　　症状:

　　开发所用周期超过了最坏预测的周期1/3以上

　　提供商已经提供了某项功能，但开发者在不知道的情况下重新进行了该项功能的开发

　　规避方案:

　　为了规避这样的风险，你可以尽可能地订阅提供商的网上资源，例如邮件列表、新闻组、版本信息(尤其是其中的bug修复补丁的说明等)，你能从中得到无法估量之多的收获。

　　一旦你已经选定了提供商，那么立即就要投资进行培训，并且尽可能赶在项目启动以前。然后，逐渐在团队中建立起对此提供商的认识及信任。试着建立几个EJB并部署一下，再用你的表示层技术 (Swing GUI, JSP等)来调用它们。如果你既要搭建开发环境，又要同时在实现项目目标，就会产生一些不必要的冲突。实际上，我也见到过一直没有进行构建过程的情况：“我们没有时间。”因此，这些工作必须提早进行。有些人会说：“我们的计划中没有为我们提供这些时间。”我的回答是：“你的计划中并没有不给你时间使你不这么做啊。”

　　备注:

　　在J2EE世界里，各提供商产品的技术兼容性究竟如何?让我们看一下IBM和BEA的具体分析吧。两者都分别在各自的应用服务器中支持EJB 1.1。那么，实际上BEA WebLogic 5.1和IBM WebSphere 3.5究竟有多少相似之处呢?

　　BEA WebLogic和IBM WebSphere的系统配置和管理方式几乎完全不同。

　　IBM在WebSphere中采用了全面的GUI环境，而与之相对的是，BEA 在WebLogic中提供一整套命令行。

　　IBM WebSphere使用IIOP来和CORBA异常进行通讯，这些异常对程序员来说是可见的;WebLogic根本没有CORBA构造，而缺省使用t3协议。

　　WebSphere和Visual Age衔接紧密，而WebLogic是IDE无关的，实际上，你几乎可以使用任何的开发工具。

　　由此可见，差异还是相当多。如果你是一种应用服务器的专家，并不意味着你就是所有应用服务器的专家。这种区别体现在IDE，debugger，build工具，配置管理等等方面。具备某提供商的某项特殊工具的使用经验，可以在评估该提供商的竞争对手产品时具有一些便利。但是，不要奢望在不同产品之间进行无缝的转移或衔接。因此，你不得不花费足够多的时间在熟练掌握这些工具上。

　　风险7: 设计中没有充分考虑到可伸缩性和产品性能

　　项目阶段：

　　设计

　　受影响的项目阶段:

　　开发、负载测试及成熟化

　　对系统的影响:

　　可伸缩性、性能、可维护性

　　症状:

　　无法忍受的速度缓慢

　　系统给服务器端增加的沉重负担，而无法利用到一些聚簇技术。

　　规避方案:

　　把精力集中于性能和可伸缩性方面的需求，明确开发中要达到的性能指标。如果你需要每秒50个事务，而你的EJB设计只能提供40个，那么你就需要考虑替代方案，诸如存储过程，批处理，或者重新考虑OLTP的设计。

　　尽可能让你的提供商加入进来，他们应该非常清楚其产品的强项和弱处在哪里，然后给你提供最直接的帮助。

　　备注:

　　本风险与风险2 (overengineering)似乎有些冲突。实际上，两者相互影响。 我对风险2给出的解决方案是，只在绝对必要的情况下才进行构建。而对与性能和可伸缩性，你要预先划分好什么是必须要做的。

　　如果你实现就识别出系统需要非常强的可伸缩性，并把它作为一个比较关键的需求，那么你首先需要选择一个带有很强的簇支持及事务型缓存的应用服务器。另外，你应把业务对象设计为EJB，从而可以充分利用服务器架构的优势。 XP也没有问题，你仍然是只做绝对必要的工作。

　　我把这样的观点看作是一种检查和平衡的方法。我们只需要最简单可能性的系统，该系统只提供客户所需要的功能与行为即可。

　　风险8: 陈旧的开发过程

　　项目阶段：

　　开发

　　影响阶段:

　　稳定化，成熟化

　　对系统的影响:

　　可维护性、代码质量

　　症状:

　　项目计划看上去似乎类似于瀑布模型: “首先草构设计，然后在一个很长的周期里进行开发。”

　　由于不存在构建(build)过程，每次构建都象是噩梦

　　构建的日期等于损失开发的日期，因为什么也没有做成

　　在集成以前组件没有分别被充分地测试过，而集成测试意味着将2个不稳定的组件放在一起，然后查看堆栈里的跟踪结果。

　　规避方案:

　　好的软件方法学将提高你的软件生命期。此前我已经提到XP方法，你可以在网上找到很多这方面的资料。

　　备注:

　　JUnit可以用来进行单元测试，Ant工具可以进行编译与构建，这2种工具都对XP方法有很好的支持。

　　风险9: 没有好的架构方式

　　项目阶段：

　　开发

　　影响阶段:

　　开发、稳定化、成熟期

　　对系统的影响：

　　可维护性、可伸缩性、代码质量

　　症状:

　　在代码中使用了很多次的核心库中发现Bug。

　　没有建立日志标准 于是系统的输出很难读取或者解析。

　　不良的不一致的异常处理。在有些站点中我们甚至可以看到，出错信息直接暴露给了最终用户，例如在用户在他的购物车核帐时发送一条SQLException堆栈跟踪信息，用户接着会怎么做?打电话给数据库管理员要求对primary key约束进行修补吗?

　　以下任务已经被开发者以各种方式处理了无数次了，这些都有必要放在任何构架设计的第一批目标中。

　　日志

　　异常处理

　　与资源的连接(数据库，名字服务等)

　　构建JSP页

　　数据合法性检查

　　规避方案:

　　我是一个轻方法学的信徒和实践者。我在JavaWorld 上的第一篇文章 "Frameworks Save the Day" 就是研讨在企业Java环境中的架构。即使你已经开始开发了，此时考虑一下架构仍然是值得的。可能你不得不忍受一下重构带来的异常处理和日志处理，但从长远来看还是值得的，这样即省时间又省钱。

　　备注:

　　让我们想一下在构架中基于组件开发的可重用性的不同等级。第一级别是plumbing，具有0.9以上的可重用比例，也就是说，有90%的项目可以对它重复利用。 服务定义得越详细，重用比例就越低。换句话说，我需要构建一个会计服务，但要提供这些资源与用法的管理，以便于其它50%项目中可以对它们进行重复利用。但是对那些项目来说，能得到这些资源，那真是太好了!

　　风险10: 项目计划和设计基于市场效应，而脱离了技术现实

　　备注: 不断有新人加入到Java/EJB的开发领域中来，不理解Java的人数一般比想象中还要多。

　　项目阶段：

　　所有阶段都会受到影响，包括提供商的选择

　　影响阶段:

　　所有阶段都会受到影响

　　对系统的影响:

　　可维护性、可扩展性、设计质量、代码质量

　　症状:

　　轻率地进行技术决策，认为EJB只是为了便携式处理的方便

　　选择提供商的时候没有随即进行产品的试用

　　在项目的生命周期内还需要更换工具

　　规避方案:

　　不要轻易相信项目外部的任何人的看法，这些人可能已经有一些既得利益，不要相信提供商的说法(除非你早已经了解)，也不要相信白皮书。如果你要取得来自真实世界的关于应用服务器的建议，可以在网上取得。你还可以下载这些工具进行评估，用它们做一些原型，并运行一下其中的样例。(好的提供商都有这样的样例)。

　　总的来说，为你的项目选择最好的提供商及工具需要时间，而你可能没有太多的时间。你可以把选择范围限制在34个对象，然后用一周时间进行比较和检验。最后从中选出比较满意的工具和产品。

　　备注:

　　如果你缺少J2EE经验，则可能会在项目前期就产生问题。在前期所确定的决策会影响整个过程，并进而影响项目的成功。好的J2EE咨询专家将能够帮助你选择好的提供商，并为设计和开发刻划出一个好的构形。

　　仅仅只有这10项风险吗?

　　10只是一个特定的数字，显然，还有更多更多的风险会存在。只是我可以保证的是，如果你克服了所列的各项风险，那么你的项目会有出色的表现并已打好了成功的基础。

　　还有一项需要注意，即没有任何东西可以代替经验和计划。如果你没有经验，那么一定要想办法取得并积累。千万不要一边做项目一边进行培训。在开发之前要预先做好充分的准备，最好是在设计以前就进行准备。可以让你的团队接受Java/J2EE顾问的指导，并确保这样的指导能够传递到整个其他的团队成员。

　　最后，还有必要提到以下几点：

　　软件工程的外界影响

　　什么时候进行单元测试，什么时候进行集成测试?

　　设计模式

　　异常处理

　　结论

　　总的说来，以上10大风险是你在企业级Java项目开发过程中将面对的主要困难。我也相信在你的旅程中一定还有更多的陷阱，但我比较确信的是我所提到的风险已经涵盖了主要的问题。最后让我们按照优先级重新列举一下10大风险：

　　没有真正理解Java, 没有真正理解EJB, 没有真正理解J2EE

　　过度设计(Overengineering)

　　没有将业务规则和逻辑表现形式相分离

　　没有在开发环境中进行适当的配置

　　选择了错误的提供商

　　不了解你的提供商

　　设计中没有充分考虑到可伸缩性和产品性能

　　陈旧的开发过程

　　没有好的架构方式

　　项目计划和设计基于市场效应，而脱离了技术现实