??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲伊人成无码综合网,亚洲国产精品久久久久网站 ,久久久久亚洲av无码专区导航http://www.tkk7.com/bluelily22/category/4090.htmlzh-cnFri, 02 Mar 2007 02:52:54 GMTFri, 02 Mar 2007 02:52:54 GMT60J2EE目10大风?/title><link>http://www.tkk7.com/bluelily22/archive/2005/10/24/16530.html</link><dc:creator>丁丁</dc:creator><author>丁丁</author><pubDate>Mon, 24 Oct 2005 01:25:00 GMT</pubDate><guid>http://www.tkk7.com/bluelily22/archive/2005/10/24/16530.html</guid><wfw:comment>http://www.tkk7.com/bluelily22/comments/16530.html</wfw:comment><comments>http://www.tkk7.com/bluelily22/archive/2005/10/24/16530.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.tkk7.com/bluelily22/comments/commentRss/16530.html</wfw:commentRss><trackback:ping>http://www.tkk7.com/bluelily22/services/trackbacks/16530.html</trackback:ping><description><![CDATA[<DIV align=center><B>J2EE</B><B>目10大风?/B><B></B></DIV> <DIV align=center><B>避免本文所列之</B><B>10</B><B>?/B><B>J2EE</B><B>风险Q确保企业</B><B>Java</B><B>目成功</B><B></B></DIV> <DIV align=left>作者：Humphrey Sheil</DIV> <DIV align=left>译QBlueski<BR><BR>说明Q?BR>本文已在51CMM|站《中国系l分析员》杂志第3期刊载?BR>原文?<A >http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html</A></DIV> <DIV align=left><B>摘要</B><BR>当你开始着手组l一个企业Java目的时候，如同开始同时轮回地扔好几个术球Q?业主关系处理、持l而O长的设计开发过E，以及保持健全与完整性，{等。每一个“小球”都会带来其固有的风险，有些显而易见，有些则不易发现。尽如此，所有这些风险都是完全可以避免的。本文作者Humphrey Sheil分析了威胁到企业UJava目成功?0大风险， q一一列出了风险规避的{略Ҏ?</DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left>在过去这D|期里Q我担Qq程序员、高U设计师以及架构设计师等工作Q见识过很优U的企业Java目Q也见识q不好的Q甚臛_"丑陋"的项目。有时候我会自己问自己Qؓ什么一个项目可以取得成功，而另一个却走向p|Q很隑֮义出某种规则或标准来表明各个不同的项目应该如何成功，J2EE目也ƈ不例外。但与此相反的是Q我们可以从各个角度和层ơ上去考察目p|的原因，如果很好地避开了这些风险，目可以取得成功。在本文中，我将提出排名?0位的企业UJava目风险Q供读者参考?</DIV> <DIV align=left>在各U各L风险中，有些风险只是延缓了项目的q度Q有些带来了一些不必要的工作，而另一些则会把成功的可能性彻底地消除。不q，如果预先有了_的准备和清醒的认识，那么q没有不可避免的事情。这好比如果你是一名旅行者，你清楚地知道前面的道路在什么方向，做了充分的准备，又有一位清楚知道哪里有危险的向|q样׃比较利地到达自q目的地?</DIV> <DIV align=left>本文采用了以下结构来描述风险Q　 </DIV> <DIV align=left>·         <B>风险名称Q风险的标题Q用粗体）</B> </DIV> <DIV align=left>·         <B>目阶段Q?/B>在哪个项目阶D会发生风险情况 </DIV> <DIV align=left>·         <B>影响阶段Q?/B>会媄响到以后的哪些阶D?</DIV> <DIV align=left>·         <B>症状Q?/B>    风险产生时的症状 </DIV> <DIV align=left>·         <B>规避ҎQ?/B>如何规避风险或者把其对目的媄响降低到最程?</DIV> <DIV align=left>·         <B>备注Q?/B>    风险相关的补充说明和提示 </DIV> <DIV align=left>通过对企业Java目的仔l考察Q本文将J2EE目q程分解Z下几个阶D： </DIV> <DIV align=left>·         <B>提供商选择</B><B>:</B> 在开始你的J2EE目之前Q要选择最合适的提供商，从应用服务器到开发工L合，一直至工作期间享用的咖啡的厂商?)　 </DIV> <DIV align=left>·         <B>设计Q?/B> 在遵照一pd严格的规范和软g工程Ҏ的前提下Q可以开始进行够充分的设计Q然后再很自然地q入开发阶Dc在开发之前，要周全地考虑好正在做什么，以及如何往下做的问题。另外，我用了一些设计模板来信在进入开发之前，已经惛_了所有的问题和可能的解决Ҏ。但是，我有时也在该阶段做一些编码，有时候这样做可以回答一些问题，有效地判断出性能上和模块划分上的问题。　 </DIV> <DIV align=left>·         <B>开?/B><B>:</B> 也就是程序开发阶D，选择一些好的开发工Pq行_良的设计等{，在这个阶D将昄其优性，q且可以l开发带来很大的帮助。　 </DIV> <DIV align=left>·         <B>E_?/B><B>/</B><B>负蝲试Q?/B>在该阶段Q系l架构师和项目经理应该冻l住产品Ҏ，q把焦点攑֜质量以及产品参数Q允许的q发用户数量Q故障恢复情况，{等Q上。质量和性能在该阶段应得到够的重视。当Ӟ最好应该避免在前阶D写Z良的q行~慢的代码而到本阶D|作很多的修改?</DIV> <DIV align=left>·         <B>成熟期：</B>q不是一个真正的目阶段Q而是一个固定的准备阶段。过L伏的错误Q来自于p糕的设计和开发、错误的厂商选择Q可能出现ƈ影响你的pȝ?</DIV> <DIV align=left></DIV> <DIV align=left>? ׃各种原因而受到媄响的目阶段 </DIV> <DIV align=left>　 </DIV> <DIV align=left>OKQ以下让我们q入 <B>top 10 </B>目风险Q?</DIV> <DIV align=left>　 </DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>1</B><B>:</B><B>没有真正理解</B><B> Java, EJB, </B><B>?/B><B>J2EE<BR></B><BR>q个问题可以分解?个部分，以便于分析?</DIV> <DIV align=left><B>描述</B><B>:</B> 没有真正理解Java </DIV> <DIV align=left><B>目阶段</B><B>:</B><B>开?/B> </DIV> <DIV align=left><B>影响阶段Q?/B>设计、稳定性测试、成熟期 </DIV> <DIV align=left><B>对系l性能的媄响：</B>可维护性、可扩展性、性能 </DIV> <DIV align=left><B>症状Q?/B> </DIV> <DIV align=left>·         重复开发了JDK核心API中的功能或类 </DIV> <DIV align=left>·         不懂得以下列表中的某些项Q这只是一些主题或者实际例子而已Q： </DIV> <DIV align=left>o        垃圾攉?(train, generational, incremental, synchronous, asynchronous) </DIV> <DIV align=left>o        对象在何时能被进行垃圾收?-- dangling references </DIV> <DIV align=left>o        使用的承机制及其权?</DIV> <DIV align=left>o        over-riding和over-loadingҎ </DIV> <DIV align=left>o        Z么java.lang.String (在这里用你所中意的类代替) 提供的性能不好 </DIV> <DIV align=left>o        Java中的pass-by参考语义和EJB中pass-by值的语义的比?</DIV> <DIV align=left>o        使用 == 或者用equals() Ҏ for nonprimitives </DIV> <DIV align=left>o        在不同^CJavaU程的运行顺序方?例如是否是抢先方式的) </DIV> <DIV align=left>o        新线E和本地U程的比?</DIV> <DIV align=left>o        Hotspot技?以及Z么旧的性能调整技术降低了Hotspot 的优化效? </DIV> <DIV align=left>o        JITQ以及什么时候好的JIT变得不好(未安装的JAVA~译器，以及你的代码q行得刚够良? </DIV> <DIV align=left>o        API搜集 </DIV> <DIV align=left>o        RMI </DIV> <DIV align=left><B>规避ҎQ?/B><BR>你需要不断改qJava斚w的知识，其是深入了解Java的优势和不之处。Java的存在h值已l远不止是一U语aQ理解^?JDK及工L)也是同样重要的。具体地_你应该是l过认证的JavaE序员，如果你不是的话，也许你有时会有那么多不知道的内容而感到惊讶。另外，你可以加入Java的邮件列表。以前我曑֊盟过的每一个公叔R加入了这L邮g列表Q从同行中学到技术，q将是你最好的资源?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>如果你或者你的团队中的成员不真正了解~程语言和^収ͼ怎么q能保持成功的希望呢Q强q的JavaE序员之于EJB和J2EEQ就象是鸭子之于水一栗与此相反，比较q、没有经验的E序员只能开发出质量低劣的J2EE应用E序?</DIV> <DIV align=left><B>描述</B><B>: </B><B>没有真正理解</B><B>EJB</B> </DIV> <DIV align=left><B>目阶段</B><B>:</B><BR>设计 </DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>开发、稳定化 </DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>l护 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         EJB在第一ơ被调用后没有再被用到(其是stateless session bean) </DIV> <DIV align=left>·         没有重复利用价值的EJB </DIV> <DIV align=left>·         不理解开发者要做什么，容器提供什?</DIV> <DIV align=left>·         EJB没有依照规范定义(fireU程, 加蝲了本地库Q试图执行I/OQ等{? </DIV> <DIV align=left><B>解决Ҏ</B><B>:</B><BR>要改q关于EJB斚w的知识，可以找一个周末来阅读EJB规范 (1.1版有314?Q然后阅?.0规范(524?)Q这样可以了解到1.1没有定义到的而在2.0规范中补充的内容。EJB开发者从18.1?8.2章节开始阅L比较合适的?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>不要从提供商的角度去看EJBQ要切地知道规范所支持的标准EJB模型和基于这些模型的Ҏ应用之间的区别。这也会有助于你q移到别的提供商的时候所用?</DIV> <DIV align=left><B>描述</B><B>:</B> 没有真正理解J2EE </DIV> <DIV align=left><B>目阶段</B><B>:</B><BR>设计 </DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>开?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>l护、扩展性、性能 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         "Everything is an EJB"的设计方?</DIV> <DIV align=left>·         用手工事务管理取代了容器-提供的机?</DIV> <DIV align=left>·         自定义方式的安全处理 -- J2EEq_在企业计算中，从表C逻辑到后台处理，已具有最完整的集成安全架构；但很用到其全部功能?</DIV> <DIV align=left><B>解决Ҏ</B><B>:</B><BR>学习J2EE的关键组Ӟq且了解它们的优~点Q依ơ用它们替代每一个服务；“知识就是力量”在q里是行之有效的?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>只有知识能够弥补q些问题。好的Java开发者会成ؓ好的EJB开发者，此后也应逐渐成ؓJ2EE得道高手。Java和J2EE知识掌握得越多，设计和开发工作就会越。在设计阶段一切都会有条不紊?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>2</B><B>: </B><B>q度设计</B><B>(Over-engineering) (</B><B>采用</B><B> EJB</B><B>或者不采用</B><B>EJB) </B><BR><B>目阶段Q?/B><BR>设计 </DIV> <DIV align=left><B>影响的项目阶D?/B><B>:</B><BR>开?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>l护、扩展性、性能 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         q于庞大的EJB </DIV> <DIV align=left>·         开发者无法解释EJB做什么，以及光的联p?</DIV> <DIV align=left>·         无法重复使用的EJB、组件或者服?</DIV> <DIV align=left>·         EJB启动了新的事务，而该事务本该׃个已存在的EJB启动 </DIV> <DIV align=left>·         Z安全Q把数据分离U别定得太高 </DIV> <DIV align=left><B>解决Ҏ</B><B>:</B><BR>q度工程化的解决之道直接来自于极限编E?(XP)ҎQ用最的设计和编E来满需求，除此之外别无它干。除非你需要明知道今后可能的需求，如将来的负蝲要求Q或者系l在最高负载下的表玎ͼ否则大可不必为系l将来的情况做太多考虑或猜。另外，J2EEq_已经定义了可伸羃性及出错恢复{特性，可以让服务器pȝZq行处理?BR>在最的pȝ中，只包含一个个组Ӟq些lg只做一件事Q只要把q些要求做到的进行实玎ͼpȝE_性就已经得到了提高，而且Q你的系l的可维护性会变得很强Q在未来要增加功能以满新的需求也变得容易?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>除了上面所列方案之外，可以推行设计模式 -- 它们可以显著地改q你的系l设计。EJB模型本n也广泛用了设计模式。例如，每个EJB所带的Home 接口是Finder和Factory模式的实例。EJB的remote接口扮演了一U实际bean实现的代理，q且对于提供容器的能力也是至关重要的Q这些容器截取调用信号ƈ提供诸如透明QtransparentQ负载均衡的服务。忽视设计模式也是危险的一部分?</DIV> <DIV align=left>我常提到要反对的另外一U危险是Q仅仅是Z使用EJB而用EJB。在你的应用中的某一部分可能q不需要EJBQ甚至你的整个应用都不需要。这是过度工E化所走的极端Q而且我确实也目睹了一些良好的servlet和JavaBean应用被重构ؓEJBQ而这样做q没有很好的技术上的理由?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>3</B><B>: </B><B>没有业务规则和逻辑表现形式相分?/B><BR><B>目阶段Q?/B><BR>设计 </DIV> <DIV align=left><B>影响的项目阶D：</B><BR>开?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>l护、扩展性、性能 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         q于庞大、没有边际的JSPE序 </DIV> <DIV align=left>·         在业务逻辑改变的时候必M改JSP </DIV> <DIV align=left>·         在要求改变界面显C的时候需要修改ƈ重新配置EJB和其它后台组?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>J2EEq_使你有机会将表示逻辑和导航控制相分离Q进而与业务规则相分R这被称为模?l构?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>可以使用h一致性的设计来进行用L面框架的q接?例如可以使用taglib)Q这帮助你避免逻辑分离的问题。有许多现成的好的方法可供选择。对每一个分别进行评伎ͼ然后采用最合适的框架?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>4</B><B>: </B><B>没有在开发环境中q行适当的配|?/B><BR><B>目阶段Q?/B><BR>开?</DIV> <DIV align=left><B>影响的项目阶D?/B><B>:</B><BR>E_化、ƈ发、成熟期 </DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>你的权衡 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         l过多日或数周的旉才能q渡到成熟系l?</DIV> <DIV align=left>·         风险存在与过渡期Q带有很多不定性，有些主要的功能场景没有被试?</DIV> <DIV align=left>·         实际pȝ中的数据和开发、测试中的数据不?</DIV> <DIV align=left>·         无法在开发者机器上q行l徏 </DIV> <DIV align=left>·         应用行ؓ在开发、稳定化及品环境中各不相同 </DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>解决之道是忠实地在开发环境中配置实际的环境，让开发所用环境接q于要实施品的环境。如果未来环境是JDK 1.2.2及Solaris 7Q那么不要在JDK 1.3及Red Hat Linux上进行开发。对于所用的应用服务器也是如此。同P要快速地看一下品数据库中的数据Qƈ这L数据用于试。不要依赖于人工创徏的数据。如果品数据很敏感Q则要之变得不敏感Q然后把它配|v来。开发中未能预期到的产品数据对以下q程产生破坏Q?</DIV> <DIV align=left>·         数据验规?</DIV> <DIV align=left>·         pȝ试行ؓ </DIV> <DIV align=left>·         pȝlg构徏(特别地包括：EJB-EJB以及EJB-数据? </DIV> <DIV align=left>最为糟p的是，q样q可能生异常、空指针Q以及你从没见过的问题?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>开发h员常把安全性问题放到稳定化阶段才开始解冟뀂要防止q样的陷׃生，你也可以p同样多的旉在业务逻辑中改q安全性?</DIV> <DIV align=left>成熟期是一个复杂的q程Q其中充满了技术性问题和非技术性问题。你可能会陷于想不到的一大堆问题中，q就是成熟化所意味的一切。开发及E_化环境过Eؓ你提供了刉更多这L问题Q以及发现这L问题的地方，不断dQ就可以大大减少风险?</DIV> <DIV align=left>你做的工E越多，你就能了解什么是可行的，什么是不可行的。你可以对工E问题进行记录，以避免同L错误重复发生?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>5</B><B>: </B><B>选择了错误的提供?/B><BR><B>目阶段Q?/B><BR>提供商选择 </DIV> <DIV align=left><B>影响阶段Q?/B><BR>设计、开发、稳定化/负蝲试Q成熟化 </DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>可׾~性、性能、可l护性及E_?</DIV> <DIV align=left><B>症状</B><B>:</B></DIV> <DIV align=left>·         开发h员要使用更多的时间来处理工具斚w的问题，而不是很有成效地使用q些工具 </DIV> <DIV align=left>·         Z应付已知的和未知的问题，而不得不q行显著的系l重新设?</DIV> <DIV align=left>·         在不同的工具之间很难q行集成Q应用服务器与IDE工具QIDE工具与调试器Q源码控制与合成工具Q等{） </DIV> <DIV align=left>·         对于IDE工具和调试器{，开发h员往往排斥它们Q而推崇自己所喜欢的工?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>Z避免风险5Q你需要一个很好的提供商选择q程Q风?0的规避也适用于此?</DIV> <DIV align=left>要真正衡量一UIDE工具是否最合适的Ҏ是真正地q行使用。而唯一来评CUJ2EE应用的方法是建立一U概念试验来q行证明Q在试验中要包含你的应用框架。事实上Q你也不希望在花费了3个月旉q行了培训和开发后Q在使用时又发现一些bug?</DIV> <DIV align=left>假设在开发到一半的时候，H然发现你的工具集有问题Q那么你早应该知道，有些工具实比另一些更重要。如果你所选的应用服务器不能充分满你的需要，你只好修改原先的讑֮。如果IDE不好Q则需要设|最低限度的代码标准Qƈ让开发h员Q意选择他们认ؓ最为有效的工具?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>要真正了解到哪一个供应商对一特D的d来说最合适，其实q不是一件一ơ性决定的事情。你需要不断地跟踪与评估这个市场。例如，在过ȝ一q里我用q?U不同的IDE工具Q这取决于我使用了什么样的应用服务器、^収ͼ是否使用EJB{?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>6</B><B>: </B><B>不了解你的提供商</B><BR><B>目阶段Q?/B><BR>提供商选择 </DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>提供商选择阶段后面的所有阶D：设计、开发、稳定化/负蝲试、成熟化 </DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>可维护性、可伸羃性、性能 </DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         开发所用周期超q了最坏预的周期1/3以上 </DIV> <DIV align=left>·         提供商已l提供了某项功能Q但开发者在不知道的情况下重新进行了该项功能的开?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>Z规避q样的风险，你可以尽可能地订阅提供商的网上资源，例如邮g列表、新ȝ、版本信息（其是其中的bug修复补丁的说明等Q，你能从中得到无法估量之多的收莗?</DIV> <DIV align=left>一旦你已经选定了提供商Q那么立卛_要投资进行培训，q且可能赶在项目启动以前。然后，逐渐在团队中建立起对此提供商的认识及信Q。试着建立几个EJBq|一下，再用你的表示层技?(Swing GUI, JSP{?来调用它们。如果你既要搭徏开发环境，又要同时在实现项目目标，׃产生一些不必要的冲H。实际上Q我也见到过一直没有进行构E的情况Q“我们没有时间。”因此，q些工作必须提早q行。有些h会说Q“我们的计划中没有ؓ我们提供q些旉。”我的回{是Q“你的计划中q没有不l你旉使你不这么做啊。?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>在J2EE世界里，各提供商产品的技术兼Ҏ究竟如何？让我们看一下IBM和BEA的具体分析吧。两者都分别在各自的应用服务器中支持EJB 1.1。那么，实际上BEA WebLogic 5.1和IBM WebSphere 3.5I竟有多相g处呢? </DIV> <DIV align=left>1.        BEA WebLogic和IBM WebSphere的系l配|和理方式几乎完全不同?</DIV> <DIV align=left>2.        IBM在WebSphere中采用了全面的GUI环境Q而与之相对的是，BEA 在WebLogic中提供一整套命o行?</DIV> <DIV align=left>3.        IBM WebSphere使用IIOP来和CORBA异常q行通讯Q这些异常对E序员来说是可见的；WebLogicҎ没有CORBA构造，而缺省用t3协议?</DIV> <DIV align=left>4.        WebSphere和Visual Age衔接紧密Q而WebLogic是IDE无关的，实际上，你几乎可以用Q何的开发工兗?</DIV> <DIV align=left>由此可见Q差异还是相当多。如果你是一U应用服务器的专Ӟq不意味着你就是所有应用服务器的专家。这U区别体现在IDEQdebuggerQbuild工具Q配|管理等{方面。具备某提供商的某项Ҏ工具的用经验，可以在评估该提供商的竞争Ҏ产品时具有一些便利。但是，不要奢望在不同品之间进行无~的转移或衔接。因此，你不得不p_多的旉在熟l掌握这些工具上?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>7</B><B>: </B><B>设计中没有充分考虑到可伸羃性和产品性能</B><BR><B>目阶段Q?/B><BR>设计 </DIV> <DIV align=left><B>受媄响的目阶段</B><B>:</B><BR>开发、负载测试及成熟?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>可׾~性、性能、可l护?</DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         无法忍受的速度~慢 </DIV> <DIV align=left>·         pȝl服务器端增加的沉重负担Q而无法利用到一些聚技术?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>把精力集中于性能和可伸羃性方面的需求，明确开发中要达到的性能指标。如果你需要每U?0个事务，而你的EJB设计只能提供40个，那么你就需要考虑替代ҎQ诸如存储过E，批处理，或者重新考虑OLTP的设计?</DIV> <DIV align=left>可能让你的提供商加入进来，他们应该非常清楚其品的强项和弱处在哪里Q然后给你提供最直接的帮助?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>本风险与风险2 (over-engineering)g有些冲突。实际上Q两者相互媄响?我对风险2l出的解x案是Q只在绝对必要的情况下才q行构徏。而对与性能和可伸羃性，你要预先划分好什么是必须要做的?</DIV> <DIV align=left>如果你实现就识别出系l需要非常强的可伸羃性，q把它作Z个比较关键的需求，那么你首先需要选择一个带有很强的支持及事务型缓存的应用服务器。另外，你应把业务对象设计ؓEJBQ从而可以充分利用服务器架构的优ѝ?XP也没有问题，你仍然是只做l对必要的工作?</DIV> <DIV align=left>我把q样的观点看作是一U检查和q的方法。我们只需要最单可能性的pȝQ该pȝ只提供客h需要的功能与行为即可?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>8</B><B>: </B><B>陈旧的开发过E?/B><BR><B>目阶段Q?/B><BR>开?</DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>E_化，成熟?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>可维护性、代码质?</DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         目计划看上M乎类g瀑布模型: “首先草构设计，然后在一个很长的周期里进行开发。?</DIV> <DIV align=left>·         ׃不存在构建（buildQ过E，每次构徏都象是噩?</DIV> <DIV align=left>·         构徏的日期等于损失开发的日期Q因Z么也没有做成 </DIV> <DIV align=left>·         在集成以前组件没有分别被充分地测试过Q而集成测试意味着?个不E_的组件放在一P然后查看堆栈里的跟踪l果?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>好的软gҎ学将提高你的软g生命期。此前我已经提到XPҎQ你可以在网上找到很多这斚w的资料?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>JUnit可以用来q行单元试QAnt工具可以q行~译与构建，q?U工具都对XPҎ有很好的支持?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>9</B><B>:</B><B> </B><B>没有好的架构方式</B><BR><B>目阶段Q?/B><BR>开?</DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>开发、稳定化、成熟期 </DIV> <DIV align=left><B>对系l的影响Q?/B><BR>可维护性、可伸羃性、代码质?</DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         在代码中使用了很多次的核心库中发现Bug?</DIV> <DIV align=left>·         没有建立日志标准 -- 于是pȝ的输出很难读取或者解析?</DIV> <DIV align=left>·         不良的不一致的异常处理。在有些站点中我们甚臛_以看刎ͼ出错信息直接暴露l了最l用P例如在用户在他的购物车核帐时发送一条SQLException堆栈跟踪信息Q用h着会怎么做？打电话给数据库管理员要求对primary keyU束q行修补吗？ </DIV> <DIV align=left>以下d已经被开发者以各种方式处理了无数次了，q些都有必要攑֜M构架设计的第一批目标中。　 </DIV> <DIV align=left>·         日志 </DIV> <DIV align=left>·         异常处理 </DIV> <DIV align=left>·         与资源的q接(数据库，名字服务{? </DIV> <DIV align=left>·         构徏JSP?</DIV> <DIV align=left>·         数据合法性检?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>我是一个轻Ҏ学的信徒和实践者。我?I>JavaWorld</I> 上的W一文?-- "<A >Frameworks Save the Day</A>" -- 是研讨在企业Java环境中的架构。即使你已经开始开发了Q此时考虑一下架构仍然是值得的。可能你不得不忍受一下重构带来的异常处理和日志处理，但从长远来看q是值得的，q样即省旉又省钱?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>让我们想一下在构架中基于组件开发的可重用性的不同{。第一U别是plumbingQ具?.9以上的可重用比例Q也是_?0%的项目可以对它重复利用?服务定义得越详细Q重用比例就低。换句话_我需要构Z个会计服务，但要提供q些资源与用法的理Q以便于其它50%目中可以对它们q行重复利用。但是对那些目来说Q能得到q些资源Q那真是太好了！</DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>风险</B><B>10</B><B>: </B><B>目计划和设计基于市场效应，而脱M技术现?/B> </DIV> <DIV align=left><B>备注</B><B>:</B> 不断有新人加入到Java/EJB的开发领域中来，不理解Java的hC般比惌中还要多?</DIV> <DIV align=left><B>目阶段Q?/B><BR>所有阶D都会受到媄响，包括提供商的选择 </DIV> <DIV align=left><B>影响阶段</B><B>:</B><BR>所有阶D都会受到媄?</DIV> <DIV align=left><B>对系l的影响</B><B>:</B><BR>可维护性、可扩展性、设计质量、代码质?</DIV> <DIV align=left><B>症状</B><B>:</B> </DIV> <DIV align=left>·         ȝ地进行技术决{，认ؓEJB只是Z便携式处理的方便 </DIV> <DIV align=left>·         选择提供商的时候没有随卌行品的试用 </DIV> <DIV align=left>·         在项目的生命周期内还需要更换工?</DIV> <DIV align=left><B>规避Ҏ</B><B>:</B><BR>不要L怿目外部的Q何h的看法，q些人可能已l有一些既得利益，不要怿提供商的说法Q除非你早已l了解）Q也不要怿白皮书。如果你要取得来自真实世界的关于应用服务器的Q可以在|上取得。你q可以下载这些工兯行评伎ͼ用它们做一些原型，q运行一下其中的样例?好的提供商都有这L样例)?</DIV> <DIV align=left>ȝ来说Qؓ你的目选择最好的提供商及工具需要时_而你可能没有太多的时间。你可以把选择范围限制?-4个对象，然后用一周时间进行比较和验。最后从中选出比较满意的工具和产品?</DIV> <DIV align=left><B>备注</B><B>:</B><BR>如果你缺J2EEl验Q则可能会在目前期׃生问题。在前期所定的决{会影响整个q程Qƈq而媄响项目的成功。好的J2EE咨询专家能够帮助你选择好的提供商，qؓ设计和开发刻划出一个好的构形?/DIV> <DIV align=center> <HR align=center width="100%" SIZE=2> </DIV> <DIV align=left><B>仅仅只有q?/B><B>10</B><B>w险吗Q?/B><B><BR></B><BR>10只是一个特定的数字Q显Ӟq有更多更多的风险会存在。只是我可以保证的是Q如果你克服了所列的各项风险Q那么你的项目会有出色的表现q已打好了成功的基础?</DIV> <DIV align=left>q有一w要注意，?I>没有M东西可以代替l验和计划?/I>如果你没有经验，那么一定要惛_法取得ƈU篏。千万不要一边做目一边进行培训。在开发之前要预先做好充分的准备，最好是在设计以前就q行准备。可以让你的团队接受Java/J2EEN的指|q确保这L指导能够传递到整个其他的团队成员?</DIV> <DIV align=left>最后，q有必要提到以下几点Q?</DIV> <DIV align=left>·         软g工程的外界媄?</DIV> <DIV align=left>·         什么时候进行单元测试，什么时候进行集成测试？ </DIV> <DIV align=left>·         设计模式 </DIV> <DIV align=left>·         异常处理 </DIV> <DIV align=left><B>l论</B><BR>ȝ说来Q以?0大风险是你在企业UJava目开发过E中面对的主要困难。我也相信在你的旅程中一定还有更多的陷阱Q但我比较确信的是我所提到的风险已l涵盖了主要的问题。最后让我们按照优先U重新列举一?0大风险：　 </DIV> <DIV align=left>1.        没有真正理解Java, 没有真正理解EJB, 没有真正理解J2EE </DIV> <DIV align=left>2.        q度设计(Over-engineering)  </DIV> <DIV align=left>3.        没有业务规则和逻辑表现形式相分?</DIV> <DIV align=left>4.        没有在开发环境中q行适当的配|?</DIV> <DIV align=left>5.        选择了错误的提供?</DIV> <DIV align=left>6.        不了解你的提供商 </DIV> <DIV align=left>7.        设计中没有充分考虑到可伸羃性和产品性能 </DIV> <DIV align=left>8.        陈旧的开发过E?</DIV> <DIV align=left>9.        没有好的架构方式 </DIV> <DIV align=left>10.     目计划和设计基于市场效应，而脱M技术现?</DIV> <DIV align=left>最后，让我你好运Q　<BR><BR> <DIV align=left>译后讎ͼ</DIV> <DIV align=left>我基本上没有做过J2EE目Q但仍有_勇气译q样的文章。在国内软g公司里，极端情况下也许到处都是风险，q样也就无所谓风险了。对于选择J2EE技术\U，自然会有J2EEҎ的风险，因此本文中的风险往往也是特别针对J2EE目的。另外，对于J2EE目Q我们不应该忽视的一ҎQ其技术上的风险会更大一些?/DIV> <DIV> </DIV></DIV><img src ="http://www.tkk7.com/bluelily22/aggbug/16530.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.tkk7.com/bluelily22/" target="_blank">丁丁</a> 2005-10-24 09:25 <a href="http://www.tkk7.com/bluelily22/archive/2005/10/24/16530.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <p>лǵվܻԴȤ</p> <a href="http://www.tkk7.com/" title="亚洲av成人片在线观看">亚洲av成人片在线观看</a> <div class="friend-links"> </div> </div> </footer> վ֩ģ壺 <a href="http://kouchoubao.com" target="_blank">ɫһ</a>| <a href="http://qsqse1.com" target="_blank">ޱһ</a>| <a href="http://b2bautoparts.com" target="_blank">˳ëƬ߲</a>| <a href="http://51wdn.com" target="_blank">99reƵ</a>| <a href="http://yanyingqiang.com" target="_blank">ŷպ</a>| <a href="http://bbscqz.com" target="_blank">999|</a>| <a href="http://222941.com" target="_blank">޾Ļ</a>| <a href="http://fense1.com" target="_blank">ֳִִֺƵ</a>| <a href="http://c9133.com" target="_blank">޻ɫվ</a>| <a href="http://www96pg.com" target="_blank">ŷ</a>| <a href="http://k67m.com" target="_blank">þþþ޹AV鶹</a>| <a href="http://lfhuanxin.com" target="_blank">Ƭ91Ʒѹۿͬ </a>| <a href="http://syeyo.com" target="_blank">avr </a>| <a href="http://gxshenquan.com" target="_blank">Դ</a>| <a href="http://hzkjjy.com" target="_blank">aƵƷѹۿ</a>| <a href="http://hssw1688.com" target="_blank">Avһ</a>| <a href="http://x3013.com" target="_blank">ƬƵ</a>| <a href="http://df8848.com" target="_blank">պAVһl</a>| <a href="http://qsqse1.com" target="_blank">˳ۺ7777</a>| <a href="http://aqdav22.com" target="_blank">ѹۿ91Ƶ</a>| <a href="http://hbgksy.com" target="_blank">޴ɫAvר</a>| <a href="http://zjtuhui.com" target="_blank">h⶯߹ۿ</a>| <a href="http://fsdyzs.com" target="_blank">Ʒһѹۿ </a>| <a href="http://assbjg.com" target="_blank">vavavaþ</a>| <a href="http://xuanzhicity.com" target="_blank">51ƵѹۿƵ</a>| <a href="http://wwwks2424.com" target="_blank">þþþseɫ͵͵޾Ʒav</a>| <a href="http://yw835.com" target="_blank">ŮڵƵ</a>| <a href="http://micehunan.com" target="_blank">йƷһëƬѲ</a>| <a href="http://popodino.com" target="_blank">97츾͵ͼƬ</a>| <a href="http://xuexilo.com" target="_blank">߹ۿѲ</a>| <a href="http://kfdingrui.com" target="_blank">һëƬ߲Ƶѹۿ </a>| <a href="http://mcjc1.com" target="_blank">ѵӰվ</a>| <a href="http://boyipark.com" target="_blank">ҹavƵ</a>| <a href="http://hmjx-tape.com" target="_blank">avƬ쿴</a>| <a href="http://6atb.com" target="_blank">˳ѵӰ</a>| <a href="http://douhuowang.com" target="_blank">MM131޹Ůþ</a>| <a href="http://hkcp168.com" target="_blank">2019ĻѴȫ5</a>| <a href="http://assbjg.com" target="_blank">޹AVվ</a>| <a href="http://15831883389.com" target="_blank">þAVҹƷһ</a>| <a href="http://ruidamo.com" target="_blank">Ƶۿڵ</a>| <a href="http://selaohu.com" target="_blank">ˮƵ߹ۿѲŸ</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>