??xml version="1.0" encoding="utf-8" standalone="yes"?> 摘要 在你着手企业JAVA 目开发时Q你需要像耍杂技掌控手中的球一h处理一些问题:与工具商之间的关p,漫长的工E——不论是设计q是开发,q是保持健壮性。每一w会带来固有的危险Q一些是明显的,然而另外一些却不是。但所有这些危机均可避免。本文作者分析了10危Z业JAVA目的最大的危险Qƈ大致指出了避免它们的办法。(4Q?00字——此处是指英文字敎ͼ
在我作ؓ开发者、高U开发者、架构师的经历中Q我遇到q好的、差的甚x丑陋的企业JAVA目。当我问自己Q是什么一个项目成功而另外的失败,我发现很隑־C个完的{案Q就好像很难?I>成功来定义所有的软g目。J2EE目也不例外。因此,目被分Z同别的成功或失败。在q篇文章里,我主要想为您——读者朋友——揭C媄响企业JAVA目的最大的10危险?/FONT> 一些危险只是简单的延迟目q度Q一些却是错误的征兆Q而还有一些ə目d没有成功的希望。尽如此,如果h良好的准备,征程开始前相关的知识和熟悉地Ş的向|所有的都可避免?/FONT> q篇文章l构单,我会按以下方式来揭示各种危机Q? 如上所注,我们在企业UJAVA目背景和它的各个重要阶D中查每一危险。这些项目阶D包括:
?/FONT>1阐释了这些项目阶D,以及对其有媄响的各种因素Q尤其是那些“突然的[knock-on]”媄响)
By Humphrey Sheil
作者:Humphrey Sheil
原文出处Qhttp://java.sun.com/developer/technicalArticles/J2EE/projectdangers/
译Qgooing 2005-01-18
http://blog.csdn.net/gooing/
感谢金山词霸和薛叉叉Q请指正!
Figure 1. Enterprise Java project phases
and their most likely reasons for failure.
Click on thumbnail to view full-size
image. (60 KB)
危机1Q没有理解Java,没有理解EJB,没有理解J2EE
好,现在我将其分解成3个小主题来进一步阐释?/FONT>
描述Q不理解Java
目阶段Q?/B>开发阶D?/P>
所牵连的项目阶D:设计Q稳定阶D,存在阶段
受媄响的pȝҎ:可维护性,可测量性(scalabilityQ?执行?/P>
征兆Q?/STRONG>
解决办法Q?/B>
你需要提高你的Java知识Q尤其是了解它的优势和弱炏VJava的存在已l远q超除了一门语a本nQ同样重要的是理解这q_QJDK and toolsQ?具体的,你应当具有做一名Java E序员的资格Q如果你q没有的话)——你对你有如此多不了解的东西感到吃惊。更q一步,它作ؓ你小l的一部分q向其他人推q,q种方式同样很有乐趣。更q一步,创徏一份邮件列表,专心于Java技术ƈ且保持下厅R(我曾工作q的公司都有q些列表Q大多数׃不更新而变的岌岌可危)向你的同伴学习——他们是你最好的资源?
注:
如果你或你团队中的其他成员不理解q门~程语言和这q_Q你又怎么能期待徏造一个成功的企业UJava应用呢?健壮的JavaE序员对于EJB和J2EE如果鸭子对于水一般。与之相对,差的没有l验的程序员徏造一个质量差的J2EE应用?
描述Q不理解EJB
目阶段Q设?
所牉|目阶段Q开发,E_性阶D?
受媄响的pȝҎ:可维护?
征兆Q?/STRONG>
解决Q?/B>
为提高你的EJB知识Q花一个周末来阅读EJB规范Q?.1规范?14)。然后阅?.0规范Q?24)来了解ؓ什?.1规范不再适用?.0规范能带l你什么。关注规范中那些能告诉你——应用开发者——什么是在EJB中合法的行ؓ的部分?8.1?8.2节是开始的好地斏V?
注:
不要从你的提供商Q指应用服务器或其他开发Y件的提供商——译者)的眼里看EJB世界。确保你了解W合规范的EJB模型和特D的实现之间的不同。这保证在需要时你可以将你的技术带l你的提供商Q或其他版本Q?
描述Q?/B>不理解J2EE
目阶段Q?/B>设计
所牉|目阶段Q开?
受媄响的pȝҎ:可维护性,可度量性(scalabilityQ,执行?
征兆Q?/B>
解决Q?/B>
学习J2EE关键lg以及每个lg所能带来的优势和劣ѝ依ơ涉及各Ҏ务,此处知识和能力一样重要?
注:
只有知识能解册些问题。好的Java 开发者造就好的EJB开发者——一步步地可以完地成ؓJ2EE领袖的h。你获得多的Java/J2EE知识Q你在设计和实现斚w的能力越?Things will start to slot into place for you at design time.(想了半天也不知道怎么译:-{ )
危机2Q过度设计(无论是否是对于EJBQ?/STRONG>
目阶段Q设?
所涉及的项目阶D:开?
受媄响的pȝҎ?/B>Q可l护性,可测量性(scalabilityQ,可执行?
征兆Q?/P>
解决Q?BR>解决q度设计的方法可以直接从XPQextreme programmingQ中扑ֈQ局部范围内Q设计和~码实现最的暴露的[bare minimum]部分来满需求,而不要做的过多。当你需要意识到来的需求,比如q_负蝲需求和在系l负载顶峰时候的行ؓQ不要试䏀第二次猜测”[second-guess]pȝ来需要成为的样子。另外,J2EEq_Z定义了特性如可测度性和服务器底层需要捕Ld错误?/P>
?/B>Q?
除了上面的解x式,使用设计模式——它们会显著的提高你的系l设计。EJB模型本nq泛C用设计模式。如Q每个EJB里的Home接口是一个寻找者和工厂模式的例子[Finder and Factory pattern].一个EJB的远E接口担当实际bean的实现的代理Q也是容器截取调用和提供服务如透明化负载均衡的能力关键。忽略设计模式的价值是危险的?
我不断强调的另一U危险是Qؓ使用EJB而用。你的应用的一些部分在不适合被当作EJB模型时候而被设计为EJB模型Q你的整个应用似乎用EJBs获得无限h倹{这是极度的q分设计Q我曄到完的servlet ?JavaBean 应用在ƈ没有好的技术方面的原因而用EJBsӞ变的׃八糟Q不得不重新设计?
危机3Q未分离表示逻辑和商业逻辑
目阶段Q?/B>设计
所涉及的项目阶D?/B>Q开?
所影响的系l性能Q可l护性,可扩展性,可执行?/P>
症状Q?/B>
解决Q?/B>
J2EEq_l你表C逻辑同导航和控制分离q最l与商业逻辑分离的机会,q被UCؓModel2 l构Q参?Resources Q。如果你已经掉进圈套Q一U比较呆板的做法或许有用。你应该臛_?那些大部分自我包含的片断保持“垂直瘦”[thin vertical slices](q是_我如何布局的一个片断要同如何更Ҏ的用户名和密码分开)。在你系l中使用q种方式来重新组l?
注:
在你的工E中使用一U连接UI框架Q如标签库)坚固的设计将帮助你避免逻辑分离问题Q不要ؓ你自己需要的GUI框架设计而烦|q会Z带来诸多执行斚w的好处。依ơ评估每一U框Ӟ然后选择最适合你的那种?
危机4 Q未在你开发的地方部v
目阶段Q?/B>开?
所影响的项目阶D:E_阶段Qƈ行阶D,存在阶段
所影响的系l特?/B>Q正常的心智QYour sanityQ?
征兆Q?/B>
解决Q?/B>
危机4的解军_法是你产品的环境如实地复制C的开发环境。在你打放|品的切的环境上开发——不要在Red Hat Linux 上用JDK1.3开发,然后却布|到 JDK 1.2.2 ?Solaris 7 上。进一步,不要在这个应用服务器上开发却部v到另外的服务器上。同Ӟ得到你品的数据库的数据的大致印象,q且在其上进行测试,不要依赖人工创造的数据。如果品数据是敏感的[sensitive],减少其敏感性,装蝲它。意想不到的产品数据打_
最坏的情况Q每一均会导致异常,I指针和你以前从未见q的行ؓ?
注:
开发者经常到E_阶段才想起安全性(“Ӟ屏幕正常Q让我们把用户加为确认的员工”)。花费同L旉来避免这U圈套实现安全性,像你分d业逻辑时候做的那栗?
实施是一个复杂的q程Q充满政治问题和技术问题。你会到你不期望的问题;q就是实施的全部。开发环境和E_性环境给你在实施前犯错误和找到问题的I间Q利用这点,减应用实施过E中你的痛苦和风险?
你经历的目多Q你pҎ知道什么能q行什么不能,Z和你的同伴保留一本项目记事本。在实施q程Q你的目标应该是同样的错误不犯两ơ?
危机5Q选择错误的(开发工P提供?/B>
目阶段Q?/B>提供商选择
所牉|的项目阶D?/B>:设计Q开发,E_?负蝲试Q实?
所影响的系l特?/B>Q可量性,执行性,可维护性,E_?
征兆Q?/B>
解决Q?/STRONG>
Z避免危机5Q你需要一个好的供应商选择q程。危?0在这里是适用的?
对于IDEs,唯一的评h法是M用它。评价J2EE的唯一的方式是构徏一个你的观忉|架中用到的特性的实现。事实上Q当你花?个月开发和投资C特D的培训的时候,你不会希望在q些工具之间出现BUG.
那么Q当你开发的半\上遇到关于工具集的麻烦的时候怎么办?一些工具似乎比其他的更加重要。如果你选择的应用服务器不适合你的需求,你要接受它ƈ改变规范。如果IDE令h恶心Q就讄最别的代码规范Qtabs对空格等{)Qƈ让开发者寻找能最大限度提高生产效率的配置?
注:
了解最好的供应商和工具作ؓ一特D的dq是一个“只做一ơ”的工作。你需要不断对市场评估。例如,q去?2个月Q我曄q?个不同的IDE,q取决于我的应用服务器^収ͼ而不是我是否写EJB代码?
危机6Q不了解你的供应?/B>
目阶段Q供应商选择
所涉及的项目阶D?/B>Q供应商选择之后的所有阶D?
受媄响的pȝҎ?/B>Q可l护性,可测量性,执行?
征兆Q?/STRONG>
解决Q?/STRONG>
为避免由于不了解供应商而生的问题Q去订阅所有的供应商所能提供的资源Q如邮g列表Q新ȝQ和发行注释Q尤其是那些修订BUGS的列表)Q你得到无可估量的信息?/P>
一旦你选定了供应商p马上投资于培训,然后Q徏立一个快速的概念的实现来打破q个它。[Once you've picked your vendors, invest in training as soon as possible, ideally well before the project kicks off. Next, build a quick proof of concept to break the team in gently.原文如此Q译的郁?-{] 建立两个Ejbsq|它们,然后通过你的昄层技术(Swing GUIQJsps {)调用它们。如果你试着构造你的开发环境同时试着满一个项目目标,环境的设|将不尽人意。事实上Q我曄看到q没有经q部|过E的目Q原因是“我们没有时间”。当团队不得不每天晚上干?1点仅仅是Z获得一个发布的应用的时候,此处的意义就昑־ؓ重要。因此,事先p一些时间将q些l节处理好,在以后的路上你将节约大量旉。对那些说“我们的计划没有l我们这么多的时间”的人,我要_“你的计划没有给你不做它的时间。?/P>
注:
在J2EE世界中,工具提供商的技术的可{换性[transferable]如何呢?让我们看一看两个供应商的具体例子——IBM和BEApȝ公司——支持EJB1.1的不同的应用服务器。确实,BEA WebLogic 5.1 ?IBM WebSphere 3.5 有多大程度的怼呢?
q里只是几个不同之处Q还有许多。概要:多数的供应商之间的相似就像粉W和奶a之相g栗在一U应用服务器上成Z名专家ƈ不意味着你在所有的服务器上都是专家。上面的讨论适合于Q何东西:IDEs,调试器,~译工具Q配|管理等{。对于一U特D工h有用经验对于评价其竞争Ҏ是一件好事情。但qƈ不意味着你可以从一U工具^滑的q度到另一U。尽量给你自己时间来熟悉你的工具?/P>
危机7Q没有ؓ可测量性或可执行性设?/B>
目阶段Q设?
所涉及的项目阶D?/B>Q开发,试Q生存期
受媄响的pȝҎ?/B>Q可量性,可执行性,可维护?
征兆Q?/STRONG>
解决Q?/B>
对于危机7Q在分析阶段你要明确的知道系l的执行性能和测量性能——在q入开发之前就要知道你需要得到的数字。如果你知道你需要每U处?0个交易,但所有的实体Bean的设计只能提?0个交?U,那么你需要ؓ你的pȝL替代方式Q比如存储过E,批处理或重写的OLTP 斚w[reworked OLTP aspects ].
量求助于你的工具供应商——他们应该知道他们品的优缺点,q因此而帮助你?/P>
注:
没有为可量性或可执行性设计经常和危机2Q过度设计)相抵触。事实上Q它们相互取长补短。对于危?我的解决方式是只有绝寚w要的时候才q行部v。对于确定可量性和可执行性,你可以在需要的时候设|可能的最大倹{?/P>
如果你确定大量的度是一个必需的需求,你可以指定一个支持最大聚合的应用服务器,可能的话Qؓ你的执行提供一个交易缓存。进一步,你可以设计商业对象如Ejbs来最大程度的利用服务器的架构。XP没有q样的问题,你仍然可以在必须的时候再部v.
我回这U方式,思考提供这U^衡的方式。当我想一个最单的pȝӞ那个pȝ需要提供客戯求的功能和行为?
危机8Q陈旧的开发过E?/B>
目阶段Q开?
所涉及的项目阶D?/B>Q稳定性,生存?
受媄响的pȝҎ?/B>Q可l护性和~码质量
征兆Q?/B>
解决Q?/STRONG>
一个好的Y件设计方法将拯救你的生命。我l常提到XPQ下面的资源包含一个这L链接(Resources)。你发现XP覆盖了很大的l节?
注:
我ƈ没有 没经qJunit单元试和没有用Ant部v的经历——那是两个可以加强XPҎ的免费工兗参见: Resources.
危机9Q用框架失?/STRONG>
目阶段Q开?
所涉及的项目阶D?/B>Q开发过E,E_性能Q生存期
受媄响的pȝҎ?/B>Q可l护性,可扩展性和~码质量
征兆Q?/STRONG>
下面的Q务需要开发者在大量的情况下处理Qƈ且,应该作ؓ使用框架的首要Q务:
解决Q?/STRONG>
我对在重型应用中使用轻量U框架坚信不UR事实上Q我在JavaWorld的第一文?Frameworks Save the Day" 讨论q在企业开发环境中使用框架的问题。如果你现在已经在开发,马上采用框架仍然获得重大收益。你经历重新工作的痛苦Q像日志及异常捕P但就长远来看Q你会节U大量时间和金钱?/P>
注:
当你采用框架和面向组件编E时候,考虑不同U别的重用。在W一层,重塑QplumbingQ,使用0.9或更高的重用因子Qreuse factorQ?q意味着90Q的工程用到它。越是特D的服务Q其重用因子低。是_我可能徏立一个帐h务来理资源使用Q希?0%的工E用到它。但对于那些需要它的工E——那些搞开发的男孩很高兴它在那里Q?/P>
危机10Q将工程计划和设计基于市场广告,而不是技术现?/FONT>
注:
危机10q未出现在我的列表中Q直到我认识到有许多的h而不仅仅是我一个存在对企业java的误解,其是那些新鲜的领域?/P>
目阶段Q?/STRONG> 所影响的项目阶D: 所影响的项目特性: 征兆Q?/STRONG> 解决Q?/STRONG> 不要怿在你目之外的Q何既得利益者。这是说Q不要相信供应商Q除非你已经了解他们了)Q不要相信供应商提供的白U。如果你惌一些真实的应用服务器的Q查询以前的链接Q?A >Resources。进一步,下蝲你想评测的工P挽v袖子Q设计原型。通过提供的例子来q行QQ何好的提供商都有例子Q?/P>
MQ选择正确的供应商和工具集需要花Ҏ_管你的旉可能q不充裕。将你的选择集中?个-4个,然后每个都试一下。花费一周的旉来验证你的应用服务器QIDEQ部|过E等{,直到用这些工具可以满你的开发计划时? 注: 只有q?0危机? 10只是一个武断的数字Q只是作Z个断点——还有数不清的其他危机存在。确实,我自׃知道比这多一倍的危机。即使这P如果你防备了q里所列出的,我保证你的工E可以完和成功?/P>
如果只从q篇文章中吸取一样东西,我的是:没有什么可以替代经验和计划?/I>[There is no substitute for experience and planning]。如果你没有l验Q那么你去试Q然后得到它。在工程q程中,不要赌注押到工E开始时候你以及你团队的培训上。开发前p行一些编码,更好的是在设计之前就做编码。把你的Java和J2EE团队交给l验丰富的h来带以确保整个工E的方向和你团队中那些经验少的成员可以沿着q条路成长v来?/P>
最后,我写的越多,我越清楚我想说的Q? 唉,我没有那么多的空_下一文章将很快出来。不论如何,好q! l论 好吧Q就q么多。上面的互相影响?0危机,是你在企业Java开发中要面对或已l面对的大多敎ͼ如果不是全部的话Q问题的原因。自然的Q在你的旅途中q会遇到许多问题Q但我相信,我已l揭CZ最主要的原因。做个回,下面是按重要程度划分的q?0危机:
所有的目阶段Q尤其是供应商的选择更明显?/P>
所有阶D?
可维护性,可扩展性,设计质量Q代码质?
如果你对J2EE不熟悉,在项目开始阶D你很受打凅R一开始所做的军_对整个目的成功有巨大的媄响。一个好的J2EEN可能要进行一个重大的供应商选择q程q很好地你带入设计和开发状态?/P>
]]>
վ֩ģ壺
Ƶһ|
þùƷѹۿ|
һƷպ߲|
ۺ|
aƬ2023|
߹͵Ʒ|
˾þۺӰԺҳ|
ӽ18վ|
һ˿|
Ƶվ|
ۺŷ㻨|
þóѲվ|
㽶|
һƵ|
һ߹ۿվ|
պƬӰѹۿ|
Һ|
ŪƵ|
˾þۺһ|
Ʒһ|
18վڵ|
˾Ʒձ11|
ѹۿŮվ|
þþƷŮav鶹|
ƷƵѹۿ|
ɫav|
ɫַ|
һƵ|
Ļ|
99Ƶ߾Ʒ|
ASS츾ëPICS|
ƷƵƷ|
Ůڵ|
¼ۺͼƬ|
ŮƵվ|
ֳִִӲ3pƵ|
ƷŮþþ|
һ߹ۿ|
ƷaƬ߹ۿ|
ӰԺһҳСƵ߹ۿ|
ˬִֻ̼վ|