J2EE项目开发风险

时间：2021-04-19 13:10:35 J2EE培训我要投稿

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等。

　　风险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只是为了便携式处理的方便

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

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