J2EE项目危机2

　　项目阶段:设计

　　所涉及的项目阶段:开发

　　所影响的系统性能:可维护性，可扩展性，可执行性

　　症状:

　　大型且笨拙的JSPs
　　当商业逻辑改变时，你发现你需要编辑JSP文件
　　显示需求的改变迫使你编辑和重新部署EJBs和后台组件

　　解决:

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

　　注:

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

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

　　项目阶段:开发

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

　　所影响的系统特性:正常的心智(Your sanity)

　　征兆:

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

　　解决:

　　危机4的解决办法是将你产品的环境如实地复制到你的开发环境。在你打算放置产品的确切的环境上开发??不要在Red Hat Linux 上用JDK1.3开发，然后却布置到 JDK 1.2.2 和 Solaris 7 上。进一步，不要在这个应用服务器上开发却部署到另外的服务器上。同时，得到你产品的数据库的数据的大致印象，并且在其上进行测试，不要依赖人工创造的数据。如果产品数据是敏感的[sensitive],减少其敏感性，装载它。意想不到的产品数据将打破:

　　数据有效性规则
　　已经测试的系统行为
　　系统组件间的契约(尤其是EJB-EJB和EJB-DB之间)
　　最坏的情况，每一项均会导致异常，空指针和你以前从未见过的行为。

　　注:

　　开发者经常到稳定阶段才想起安全性(“耶!屏幕正常，让我们把用户加为确认的员工”)。花费同样的时间来避免这种圈套实现安全性，就像你分离商业逻辑时候做的那样。
　　实施是一个复杂的过程，充满政治问题和技术问题。你将会碰到你不期望的问题;这就是实施的全部。开发环境和稳定性环境给你在实施前犯错误和找到问题的空间，利用这点，将减少应用实施过程中你的痛苦和风险。
　　你经历的项目越多，你就越容易知道什么能运行什么不能，为你和你的同伴保留一本项目记事本。在实施过程，你的目标应该是同样的错误不犯两次。