j2ee项目10大风险

《j2ee项目10大风险》由会员分享，可在线阅读，更多相关《j2ee项目10大风险（14页珍藏版）》请在金锄头文库上搜索。

1、J2EE 项目 10 大风险（使我受益匪浅的一篇文章） http:/ 作者: 猫小 发表于：2003-11-06 09:41:13 b:65da3ba8b1避免本文所列之 10 大 J2EE 风险，确保企业级 Java 项目成功/b:65da3ba8b1 作者：Humphrey Sheil 翻译：Blueski 说明： 本文已在 51CMM 网站中国系统分析员杂志第 3 期刊载。 原文在 http:/ 摘要 当你开始着手组织一个企业级 Java 项目的时候，就如同开始同时轮回地扔好几个魔术小球：业主关系处理、持续而漫长的设计开发过程，以及保持健全与完整性，等等。每一个“小球”都会带来其固有的风

2、险，有些显而易见，有些则不易发现。尽管如此，所有这些风险都是完全可以避免的。本文作者 Humphrey Sheil 分析了威胁到企业级 Java 项目成功的 10大风险， 并一一列出了风险规避的策略方法。 - 在过去这段时期里，我担任过程序员、高级设计师以及架构设计师等工作，见识过很优秀的企业级 Java 项目，也见识过不好的，甚至很丑陋 的项目。有时候我会自己问自己，为什么一个项目可以取得成功，而另一个却走向失败？很难定义出某种规则或标准来表明各个不同的项目应该如何成功，J2EE 项目也并不例外。但与此相反的是，我们可以从各个角度和层次上去考察项目失败的原因，如果很好地避开了这些风险，项目就

3、可以取得成功。在本文中，我将提出排名前 10 位的企业级 Java 项目风险，供读者参考。 在各种各样的风险中，有些风险只是延缓了项目的进度，有些带来了一些不必要的工作，而另一些则会把成功的可能性彻底地消除。不过，如果预先有了足够的准备和清醒的认识，那么并没有不可避免的事情。这好比如果你是一名旅行者，你清楚地知道前面的道路在什么方向，做了充分的准备，又有一位清楚知道哪里有危险的向导，这样就会比较顺利地到达自己的目的地。 本文采用了以下结构来描述风险： b:65da3ba8b1风险名称：风险的标题（使用粗体） /b:65da3ba8b1 项目阶段：在哪个项目阶段会发生风险情况 影响阶段：会影响到

4、以后的哪些阶段 症状： 风险产生时的症状 规避方案：如何规避风险或者把其对项目的影响降低到最小程度 备注： 风险相关的补充说明和提示 通过对企业级 Java 项目的仔细考察，本文将 J2EE 项目过程分解为以下几个阶段： 提供商选择: 在开始你的 J2EE 项目之前，要选择最合适的提供商，从应用服务器到开发工具组合，一直至工作期间享用的咖啡的厂商。 设计： 在遵照一系列严格的规范和软件工程方法的前提下，可以开始进行足够充分的设计，然后再很自然地进入开发阶段。在开发之前，要周全地考虑好正在做什么，以及如何往下做的问题。另外，我使用了一些设计模板来确信在进入开发之前，已经想到了所有的问题和可能的解

5、决方案。但是，我有时也在该阶段做一些编码，有时候这样做可以回答一些问题，有效地判断出性能上和模块划分上的问题。 开发: 也就是程序开发阶段，选择一些好的开发工具，进行精良的设计等等，在这个阶段将显示其优越性，并且可以给开发带来很大的帮助。 稳定性/负载测试：在该阶段，系统架构师和项目经理应该冻结住产品特性，并把焦点放在质量以及产品参数（允许的并发用户数量，故障恢复情况，等等）上。质量和性能在该阶段应得到足够的重视。当然，最好应该避免在前阶段写出不良的运行缓慢的代码而到本阶段来作很多的修改。 成熟期：这不是一个真正的项目阶段，而是一个固定的准备阶段。过去潜伏的错误（来自于糟糕的设计和开发、错误的

6、厂商选择）可能出现并影响你的系统。 OK，以下让我们进入 top 10 项目风险！ - b:65da3ba8b1风险 1:没有真正理解 Java, EJB, 和 J2EE/b:65da3ba8b1 这个问题可以分解为 3 个部分，以便于分析。 描述: 没有真正理解 Java 项目阶段:开发 影响阶段：设计、稳定性测试、成熟期 对系统性能的影响：可维护性、可扩展性、性能 症状： 重复开发了 JDK 核心 API 中的功能或类 不懂得以下列表中的某些项（这只是一些主题或者实际例子而已）： 垃圾收集器 (train, generational, incremental, synchronous, a

7、synchronous) 对象在何时能被进行垃圾收集 - dangling references 使用的继承机制及其权衡 over-riding 和 over-loading 方法 为什么 java.lang.String (在这里用你所中意的类代替) 提供的性能不好 Java 中的 pass-by 参考语义和 EJB 中 pass-by 值的语义的比较 使用 = 或者使用 equals() 方法 for nonprimitives 在不同平台上 Java 线程的运行顺序方式( 例如是否是抢先方式的) 新线程和本地线程的比较 Hotspot 技术(以及为什么旧的性能调整技术降低了 Hotspo

8、t 的优化效果) JIT，以及什么时候好的 JIT 变得不好(未安装的 JAVA 编译器，以及你的代码运行得刚够良好) API 搜集 RMI 规避方案： 你需要不断改进 Java 方面的知识，尤其是深入了解 Java 的优势和不足之处。Java 的存在价值已经远不止是一种语言，理解平台(JDK 及工具等)也是同样重要的。具体地说，你应该是经过认证的 Java 程序员，如果你不是的话，也许你有时会为还有那么多不知道的内容而感到惊讶。另外，你可以加入 Java 的邮件列表。以前我曾加盟过的每一个公司都加入了这样的邮件列表，从同行中学到技术，这将是你最好的资源。 备注: 如果你或者你的团队中的成员不

9、真正了解编程语言和平台，怎么还能保持成功的希望呢？强干的 Java 程序员之于 EJB 和 J2EE，就象是鸭子之于水一样。与此相反，比较弱的、没有经验的程序员只能开发出质量低劣的 J2EE 应用程序。 描述: 没有真正理解 EJB 项目阶段: 设计 影响阶段: 开发、稳定化 对系统的影响: 维护 症状: EJB 在第一次被调用后没有再被使用到(尤其是 stateless session bean) 没有重复利用价值的 EJB 不理解开发者要做什么，容器提供什么 EJB 没有依照规范定义(fire 线程, 加载了本地库，试图执行 I/O，等等) 解决方案: 要改进关于 EJB 方面的知识，可以

10、找一个周末来阅读 EJB 规范 (1.1 版有 314 页)，然后阅读 2.0 规范(524 页!) ，这样可以了解到 1.1 没有定义到的而在 2.0 规范中补充的内容。EJB开发者从 18.1 及 18.2 章节开始阅读是比较合适的。 备注: 不要从提供商的角度去看 EJB，要确切地知道规范所支持的标准 EJB 模型和基于这些模型的特殊应用之间的区别。这也会有助于你迁移到别的提供商的时候所用。 描述: 没有真正理解 J2EE 项目阶段: 设计 影响阶段: 开发 对系统的影响: 维护、扩展性、性能 症状: Everything is an EJB的设计方式 用手工事务管理取代了容器-提供的机

11、制 自定义方式的安全处理 - J2EE 平台在企业级计算中，从表示逻辑到后台处理，已具有最完整的集成安全架构；但很少用到其全部功能。 解决方案: 学习 J2EE 的关键组件，并且了解它们的优缺点，依次用它们替代每一个服务；“知识就是力量”在这里是行之有效的。 备注: 只有知识能够弥补这些问题。好的 Java 开发者会成为好的 EJB 开发者，此后也应逐渐成为J2EE 得道高手。Java 和 J2EE 知识掌握得越多，设计和开发工作就会越出色。在设计阶段一切都会有条不紊。 - b:65da3ba8b1风险 2: 过度设计(Over-engineering) (采用 EJB 或者不采用 EJB)

12、/b:65da3ba8b1 项目阶段： 设计 影响的项目阶段: 开发 对系统的影响: 维护、扩展性、性能 症状: 过于庞大的 EJB 开发者无法解释 EJB 做什么，以及其间的联系 无法重复使用的 EJB、组件或者服务 EJB 启动了新的事务，而该事务本该由一个已存在的 EJB 启动 为了安全，把数据分离级别定得太高 解决方案: 过度工程化的解决之道直接来自于极限编程 (XP)方法：用最小的设计和编程来满足需求，除此之外别无它干。除非你需要明确知道今后可能的需求，如将来的负载要求，或者系统在最高负载下的表现，否则大可不必为系统将来的情况做太多考虑或猜测。另外，J2EE 平台已经定义了可伸缩性及

13、出错恢复等特性，可以让服务器系统为你进行处理。 在最小的系统中，只包含一个个小组件，这些组件只做一件事，只要把这些要求做到的进行实现，系统稳定性就已经得到了提高，而且，你的系统的可维护性会变得很强，在未来要增加功能以满足新的需求也将变得容易。 备注: 除了上面所列方案之外，可以推行设计模式 - 它们可以显著地改进你的系统设计。EJB模型本身也广泛使用了设计模式。例如，每个 EJB 所带的 Home 接口就是 Finder 和Factory 模式的实例。 EJB 的 remote 接口扮演了一种实际 bean 实现的代理，并且对于提供容器的能力也是至关重要的，这些容器截取调用信号并提供诸如透明（

14、transparent）负载均衡的服务。忽视设计模式也是危险的一部分。 我常提到要反对的另外一种危险是：仅仅是为了使用 EJB 而使用 EJB。在你的应用中的某一部分可能并不需要 EJB，甚至你的整个应用都不需要。这是过度工程化所走的极端，而且我确实也目睹了一些良好的 servlet 和 JavaBean 应用被重构为 EJB，而这样做并没有很好的技术上的理由。 - b:65da3ba8b1风险 3: 没有将业务规则和逻辑表现形式相分离/b:65da3ba8b1 项目阶段： 设计 影响的项目阶段： 开发 对系统的影响: 维护、扩展性、性能 症状: 过于庞大、没有边际的 JSP 程序 在业务逻辑改变的时候必须修改 JSP 在要求改变界面显示的时候需要修改并重新配置 EJB 和其它后台组件 规避方案: J2EE 平台使你有机会将表示逻辑和导航控制相分离，进而与业务规则相分离。这被称为模式 2 结构。 备注: 可以使用具有一致性的设计来进行用户界面框架的连接。(例如可以使用 taglib)，这将帮助你避免逻辑分离的问题。有许多现成的好的方法可供选择。对每一个分别进行评估，然后采用最合适的框架。 -