J2EE项目开发风险汇总

2016-12-31 00:00:00嘉辉 J2EE培训

  在各种各样的风险中,有些风险只是延缓了项目的进度,有些带来了一些不必要的工作,而另一些则会把成功的可能性彻底地消除。下面小编总结了J2EE项目开发的风险,提供给大家参考!

  风险1:没有真正理解 Java, EJB, 和J2EE

  这个问题可以分解为3个部分,以便于分析。

  描述: 没有真正理解Java

  项目阶段:开发

  影响阶段:设计、稳定性测试、成熟期

  对系统性能的影响:可维护性、可扩展性、性能

  症状:

  重复开发了JDK核心API中的功能或类

  不懂得以下列表中的某些项(这只是一些主题或者实际例子而已):

  垃圾收集器 (train, generational, incremental, synchronous, asynchronous)

  对象在何时能被进行垃圾收集 dangling references

  使用的继承机制及其权衡

  overriding和overloading方法

  为什么java.lang.String (在这里用你所中意的类代替) 提供的性能不好

  Java中的passby参考语义和EJB中passby值的语义的比较

  使用 == 或者使用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: 过度设计(Overengineering) (采用 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上进行开发。对于所用的应用服务器也是如此。同样,要快速地看一下产品数据库中的数据,并将这样的数据用于测试。不要依赖于人工创建的数据。如果产品数据很敏感,则要使之变得不敏感,然后把它配置起来。开发中未能预期到的产品数据将对以下过程产生破坏:

  数据检验规则

  系统测试行为

  系统组件构建(特别地包括:EJBEJB以及EJB数据库)

  最为糟糕的是,这样还可能产生异常、空指针,以及你从没见过的问题。

  备注:

  开发人员常把安全性问题放到稳定化阶段才开始解决。要防止这样的陷阱产生,你也可以花费同样多的时间在业务逻辑中改进安全性。

  成熟期是一个复杂的过程,其中充满了技术性问题和非技术性问题。你可能会陷于想不到的一大堆问题中,这就是成熟化所意味的一切。开发及稳定化环境过程为你提供了制造更多这样的问题,以及发现这样的问题的地方,不断去做,就可以大大减少风险。

  你做的工程越多,你就越能了解什么是可行的,什么是不可行的。你可以对工程问题进行记录,以避免同样的错误重复发生。

  风险5: 选择了错误的提供商

  项目阶段:

  提供商选择

  影响阶段:

  设计、开发、稳定化/负载测试,成熟化

  对系统的影响:

  可伸缩性、性能、可维护性及稳定性

  症状:

  开发人员要使用更多的时间来处理工具方面的问题,而不是很有成效地使用这些工具

  为了应付已知的和未知的问题,而不得不进行显著的系统重新设计

  在不同的工具之间很难进行集成(应用服务器与IDE工具,IDE工具与调试器,源码控制与合成工具,等等)

  对于IDE工具和调试器等,开发人员往往排斥它们,而推崇自己所喜欢的工具

  规避方案:

  为了避免风险5,你需要一个很好的提供商选择过程,风险10的规避也适用于此。

  要真正衡量一种IDE工具是否最合适的方法是真正地进行使用。而唯一来评估一种J2EE应用的方法是建立一种概念试验来进行证明,在试验中要包含你的应用框架。事实上,你也不希望在花费了3个月时间进行了培训和开发后,在使用时又发现一些bug。

  假设在开发到一半的时候,突然发现你的工具集有问题,那么你早应该知道,有些工具确实比另一些更重要。如果你所选的应用服务器不能充分满足你的需要,你只好修改原先的设定。如果IDE不好,则需要设置最低限度的代码标准,并让开发人员任意选择他们认为最为有效的工具。

  备注:

  要真正了解到哪一个供应商对一项特殊的任务来说最合适,其实并不是一件一次性决定的事情。你需要不断地跟踪与评估这个市场。例如,在过去的一年里我用过4种不同的IDE工具,这取决于我使用了什么样的应用服务器、平台,是否使用EJB等。

 1/2    1 2 下一页 尾页

[J2EE培训]相关推荐

[J2EE培训]相关栏目推荐
查看更多
上一篇:J2EE应用服务器 下一篇:Servlet上传文件注意事项