J2EE项目风险
一、概述
当您开始着手一个企业级JAVA项目的时候，您必须对很多方面进行权衡：供应商关系，为保证完整性在设计和开发阶段的过度设计。每个都会带来与生俱来的的一些风险，其中一些是非常明显的，而其他则不怎么明显。但是所有这些风险都是可以避免的。在Humphrey Sheil的这篇文章中，他分析了有可能对企业级JAVA项目的成功造成威胁的10个风险，并且描述了避免方法。
在我当程序员、高级程序员和系统构架师的各个时期，我见证了许多企业级JAVA项目的喜怒哀乐！当我思考到底是什么导致项目失败或者成功的原因的时候，我发现很难找到一个完美的答案，因为为所有的软件项目定义什么是成功是很难的。J2EE项目也不例外。而且，项目的成败不是绝对的。在这篇文章中，我将展示影响企业级Java项目成败的前10个风险，并将他们展示给您。
一些风险会延迟项目的速度，一些则是错误的岔路，另外一些则会使项目完全失败！但是，只要有好的准备、有关的知识储备以及对其有一定了解的知道者，这都是可以避免的。
这篇文章的结构很简单；我将对每个风险按照下面的格式讲述：
风险名称：描述风险的一行文字。
项目阶段：风险发生的项目阶段。
受影响的项目阶段：在很多情况下，风险是影响项目的后边阶段的。
征兆：风险的相关征兆。
方案：如何避免这种风险以及将其对项目的影响降低到最小。
备注：我没有在前边条目中提到的但是必须要提醒的关于风险的一些东西。
我们将在企业级Java项目的重要的阶段检查每个风险。项目涉及到的阶段有：
选择服务提供商：在开始J2EE项目之前选择最好的工具组合－从应用服务器到什么品牌的咖啡。
设计：严格的瀑布方法学模型和“编码然后运行”方法都依赖于设计：我进行足够的设计然后就可以开始开发了。我对设计阶段进行全面思考以保证在开始开发之前我已经思考了所有的问题和解决方案。但是、我并不害怕在这个阶段编码，有时这是回答有关性能和模块性问题的唯一途径。
开发：在这个阶段我们前期阶段的工作的效果将会显现出来。好的工具加上好的设计并不意味着开发阶段会很顺利，但是确实有帮助！
稳定性负载测试：在这个阶段，系统构架师和项目经理要将系统特性冻结，开始关注于构建质量，并保证系统的重要参数指标满足要求－并发用户数，失败次数等。但是，质量和性能不能在前边的阶段被忽略。您不可能写低质量或运行速度缓慢的代码留到以后再去修正。
维护：这其实并不是工程的一个阶段，它只是一个时间段。这个阶段都涉及到了准备阶段。前期的错误（糟糕的设计以及开发阶段对供应商的错误选择）将会显现出对你项目构成威胁。
图一显示了项目各个阶段的不同的风险（特别是对后期造成的风险）
好了，先不管别的乱七八糟的东西了，咱们开始看一看10个最大的风险吧！
二 风险分析
（一）风险1：不懂Java、EJB或者J2EE。
我将逐条分析前面所说的三个东西。
描述：不懂Java。
工程阶段：开发。
受影响阶段：设计，稳定阶段，维护阶段。
受影响的系统特性：可维护性、可量测性以及性能。
现象：写JDK核心API已经有的函数和类。
不知道下面所列的这些东西（下边列出的只是一些例子而已）：垃圾收集；什么时候实例会被垃圾收集――悬挂引用问题；Java中的继承机制（或者他们的折衷选择）；方法覆盖和重载；为什么 java.lang.String（这里它替代了你喜欢用的类）会导致糟糕的性能；Java的引用传递（与EJB中的传值相比较）；使用＝＝与实现equals() 方法这种非初级应用相比较；Java在不同平台上的不同的线程调度策略（例如空闲还是非空闲）；绿色线程与本地线程的比较；热点（为什么旧有的性能调节技术否定热点优化）；JIT以及什么时候好用的JIT变得不好用（例如不安装JAVA_COMPILER的时候您的代码仍然完好的运行等等）；Collections API
RMI（远程方法调用）
解决方案：
您必须加深java的相关知识，特别是关于它的强项和弱项。Java已经超越了语言的范畴。理解它相当于理解一个平台（JDK和相关工具）。具体来说，如果您还没有取得Java程序员认证您必须去取得－您会惊讶的发现您还这么多不了解的。如果把这做为你项目组并且将它推行到每一个人就更好了，而且也更有趣。如果有可能的话家里一个邮件列表来讨论Java技术并且保证它的活跃那就更好了。（我工作国的每个公司都有这样的邮件列表，但是他们大部分由于没有足够的人气而奄奄一息）。向你的开发同事学习――这就是最好的来源。
备注：
如果您或者您的开发团队成员不懂这门语言以及这个平台的话，您能希望您的团队能开发出成功的企业级Java程序吗？高级的Java程序员使用EJB和J2EE将会非常容易。相反，低级的或者是经验不足的程序员则会将J2EE系统弄得质量很差。
描述：不懂EJB
项目阶段：设计
项目影响阶段：开发、运行
影响到的系统特性：可维护性
现象：EJB只被使用一次（特别是返回到等待池衷的无状态会话Bean）
不可重用的EJB
不知道程序员要做什么，容器能提供什么。
不符合规范的EJB（使用线程，调用本地方法，尝试访问IO等等）。
解决方案：
Description: Not understanding J2EE
为了增加您对EJB的知识，请拿出一个周末的时间看一下EJB规范（1.1版有314页）。然后阅读2.0规范以了解1.1规范没提供了什么而2.0提供了什么。特别要注意告诉做为应用程序开发者的您在EJB中怎样做才是规范的做法的那些章节。
备注：
不要从供应商的角度看EJB世界。你一定要了解EJB规范和特定容器的EJB实现之间的差别。这将有利于您在必要的时候将开发经验用到其他供应商（或其他版本）上去。
项目阶段：设计
项目影响阶段：开发
受到影响的系统阶段：可维护性，可扩展性，性能
现象：
一切都是EJB的设计。
使用手动事务管理而不是使用容器提供的机制。
定制安全机制――J2EE平台提供了尽可能完善的集成化的安全构架，从头到尾我们很少用到它的全部功能。
解决方案：
学习J2EE的关键部件以及它们优缺点，并把它们列成表格形式。弄清楚它们的每项服务，记住“知识就是力量”。
备注：
只有知识才能修补这些错误。一个好的Java程序员将会是一个好的EJB开发者。您掌握的J2EE和Java的知识越多，您在设计和实现阶段做的就会更好。这些将会在设计阶段开始显示作用。
风险2：过度设计（使用EJB还是不使用）
项目阶段：设计
受影响项目阶段：开发
受影响系统特性维护、扩展性，性能
征兆：
过大的EJB
开发者无法解释他们的EJB在做什么以及他们之间的关系。
不可重用的EJB、组件或者服务
本应该使用已有事务的时候EJB启动了一个新的事务
为了安全，把数据独立级别设太高
解决方案：
对过度设计的解决方案直接来自于极限编程（XP）方法学。用最小的设计和编程来满足需求，除此之外其他的不考虑。除非你需要明确知道今后可能的需求，如将来的负载要求，或者系统在最高负载下的表现，否则大可不必为系统将来的情况做太多考虑或猜测。另外，J2EE平台已经定义了可伸缩性及出错恢复等特性，可以让服务器系统为你进行处理。
在最小的系统中，系统由一个个小的组件组成，每个组件完成一个单独的工作。这样系统的可重用性得到改善，系统的稳定性也同样得到改善。而且，系统的可维护性得到增强，并且未来新的需求的加入也将变得更简单。
备注：
除了采用上边的解决方案，也可以采用设计模式。它们可以显著改善您系统的设计。EJB模型本身也广泛的使用了设计模式。例如，每个EJB的Home接口都是Finder和Factory模式的例子。远程接口则是真实Bean的代理，对于提供容器的能力也是至关重要的，这些容器截取调用信号并提供诸如透明负载均衡的服务。忽略设计模式的价值将会让是非常危险的。
另外一个我常常警告的风险就是为了EJB而使用EJB。在你的应用中的某一部分可能并不需要EJB，甚至你的整个应用都不需要。这是过度设计所走的极端，而且我确实也目睹了一些良好的servlet和JavaBean应用被重构为EJB，而这样做并没有很好的技术上的理由。
风险3：没有将业务规则和逻辑表现形式相分离
项目阶段：设计
受影响项目阶段：开发
受影响系统特性维护、扩展性，性能
征兆：
过大的没有边界的Jsp
您发现您在业务逻辑发生变化的时候在编辑JSP页面。
显示上的改变迫使你修改并重新部署EJB和其他后台组件
解决方案：
J2EE平台使你有机会将表示逻辑和导航控制相分离，进而与业务规则相分离。这叫做Model 2框架。如果您已经陷入这个陷阱，您可以使用重构。
备注：
可以使用具有一致性的设计来进行用户界面框架的连接（例如taglibs）浙江有助于您在您的项目中将业务规则和逻辑表现形式相分离，不需要您创建一个新的GUI框架，现在已经有很多稳定的实现。对他们一次进行评估，然后选出一个最符合您需要的框架来。
风险4: 没有在开发环境中进行适当的配置
项目阶段：开发
受影响的项目阶段: 运行、并发、成熟期
受印象的系统特征:你的权衡
征兆：
经过多日或数周的时间才能过渡到成熟系统
风险存在与过渡期，带有很多不确定性，有些主要的功能场景没有被测试到
实际系统中的数据和开发、测试中的数据不同
无法在开发者机器上进行组建
应用行为在开发、稳定化及产品环境中各不相同
解决方案：
风险4的解决方案是忠实地在开发环境中配置实际的环境，让开发所用环境接近于要实施产品的环境。如果客户的运行环境是JDK 1.2.2和Solaris 7，那么不要使用JDK 1.3 和Red Hat Linux进行开发。而且不要在一个应用服务器开发而在另一种应用服务器中运行。使用实际产品的数据进行测试，而不要依靠于手工录入的模拟数据。如果产品数据很敏感，则要使之变得不敏感，然后把它配置起来。开发中未能预期到的产品数据将对以下过程产生破坏：
数据校验规则
系统测试行为
系统组件构建(特别地包括：EJB-EJB以及EJB-数据库)
最为糟糕的是，这样还可能产生异常、空指针，以及你从没见过的问题。
备注：
开发者常常将安全问题留到稳定阶段才解决（程序界面很好的运行，我们现在加上用户校验的东西吧）。要防止这样的陷阱产生，你也可以花费同样多的时间在业务逻辑中改进安全性。
成熟期是一个复杂的过程，其中充满了各种非技术的和技术的问题。你可能会陷于想不到的一大堆问题中，这就是成熟化所意味的一切。开发及稳定化环境过程为你提供了制造更多这样的问题，以及发现这样的问题的地方，不断去做，就可以大大减少风险。
你做的工程越多，你就越能了解什么是可行的，什么是不可行的。你可以对工程问题进行记录，以避免同样的错误重复发生。
风险5：选择错误的供应商
项目阶段：供应商选择
受影响项目阶段：设计，开发，维护，测试，运行
受影响系统特性：性能，可维护性，稳定性。
征兆：
开发者花费大量时间跟开发工具脚劲而不是使用他们进行高效率的开发。为了解决已知的或未知的Bug，系统需要重构，并且不同的开发工具几乎无法整合（应用服务器和IDE，IDE和调试器，源码控制和构架工具等等）
对于IDE，调试器等，开发者会赞同使用他们喜欢的工具。
解决方案：
为了避免风险5，您需要一个好的供应商选择流程，风险10也适用于此。
对于IDE，唯一的评估它的途径就是使用它。评估J2EE实现的唯一途径就是构建一个试验并对您关心的系统的特性进行试验。您肯定不希望您花费了3个月时间开发并进行了培训后才发现系统有很多的bug。
如果在开发过程中，您对您的工具集有疑问怎么办呢？当然一些工具肯定会比另一些表现好。如果你现则了不满足您要求的应用服务器，那么请吸收它然后修改开发规范。如果IDE不好用，请降低代码标准（使用制表符还是空格）。让开发者选择使他们更高效的开发工具。
备注：
要知道最好的供应商和工具不是对一个特殊任务的一次性工作。您要经常进行市场评估。例如，我在过去的12个月中使用了四个不同的IDE，这依赖于我的应用服务器、平台还有是否编写EJB。
风险6：不了解供应商
项目阶段：供应商选择
受影响项目阶段：供应商选择之后的所有阶段－设计，开发，维护，测试，运行
受影响系统特性：可维护性，可扩展性，性能
征兆：
开发时间比预想的长了超过33％，开发者重新发明轮子――开发供应商已经提供的需求的特性。
解决方案：
为了避免不了解供应商造成的风险，订阅所有供应商提供的资源，您可以在邮件列表、新闻组和版本备注（特别是已修正的bug列表）中得到您评估需要的信息。
一旦确定了供应商，请尽快开始培训，在项目开始前越早越好。下一步，构建一个快速模型来证明，从而打消开发团队的顾虑。构建EJB并部署它们，然后在表达层（Swing GUI, JSP等等）中调用他们。如果您在进行系统开发的时候才进行开发环境的搭建，那么环境搭建常常会造成麻烦。我看到过这样的项目，他们没有一个构建流程，“我们没有时间了”。当团队必须工作到11点的时候表现的更为明显，每晚他们只是将程序拼起来然后运行。磨刀不误砍柴工－这样做会节省你很多时间。有人会说“我们计划中中没有安排这个时间”，我说“您的计划中没有不去这么做的时间”
备注：
不同的供应商对J2EE的特定的实现技术是不同的。让我们看看一个两个供应商的例子：IBM和BEA。IBM采用图形化的WebSphere环境，恰恰相反，BEA则为WebLogic提供很多的命令行工具。IBM的WebSphere使用IIOP进行通讯，并抛出CORBA异常（对程序员非透明），WebLogic则没有采用CORBA底层构架而是默认使用t3协议。
WebSphere与Visual Age是紧密结合在一起的，而Weblogic则是可以使用多种IDE的。您可以使用几乎任何IDE进行WebLogic的开发。
他们之间是还是有不同点的。你是一种应用服务器的专家并不意味着你是其他应用服务器的专家。上述各点体现在各个方面：IDE、调试器、构建工具，配置管理等等。在一个特定工具上熟悉的人可以在评估该提供商的竞争对手产品时具有一些便利。但是这并不意味着您可以把程序在不同程序之间进行无缝链接。因此，您必须花费一些时间来熟悉这些工具。
风险7：没有考虑可扩展性和性能
项目阶段：设计
受影响项目阶段：可扩展性，性能，可维护性
征兆：无法接受的慢速的系统（不应该服从重构）
服务器端被很强的负载所压迫，导致不能充分发挥集群技术的全部优势。
解决方案：
在这个风险中，我们接近我们系统性能的可扩展性需求－我们在您开始开发之前要知道您需要什么参数。如果您需要每秒50个并发事务数，而您的实体Bean只能提供40个，那么您需要寻找其他可选的解决方案，例如存储过程、批处理或者重写联机事务处理系统。
您要让供应商参与到系统性能需求中去――他们知道他们产品的强项和弱项，这样可以对您有相应的帮助。
备注：
没有为可扩展性和性能进行设计看起来与第二个风险（过度设计）相冲突。实际上他们是互为补充的。对于风险2我提倡只实现真正需要的功能。通过说明性能和可测试性要求，您可以设定需求的上界。
如果您认为可扩展性是一个重点要求的话，您就需要首先选用一个带集群支持的应用服务器，可能还需要一个事务缓冲池支持。您还需要象EJB这样的业务组件引擎，因为您可以充分利用服务器的系统构架。在这一点上极限编程将不会有任何问题，在极限编程中系统是用来满足客户的功能和行为要求的。
风险8：缺乏开发过程控制。
项目阶段：开发
受影响阶段：维护，运行
受影响系统特征：可维护性，代码质量。
现象：
项目计划看起来象瀑布模型：首先根据草案设计系统，然后我们就坐下来开始漫长的编码。因为构建过程不存在，所以构建成了一个梦魇。构建的日子也就是停止开发的日子，因为我们什么都没得到。
组件在集成之前没有经过足够的测试。集成测试意味着将两个不稳定的组件捆在一起，然后到调试器的堆栈树中去观察他们。
解决方案：
一个好的软件方法学将会节省您的生命。我已经提过了XP；在参考资料章节中我给出了相关的站点。在那里您会对XP有更深入细致的了解。
备注：
我无法想象我不使用Junit进行单元测试和Ant进行构建的日子（这两个免费工具支撑着XP方法学）。如果想了解更多关于Junit和Ant，请参考资源这一章。
风险9：使用框架失败
项目阶段：开发
受影响项目阶段：开发、维护、运行
受影响系统特征：维护性，可扩展性，代码质量
征兆：
核心类库中的Bug在代码中多次使用
没有设定日志标准，所以输出不能此采用脚本进行读取和分析
错误的或不协调的异常处理。我再有的站点看到，终端用户可以看到系统的低级错误；例如当用户要将他们购物车中的商品付费的时候出现一个SQLException 的stack trace。用户应该怎么办呢？难道要求他给数据库管理员打电话，然后要求他修改主键约束错误？
下面的任务必须以某种方法进行处理，并且要成为任何构架的第一目标：
日志：
异常处理
夺得到某些资源的连接（例如数据库、命名服务）
构建Jsp 页面
数据校验
解决方案：
我对轻量级框架非常情有独衷，实际上，我在JavaWorld上的第一篇文章就是《框架节省时间》，它讨论的就是企业及Java环境衷的框架。如果您已经在开发了，那么通过使用一个框架您仍然能够收获颇丰。在重做这些东西的时候，您将会遇到诸如错误处理和日志之类的错误，但是从长远来看这会大大节省时间和金钱。
备注：
当在选择框架和基础组件开发的时候，您必须思考他们的不同的重用级别。第一级别的重用率时0.9甚至更高，也就是说项目中90％将会用到它。
风险10：项目计划和设计建立在市场炒作上，而非实际的技术上。
备注：一开始我没有把风险10加上来，后来我发现很多人都对企业级Java有误解，特别是对于刚刚解除这个领域的人。
项目阶段：所有受影响的阶段，特别是供应商选择阶段尤甚。
受影响项目阶段：所有阶段。
受影响系统特性：可维护性，可扩展性，设计质量，编码质量。
征兆：
因为EJB是可移植的所以在技术选型方面不重视。
在供应商选择时没有进行产品试验
在项目生命周期衷需要更换开发工具。
解决方案：
别
轻信项目外任何有即得利益人得说法。也就是说：不要轻信供应商（除非您对他们非常了解），不要轻信白皮书（因为他们是供应商花钱买的）。如果您需要真正得
建议，那么请查找关于它得相关评论。甚至，可以下载您想评估得工具，在上边试着开发一个小的系统原型。不要运行工具中自带的例子（每个好一点的供应商都会
加上这个）。
为了概括总结，花一定的时间为您的项目选择正确的供应商和工具集。缩小您的选择范围到三四个供应商，然后进行测试。对您选择的IDE、应用服务器进行为时一周的测试和构建。熟悉您将要用来开发项目的工具。
三 总结
只有这10个风险需要注意吗？
10只是一个武断的与其他风险分割开的数字而已，还有很多其他的风险。我就能说出很多。但是即使如此，如果您能说出我这列出的这些风险，我就可以保证您的项目会非常优秀而且必定成功。
如果还有我不想让您独这篇文章的原因就是：这不是经验和计划的代替品。如果您没有经验，那么请去积累。不要依赖项目开发中的培训会起多大的兆月年个。在开发前请做好心理准备。请Java和J2EE指导者对你们团队进行全程指导、把握项目方向，并和较少经验的团队人员一起成长。
最后，我写的越多我想到需要说的东西越多：
软件工程的社会因素
单元测试与集成测试（什么时候进行测试？）
设计模式
异常处理
唉，不能再写了。等待着新文章吧，祝君好运！
结论：
这里列出了10个风险，他们能够概括您进行企业级java开发的时候遇到的大部分问题。我坚信，您在开发过程中，还会面对很多其他的缺陷，但是我也坚信我已经概括了主要的问题。我们翻个个，将10个风险按着优先级排序：
不懂Java,不懂EJB,不懂J2EE
过度设计（使用EJB还是不使用）（设计模式）
没有将业务规则和逻辑表现形式相分离
开发时没有部署
选择了错误的供应商
不了解您的供应商
没有设计可扩展性和系统性能
陈旧的开发过程
没有使用框架
项目计划和设计建立在市场炒作上，而非实际的技术上。