J2EE项目危机4

　　项目阶段:开发

　　所涉及的项目阶段:开发过程，稳定性能，生存期

　　受影响的系统特性:可维护性，可扩展性和编码质量

　　征兆:

　　核心库中的Bug在代码里重复使用
　　没有设定日志标准,因此系统的输出不可读或不能转换成scripts
　　差的或不协调的异常处理。在一些站点上我看到，终端用户在一些低级错误上被暴露，例如，当用户试图为购物车结帐的时候出现SQLException的堆栈追踪。用户接下来做什么呢?打电话给数据库管理员并强制报告这个错误吗?
　　下面的任务需要开发者在大量的情况下处理，并且，应该作为使用框架的首要任务:
　　记录日志
　　异常处理
　　获取相关资源的链接(数据库，名字服务等)
　　建立JSP页面
　　数据有效性验证

　　解决:

　　我对在重型应用中使用轻量级框架坚信不移。事实上，我在JavaWorld的第一篇文章"Frameworks Save the Day" 讨论过在企业开发环境中使用框架的问题。如果你现在已经在开发，马上采用框架仍然将获得重大收益。你将经历重新工作的痛苦，像日志及异常捕获，但就长远来看，你会节约大量时间和金钱。

　　注:

　　当你采用框架和面向组件编程时候，考虑不同级别的重用。在第一层，重塑(plumbing)，使用0.9或更高的重用因子(reuse factor),这意味着90%的工程将用到它。越是特殊的服务，其重用因子越低。是说，我可能建立一个帐号服务来管理资源使用，希望50%的工程用到它。但对于那些需要它的工程??那些搞开发的男孩将很高兴它在那里!

　　危机10:将工程计划和设计基于市场广告，而不是技术现实

　　注:

　　危机10并未出现在我的列表中，直到我认识到有许多的人而不仅仅是我一个存在对企业java的误解，尤其是那些新鲜的领域。

　　项目阶段:所有的项目阶段，尤其是供应商的选择更明显。

　　所影响的项目阶段:所有阶段

　　所影响的项目特性:可维护性，可扩展性，设计质量，代码质量

　　征兆:

　　技术方面的决策占很轻的分量，因为EJB被设计的轻便
　　供应商选择对于产品未经过是否轻便的试验
　　在项目生存期需要选择工具

　　解决:

　　不要相信在你项目之外的任何既得利益者。这是说:不要相信供应商(除非你已经了解他们了)，不要相信供应商提供的白纸。如果你想要一些真实的应用服务器的建议，查询以前的链接:Resources。进一步，下载你想评测的工具，挽起袖子，设计原型。通过提供的例子来运行(任何好的提供商都有例子)。
　　总之，选择正确的供应商和工具集需要花费时间，尽管你的时间可能并不充裕。将你的选择集中到3个-4个，然后每个都试一下。花费一周的时间来验证你的应用服务器，IDE，部署过程等等，直到用这些工具可以满足你的开发计划时。

　　注:

　　如果你对J2EE不熟悉，在项目开始阶段你将很受打击。一开始所做的决定将对整个项目的成功有巨大的影响。一个好的J2EE顾问可能要进行一个重大的供应商选择过程并很好地将你带入设计和开发状态。

　只有这10项危机?

　　10只是一个武断的数字，只是作为一个断点??还有数不清的其他危机存在。确实，我自己仍知道比这多一倍的危机。即使这样，如果你防备了这里所列出的，我保证你的工程可以完美和成功。

　　如果只从这篇文章中吸取一样东西，我的建议是:没有什么可以替代经验和计划的[There is no substitute for experience and planning]。如果你没有经验，那么你去试，然后得到它。在工程过程中，不要将赌注押到工程开始时候你以及你团队的培训上。开发前就进行一些编码，更好的是在设计之前就做编码。把你的Java和J2EE团队交给经验丰富的人来带以确保整个工程的方向和你团队中那些经验少的成员可以沿着这条路成长起来。

　　最后，我写的越多，我越清楚我想说的:

　　软件工程的社会层面
　　单元测试和整体测试
　　设计模式
　　异常捕获

　　结论

　　好吧，就这么多。上面的互相影响的10项危机，是你在企业Java开发中将要面对或已经面对的大多数(如果不是全部的话)问题的原因。自然的，在你的旅途中还会遇到许多问题，但我相信，我已经揭示了最主要的原因。做个回顾，下面就是按重要程度划分的这10项危机:

　　没有理解Java,没有理解EJB,没有理解J2EE
　　过度设计(无论是否是对于EJB)
　　未分离表示逻辑和商业逻辑
　　未在你开发的地方部署
　　选择错误的(开发工具)提供商
　　不了解你的供应商
　　没有为可测量性或可执行性设计
　　陈旧的开发过程
　　使用框架失败
　　将工程计划和设计基于市场广告，而不是技术现实