避免这10项J2EE危机来确保JAVA项目成功

2019-11-18 12:26:19

字体：大中小

来源：转载

供稿：网友

　　在我作为开发者、高级开发者、架构师的经历中，我碰到过好的、差的甚至是丑陋的企业级java项目。当我问自己，是什么使一个项目成功而使另外的失败，我发现很难得到一个完美的答案，就似乎很难用成功来定义所有的软件项目。J2EE项目也不例外。因此，项目被分为不同级别的成功或失败。在这篇文章里，我主要想为您??读者朋友??揭示影响企业级JAVA项目的最大的10项危险。
　　
　　一些危险只是简单的延迟项目进度，一些却是错误的征兆，而还有一些使项目彻底没有成功的希望。尽管如此，假如具有良好的预备，征程开始前相关的知识和熟悉地形的向导，所有的都可避免。
　　
　　这篇文章结构简单，我会按以下方式来揭示各种危机：
　　
　　危机的名称
　　
　　项目阶段（PRoject phase）：危机所出现的项目阶段
　　
　　所牵连的项目阶段（Project phase(s) affected）：大多情况下，这些危机对随后的“项目阶段”有一种顺带（knock-on）的影响
　　
　　解决：避免危机的方式以及如何最小化它们的影响
　　
　　注释：有关该危机我想透露的观点，但不适合以前的分类
　　
　　如上所注，我们将在企业级JAVA项目背景和它的各个重要阶段中检查每一项危险。这些项目阶段包括：
　　
　　供给商选择：在你启动J2EE工程之前，挑选你的最佳工具组合的过程??不论是应用服务器还是咖啡品牌
　　
　　设计：不论是严格的瀑布模型还是"code it and see"（试翻译为：编码和运行查看）方式，我对设计都有这样一个观点：我做了充分的设计，因此我可以轻松的进入开发阶段。当我确切知道我在建造什么和如何建造时，我认为我的设计阶段完成。另外，在进入开发阶段之前，我使用设计模板来保证我对我自己问了所有正确的问题并且有了建议的解决方法。然而，我在该阶段同样也不害怕写代码；有时，这是回答问题的唯一方式，执行和模块化（ performance or modularity）。
　　
　　开发：这个阶段早期有大量工作要做。选择好的工具加上一个良好的设计并不总是意味着开发阶段会非常顺利，但的确会很有用。
　　
　　稳定性/负荷测试：在这个阶段，系统架构师和项目治理员将关注系统健壮性和构建质量，如确保系统的要害统计??并发用户数，失败的情境等。然而，直到这一阶段，代码质量和运行亦不应被忽略。事实上，你不能留一些差的或慢的代码到健壮性阶段来改。
　　
　　存在阶段[live]：这并不是真正的项目阶段，it's a date set in stone（想了半天也不知道怎么翻译:-{）这是关于预备的阶段，也是以前的错误的鬼怪出没的地方，不论是差的设计、开发还是错误的（开发工具）卖主的选择。
　　
　　图1阐释了这些项目阶段，以及对其有影响的各种因素（尤其是那些“忽然的[knock-on]”影响）
　　
　　Figure 1. Enterprise Java project phases
　　and their most likely reasons for failure.
　　Click on thumbnail to view full-size
　　image. (60 KB)
　　
　　危机1：没有理解Java,没有理解EJB,没有理解J2EE
　　
　　好，现在我将其分解成3个小主题来进一步阐释。
　　
　　描述：不理解Java
　　
　　项目阶段：开发阶段
　　
　　所牵连的项目阶段：设计，稳定阶段，存在阶段
　　
　　受影响的系统特性：可维护性，可测量性（scalability）,执行性
　　
　　征兆：
　　
　　重复实现已经包含于JDK核心APIs里的函数功能和类
　　
　　不知道下面所列的任何一项或几项是什么和它们能做什么（下面列出了一些示例）
　　
　　垃圾回收（train, generational, incremental, synchronous, asynchronous）
　　
　　对象什么时候可以被“垃圾回收”??
　　
　　Java里面继续特性的使用（及其权衡使用）
　　
　　方法重载
　　
　　为什么java.lang.String（此处替代你自己喜爱的类）似乎性能很差
　　
　　忽略Java引用的语义（与忽略EJB中值的语义相对）
　　
　　对非基本类型（nonprimitives）使用＝＝而不是实现equals()方法
　　
　　在不同平台上Java线程的进度如何（for example, pre-emptive or not）
　　
　　绿色线程VS本地线程
　　
　　热点[Hotspot](Hotspot <and why old performance tuning techniques negate Hotspot optimizations>)
　　
　　JIT以及什么时候好的JITs变差（不安装的Java编译器并且你的代码依然运行良好等）
　　
　　The Collections API
　　
　　RMI
　　
　　解决办法：
　　
　　你需要提高你的Java知识，尤其是了解它的优势和弱点。Java的存在已经远远超除了一门语言本身，同样重要的是理解这平台（JDK and tools）.具体的，你应当具有做一名Java 程序员的资格（假如你还没有的话）??你将对你有如此多不了解的东西感到吃惊。更进一步，将它作为你小组的一部分并向其他人推广，这种方式同样很有乐趣。更进一步，创建一份邮件列表，专心于Java技术并且保持下去。（我曾工作过的公司都有这些列表，大多数由于不更新而变的岌岌可危）向你的同伴学习??他们是你最好的资源。
　　
　　注：
　　
　　假如你或你团队中的其他成员不理解这门编程语言和这平台，你又怎么能期待建造一个成功的企业级Java应用呢？健壮的Java程序员对于EJB和J2EE假如鸭子对于水一般。与之相对，差的没有经验的程序员将建造一个质量差的J2EE应用。
　　
　　描述：不理解EJB
　　
　　项目阶段：设计
　　
　　所牵涉项目阶段：开发，稳定性阶段
　　
　　受影响的系统特性：可维护性
　　
　　征兆：
　　
　　EJBs在第一次被调用后就不再管了（尤其是处于就绪池[ready pool]的无状态session BEANS）
　　
　　非重用的（Nonreusable）EJBs
　　
　　相比于容器提供的，开发者不知道可依靠什么
　　
　　不符合规范的EJBs(fire threads,调用本地库，试图完成I/O操作等)
　　
　　解决：
　　
　　为提高你的EJB知识，花一个周末来阅读EJB规范（1.1规范有314页）。然后阅读2.0规范（524页）来了解为什么1.1规范不再适用和2.0规范能带给你什么。关注规范中那些能告诉你??应用开发者??什么是在EJB中合法的行为的部分。18.1和18.2节是开始的好地方。
　　
　　注：
　　
　　不要从你的提供商（指应用服务器或其他开发软件的提供商??译者）的眼里看EJB世界。确保你了解符合规范的EJB模型和非凡的实现之间的不同。这将保证在需要时你可以将你的技术带给你的提供商（或其他版本）。
　　
　　描述：不理解J2EE
　　
　　项目阶段：设计
　　
　　所牵涉项目阶段：开发
　　
　　受影响的系统特性：可维护性，可度量性（scalability），执行性
　　
　　征兆：
　　
　　“什么都是EJB”的设计
　　
　　手工配置而不是使用容器提供的机制
　　
　　客户安全实现??J2EE平台或许是在企业计算中最完全和完整的安全架构，从表现一直到后台；它全部能力很少被全部使用的
　　
　　解决：
　　
　　学习J2EE要害组件以及每个组件所能带来的优势和劣势。依次涉及各项服务，此处知识和能力一样重要。
　　
　　注：
　　
　　只有知识能解决这些问题。好的Java 开发者造就好的EJB开发者??一步步地可以完美地成为J2EE领袖的人。你获得越多的Java/J2EE知识，你在设计和实现方面的能力越强.Things will start to slot into place for you at design time.(想了半天也不知道怎么翻译:-{ )
　　
　　危机2：过度设计（无论是否是对于EJB）
　　
　　项目阶段：设计
　　
　　所涉及的项目阶段：开发
　　
　　受影响的系统特性：可维护性，可测量性（scalability），可执行性
　　
　　征兆：
　　
　　特大型EJBs
　　
　　开发者无法解释他们的EJBs做什么和它们之间的关系
　　
　　不可重用的EJBs,组件，或服务??当它们应该重用时
　　
　　当已经存在的事务可以完成任务时，EJBs 启动新的事务
　　
　　数据独立性被设定的太高（为了安全的目的）
　　
　　解决：
　　
　　解决过度设计的方法可以直接从XP（extreme programming）中找到：局部范围内，设计和编码实现最小的暴露的[bare minimum]部分来满足需求，而不要做的过多。当你需要意识到将来的需求，比如平均负载需求和在系统负载顶峰时候的行为，不要试图“第二次猜测”[second-guess]系统将来需要成为的样子。另外，J2EE平台为你定义了特性如可测度性和服务器底层需要捕捉的任务错误。
　　
　　注：
　　
　　除了上面的解决方式，使用设计模式??它们会显著的提高你的系统设计。EJB模型本身广泛地使用设计模式。如，每个EJB里的Home接口是一个寻找者和工厂模式的例子[Finder and Factory pattern].一个EJB的远程接口担当实际bean的实现的代理，也是容器截取调用和提供服务如透明化负载均衡的能力要害。忽略设计模式的价值是危险的。
　　
　　我不断强调的另一种危险是：为使用EJB而使用。你的应用的一些部分在不适合被当作EJB模型时候而被设计为EJB模型，你的整个应用似乎使用EJBs将获得无限价值。这是极度的过分设计，我曾看到完美的servlet 和 JavaBean 应用在并没有好的技术方面的原因而使用EJBs时，变的乱七八糟，不得不重新设计。
　　
　　危机3：未分离表示逻辑和商业逻辑
　　
　　项目阶段：设计
　　
　　所涉及的项目阶段：开发
　　
　　所影响的系统性能：可维护性，可扩展性，可执行性
　　
　　症状：
　　
　　大型且笨拙的jsps

上一篇：介绍关于IBM MQSeries的使用指南

下一篇：回眸Java10周年：J2EE从起源到目的一