J2EE项目危机

　　你需要提高你的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规范。然后阅读2.0规范来了解为什么1.1规范不再适用和2.0规范能带给你什么。关注规范中那些能告诉你什么是在EJB中合法的行为的部分。

　　注:

　　不要从你的提供商(指应用服务器或其他开发软件的提供商??译者)的眼里看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时，变的乱七八糟，不得不重新设计。