[翻译]J2EE项目危机[3]|中文方案文档站(www.cn

http://www.cn-doc.com/_soft_java_tech_doc/2005_08_19_22/20050819225453810_3.htm
其他部分请打开源网址
危机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
• 当商业逻辑改变时，你发现你需要编辑jsp文件
• 显示需求的改变迫使你编辑和重新部署ejbs和后台组件

解决：

j2ee平台给你将表示逻辑同导航和控制分离并最终与商业逻辑分离的机会，这被称为model2 结构（参见 resources ）。如果你已经掉进圈套，一种比较呆板的做法或许有用。你应该至少使 那些大部分自我包含的片断保持“垂直瘦小”[thin vertical slices](这是说，我如何布局的一个片断要同如何更改我的用户名和密码分开)。在你系统中使用这种方式来重新组织。

注：

在你的工程中使用一种连接ui框架（如标签库）坚固的设计将帮助你避免逻辑分离问题，不要为你自己需要的gui框架设计而烦恼，这会为你带来诸多执行方面的好处。依次评估每一种框架，然后选择最适合你的那种。

危机4 ：未在你开发的地方部署

项目阶段：开发

所影响的项目阶段：稳定阶段，并行阶段，存在阶段

所影响的系统特性：正常的心智（your sanity）

征兆：

• 持续多日及1周的向真正应用系统的迁移
• 关于运行期的风险是固有的，伴随着诸多未测试的不清晰和主要的情节
• 在运行期系统上的数据和开发及稳定期间的数据不相同
• 在开发者机器上无法运行构建[builds]
• 应用的行为在开发环境、稳定性环境、产品环境不一致

解决：