爱华网当你开始着手组织一个企业级Java项目的时候，就如同开始同时轮回地扔好几个魔术小球： 业主关系处理、持续而漫长的设计开发过程，以及保持健全与完整性，等等。每一个“小球”都会带来其固有的风险，有些显而易见，有些则不易发现。尽管如此，所有这些风险都是完全可以避免的。本文作者Humphrey Sheil分析了威胁到企业级Java项目成功的10大风险， 并一一列出了风险规避的策略方法。
在过去这段时期里，我担任过程序员、高级设计师以及架构设计师等工作，见识过很优秀的企业级Java项目，也见识过不好的，甚至很"丑陋"的项目。有时候我会自己问自己，为什么一个项目可以取得成功，而另一个却走向失败？很难定义出某种规则或标准来表明各个不同的项目应该如何成功，J2EE项目也并不例外。但与此相反的是，我们可以从各个角度和层次上去考察项目失败的原因，如果很好地避开了这些风险，项目就可以取得成功。在本文中，我将提出排名前10位的企业级Java项目风险，供读者参考。
在各种各样的风险中，有些风险只是延缓了项目的进度，有些带来了一些不必要的工作，而另一些则会把成功的可能性彻底地消除。不过，如果预先有了足够的准备和清醒的认识，那么并没有不可避免的事情。这好比如果你是一名旅行者，你清楚地知道前面的道路在什么方向，做了充分的准备，又有一位清楚知道哪里有危险的向导，这样就会比较顺利地到达自己的目的地。
本文采用了以下结构来描述风险：
风险名称：风险的标题（使用粗体）
项目阶段：在哪个项目阶段会发生风险情况
影响阶段：会影响到以后的哪些阶段
症状： 风险产生时的症状
规避方案：如何规避风险或者把其对项目的影响降低到最小程度
备注： 风险相关的补充说明和提示
通过对企业级Java项目的仔细考察，本文将J2EE项目过程分解为以下几个阶段：
提供商选择: 在开始你的J2EE项目之前，要选择最合适的提供商，从应用服务器到开发工具组合，一直至工作期间享用的咖啡的厂商。
设计： 在遵照一系列严格的规范和软件工程方法的前提下，可以开始进行足够充分的设计，然后再很自然地进入开发阶段。在开发之前，要周全地考虑好正在做什么，以及如何往下做的问题。另外，我使用了一些设计模板来确信在进入开发之前，已经想到了所有的问题和可能的解决方案。但是，我有时也在该阶段做一些编码，有时候这样做可以回答一些问题，有效地判断出性能上和模块划分上的问题。
开发: 也就是程序开发阶段，选择一些好的开发工具，进行精良的设计等等，在这个阶段将显示其优越性，并且可以给开发带来很大的帮助。
稳定性/负载测试：在该阶段，系统架构师和项目经理应该冻结住产品特性，并把焦点放在质量以及产品参数（允许的并发用户数量，故障恢复情况，等等）上。质量和性能在该阶段应得到足够的重视。当然，最好应该避免在前阶段写出不良的运行缓慢的代码而到本阶段来作很多的修改。
成熟期：这不是一个真正的项目阶段，而是一个固定的准备阶段。过去潜伏的错误（来自于糟糕的设计和开发、错误的厂商选择）可能出现并影响你的系统。
风险1:没有真正理解 Java, EJB, 和J2EE
这个问题可以分解为3个部分，以便于分析。
描述: 没有真正理解Java
项目阶段:开发
影响阶段：设计、稳定性测试、成熟期
对系统性能的影响：可维护性、可扩展性、性能
症状：
重复开发了JDK核心API中的功能或类
不懂得以下列表中的某些项（这只是一些主题或者实际例子而已）：
垃圾收集器 (train, generational, incremental, synchronous, asynchronous)
对象在何时能被进行垃圾收集 -- dangling references
使用的继承机制及其权衡
over-riding和over-loading方法
为什么java.lang.String (在这里用你所中意的类代替) 提供的性能不好
Java中的pass-by参考语义和EJB中pass-by值的语义的比较
使用 == 或者使用equals() 方法 for nonprimitives
在不同平台上Java线程的运行顺序方式(例如是否是抢先方式的)
新线程和本地线程的比较
Hotspot技术(以及为什么旧的性能调整技术降低了Hotspot 的优化效果)
JIT，以及什么时候好的JIT变得不好(未安装的JAVA编译器，以及你的代码运行得刚够良好)
API搜集
RMI
规避方案：
你需要不断改进Java方面的知识，尤其是深入了解Java的优势和不足之处。Java的存在价值已经远不止是一种语言，理解平台(JDK及工具等)也是同样重要的。具体地说，你应该是经过认证的Java程序员，如果你不是的话，也许你有时会为还有那么多不知道的内容而感到惊讶。另外，你可以加入Java的邮件列表。以前我曾加盟过的每一个公司都加入了这样的邮件列表，从同行中学到技术，这将是你最好的资源。
备注:
如果你或者你的团队中的成员不真正了解编程语言和平台，怎么还能保持成功的希望呢？强干的Java程序员之于EJB和J2EE，就象是鸭子之于水一样。与此相反，比较弱的、没有经验的程序员只能开发出质量低劣的J2EE应用程序。
描述: 没有真正理解EJB
项目阶段:
设计
影响阶段:
开发、稳定化
对系统的影响:
维护
症状:
EJB在第一次被调用后没有再被使用到(尤其是stateless session bean)
没有重复利用价值的EJB
不理解开发者要做什么，容器提供什么
EJB没有依照规范定义(fire线程, 加载了本地库，试图执行I/O，等等)
解决方案:
要改进关于EJB方面的知识，可以找一个周末来阅读EJB规范 (1.1版有314页)，然后阅读2.0规范(524页!)，这样可以了解到1.1没有定义到的而在2.0规范中补充的内容。EJB开发者从18.1及18.2章节开始阅读是比较合适的。
备注:
不要从提供商的角度去看EJB，要确切地知道规范所支持的标准EJB模型和基于这些模型的特殊应用之间的区别。这也会有助于你迁移到别的提供商的时候所用。
描述: 没有真正理解J2EE
项目阶段:
设计
影响阶段:
开发
对系统的影响:
维护、扩展性、性能
症状:
"Everything is an EJB"的设计方式
用手工事务管理取代了容器-提供的机制
自定义方式的安全处理 -- J2EE平台在企业级计算中，从表示逻辑到后台处理，已具有最完整的集成安全架构；但很少用到其全部功能。
解决方案:
学习J2EE的关键组件，并且了解它们的优缺点，依次用它们替代每一个服务；“知识就是力量”在这里是行之有效的。
备注:
只有知识能够弥补这些问题。好的Java开发者会成为好的EJB开发者，此后也应逐渐成为J2EE得道高手。Java和J2EE知识掌握得越多，设计和开发工作就会越出色。在设计阶段一切都会有条不紊。
风险2: 过度设计(Over-engineering) (采用 EJB或者不采用EJB)
项目阶段：
设计
影响的项目阶段:
开发
对系统的影响:
维护、扩展性、性能
症状:
过于庞大的EJB
开发者无法解释EJB做什么，以及其间的联系
无法重复使用的EJB、组件或者服务
EJB启动了新的事务，而该事务本该由一个已存在的EJB启动
为了安全，把数据分离级别定得太高
解决方案:
过度工程化的解决之道直接来自于极限编程 (XP)方法：用最小的设计和编程来满足需求，除此之外别无它干。除非你需要明确知道今后可能的需求，如将来的负载要求，或者系统在最高负载下的表现，否则大可不必为系统将来的情况做太多考虑或猜测。另外，J2EE平台已经定义了可伸缩性及出错恢复等特性，可以让服务器系统为你进行处理。
在最小的系统中，只包含一个个小组件，这些组件只做一件事，只要把这些要求做到的进行实现，系统稳定性就已经得到了提高，而且，你的系统的可维护性会变得很强，在未来要增加功能以满足新的需求也将变得容易。
备注:
除了上面所列方案之外，可以推行设计模式 -- 它们可以显著地改进你的系统设计。EJB模型本身也广泛使用了设计模式。例如，每个EJB所带的Home 接口就是Finder和Factory模式的实例。EJB的remote接口扮演了一种实际bean实现的代理，并且对于提供容器的能力也是至关重要的，这些容器截取调用信号并提供诸如透明（transparent）负载均衡的服务。忽视设计模式也是危险的一部分。
我常提到要反对的另外一种危险是：仅仅是为了使用EJB而使用EJB。在你的应用中的某一部分可能并不需要EJB，甚至你的整个应用都不需要。这是过度工程化所走的极端，而且我确实也目睹了一些良好的servlet和JavaBean应用被重构为EJB，而这样做并没有很好的技术上的理由。
风险3: 没有将业务规则和逻辑表现形式相分离
项目阶段：
设计
影响的项目阶段：
开发
对系统的影响:
维护、扩展性、性能
症状:
过于庞大、没有边际的JSP程序
在业务逻辑改变的时候必须修改JSP
在要求改变界面显示的时候需要修改并重新配置EJB和其它后台组件
规避方案:
J2EE平台使你有机会将表示逻辑和导航控制相分离，进而与业务规则相分离。这被称为模式2结构。
备注:
可以使用具有一致性的设计来进行用户界面框架的连接。(例如可以使用taglib)，这将帮助你避免逻辑分离的问题。有许多现成的好的方法可供选择。对每一个分别进行评估，然后采用最合适的框架。
风险4: 没有在开发环境中进行适当的配置
项目阶段：
开发
影响的项目阶段:
稳定化、并发、成熟期
对系统的影响:
你的权衡
症状:
经过多日或数周的时间才能过渡到成熟系统
风险存在与过渡期，带有很多不确定性，有些主要的功能场景没有被测试到
实际系统中的数据和开发、测试中的数据不同
无法在开发者机器上进行组建
应用行为在开发、稳定化及产品环境中各不相同
规避方案:
解决之道是忠实地在开发环境中配置实际的环境，让开发所用环境接近于要实施产品的环境。如果未来环境是JDK 1.2.2及Solaris 7，那么不要在JDK 1.3及Red Hat Linux上进行开发。对于所用的应用服务器也是如此。同样，要快速地看一下产品数据库中的数据，并将这样的数据用于测试。不要依赖于人工创建的数据。如果产品数据很敏感，则要使之变得不敏感，然后把它配置起来。开发中未能预期到的产品数据将对以下过程产生破坏：
数据检验规则
系统测试行为
系统组件构建(特别地包括：EJB-EJB以及EJB-数据库)
最为糟糕的是，这样还可能产生异常、空指针，以及你从没见过的问题。
备注:
开发人员常把安全性问题放到稳定化阶段才开始解决。要防止这样的陷阱产生，你也可以花费同样多的时间在业务逻辑中改进安全性。
成熟期是一个复杂的过程，其中充满了技术性问题和非技术性问题。你可能会陷于想不到的一大堆问题中，这就是成熟化所意味的一切。开发及稳定化环境过程为你提供了制造更多这样的问题，以及发现这样的问题的地方，不断去做，就可以大大减少风险。
你做的工程越多，你就越能了解什么是可行的，什么是不可行的。你可以对工程问题进行记录，以避免同样的错误重复发生。
