本书系统地介绍了常见的服务器Java编程错误，以及这些错误产生的原因和解决方案。书中涵盖了基本Java和J2EE概念的反模式，如servlet、JSP、EJB、企业连接模型和可扩展性等，通过代码示例展示了Java编程中常见的陷阱，还提供了重构代码，并解释了为什么新方案是安全的。本书适合中级水平的Java程序员、分析员或架构师阅读，通过研究书中介绍的反模式，可以吸收别人的经验教训，在工作中少走弯路。[前言]到了夏天，得克萨斯河水就几近干涸。为了寻找急流，漂流者不得不跟着暴风雨的脚步走。那是1996年夏天的一天，我和一个同伴晚上8点离开奥斯汀，冲入狂暴的风雨中，一直来到阿肯色州的Cossatot河。等我们到了那里，坏天气好像跟我们开了个残酷的玩笑，居然绕过这条河径直走了。我们筋疲力尽，失望之极，只好在河岸上扎营休息。那天晚上我们根本没有听到一丝雨声。到了早上，我还是垂头丧气，头昏眼花地走出帐篷，然后几乎跌倒……在河里。Cossatot河素来就有涨水极快的坏名声，仅仅因为上游10英里处下了2个小时的雨，水位就突涨了6英尺。现在我们倒是可以漂流了，但是水位又太高。我们决定等第二天早上再来对付难度大的这一段，先到相对容易一些的上游漂流。原来水流迟缓的1级水域现在已经变成了汹涌的3级急流。指南上说这一段要漂流“4个小时”，但我们只花了20分钟就飞驰而下。“中间”河段更糟糕：湍急的河水已经达到4级，猛烈地咆哮着。经过仔细侦察，我们轮流在河岸上执守，一个人在河水中漂流时，要系着安全带，由另一个人在岸上监视情况。然后我们把皮划艇放在营地，徒步走下去，看看下面的河段情况怎么样。让我们惊讶的是，居然有几十个当地人在河岸旁放着躺椅，像看风景一样看着河面。以往他们看到的只是4级瀑布，如今这条河已经完全被可怕的大漩涡所笼罩。此前，我们很少看到当地人，他们在这里只是看有没有人出风头，有没有惊险的事情发生。这种景象让我们目瞪口呆，所以我和同伴也各自坐在一块大石头上开始看热闹。追溯到2000年，尽管当时我的职位已经不低，而且待遇优厚，但我还是离开了IBM，去加入一家名叫allmystuff的创业型（startup）公司。当时经济已经开始衰退，但是在奥斯汀其他创业型公司纷纷垮台之际，这家公司却刚刚拿到了赞助。这家公司的企业运作并不取决于广告收入，所以尽管广告收入日薄，似乎也影响不大，另外allmystuff里集结了许多精兵良将。我加入公司之时，它的银行资金有一千万美元，不仅有固定客户，而且拥有着高新技术，这一切都预示着它很可能成为炙手可热的成功企业。我见过许多朋友都离开IBM大旗，转而投奔其他公司，虽然新公司的待遇不能比，也没有安全感，但是很有冒险性。我想反正在必要时还可以回去，所以面对着即将到来的黑暗，我迎头冲入到这场风暴中。在奥斯汀新闻笑谈曾经红极一时的创业型公司都纷纷落马之时，allmystuff也开始在困境中挣扎。我们日以继夜地工作，为很少的几个客户部署解决方案。尽管我们的质量一流，有让人自豪的业绩记录，但最后还是被衰退的经济所累。风险投资者决定最好还是关门大吉，再找寻一种适应这种经济衰退局势的新概念东山再起。尽管这件事本身让人很难受，但是在我的职业生涯中，那个时期我学到的东西却是任何其他时候都比不上的。就像Cossatot河岸上的当地人一样，如果一个冒险故事是我们身边发生的真事，很刺激，甚至很危险，那我们大多数人都无法抵挡它的吸引力。不论是看一个久负盛名的希腊悲剧故事，还是看像电视剧“生存者”（Survivor）这样一些最新的流行节目，我们的猎奇思想永无止境。程序员也不例外。我们很喜欢聊最近发生的冒险事情（我们把这称为“实境谈话”（merctalk）），这有很多原因。我有许多鲜活的工作记忆就是在allmystuff的乒乓球台边留下的。在那里我们讨论过管理哲学；讨论过代码基是不是已经失控；另外还讨论过，与日益复杂的JSP模型相比，有专门浏览器的XML是不是一种更简单的方案。我们还讨论过，眼看着进度不断推迟，图形化设计人员能不能把他设计的用户界面映射为越来越复杂的Java命令。正是这些讨论燃起了我的热情，促使我离开了原本安稳的职位，做着百万富翁的梦，投向这个待遇更低、没有安全感的新工作。这些经验使我成为一个更好的程序员、管理人员和架构师。不记得在哪个场合下，前IBM主席JohnAkers曾说过，太多的人“整天都只是喝水聊天，无所事事”。我记得听了这话我们都很生气，他不知道，往往在喝水（或喝酒）时或者在乒乓球台边听到的东西会决定一个项目（甚至一个公司）的成败。在这里，必须听些程序员的故事，受些熏陶，因为这些会影响一生。我准备把其中一些故事放到《BitterJava》这本书里。再回到早先，那时我还没有加入allmystuff，正准备在一个会议上演讲。我报告的题目是“BitterJava”。在会议期间，我遇到了一位著名的Java程序员，JSP的创始人之一。他告诉我曾经在Pamplona参加过“公牛奔跑”（runwiththebulls）活动（译者注：这是一个很经典的活动，人们拼命地在公牛前面奔跑，一路上公牛会踩伤、踢伤或用角刺伤很多人，但人们还是乐此不疲，认为这是勇敢者的游戏），还被刺伤了。他还很起劲地给我解释他在参加公牛奔跑时的策略。我对他讲的不以为然。在Pamplona，早有无数的人告诉过我怎样避免被刺伤。我还向O.J.Simpson咨询过这方面的问题。每年都有数万个热衷于此的人参加，但只有十几个被刺伤。不过，慢慢地我有了想法：如果我要参加公牛奔跑，那我就会和他讨论。我想知道他是怎么计划的，他又怎么实施他的计划，哪里出了问题。这些信息我能用得上。后来发现，这个被刺伤的程序员正是allmystuff工程部的副总裁，他招募我帮助建立他的服务机构。再来说我的报告，尽管讲这个Pamplona故事可能会让我失去在allmystuff工作的机会，但我还是决定用这个故事来开始我的演讲。它充分体现了《BitterJava》中的概念。要说能帮助避免一个微妙的圈套或陷阱，一个关于失败的故事往往抵得上10个成功的故事。这个故事牢牢地吸引住了听众，而且……我也得到了我的工作。像许多程序员一样，我很喜欢极限运动。我们曾划着小艇遭遇危险，有时甚至遇到生命危险。WilliamNeely曾经讲过漂流界很有名的一个法则：你注视一个急流的时间与它吞掉你的危险往往成正比。换句话说，如果看上去漩涡大到能吃掉你，它很可能就会吃掉你。漂流者有自己的一套办法来描述如何沿河下行。漂流指南中会指出一条路线，还会指出路线沿线以及路线之外的一些危险地方。指南中可能说，“接下来，你会看到中间有一块大石头，你要向左。如果误撞到右边，那这个急流就会成为‘终结者’，用残酷的方式告诉你错了。”我很清楚，即使你没有真正了解一条河的威力，你也很想知道哪些地方可能出问题。我想知道水下有没有岩石，有没有陷阱等着我。我想知道哪里可能遇到漩涡，怎么躲过瀑布底下的大石头。我想知道，是不是有人在这条河上丧生，那是怎么回事。如果没有足够的了解，就算有高超的技术，我往往也会回避，甚至顶着小船沿河岸一路走下去，就是不下水。程序员（包括我）也是一样。我要了解应用和项目会在哪里失败。我要知道是不是与某个接口的通信太多了，所用的技术能不能解决这个问题。我得明白一个技术可能在哪里出问题，这个技术能不能扩展。我深信，要想成功，软件开发中总少不了失败，而且势必要从中学习。我还没有看到哪个组织能系统地从错误中学习，并以正规、系统的方式仔细分析为什么要修改一个有问题的设计模式或过程。我曾经看过许多代码，但并不是所有代码都很好。我已经领会到“bitterJava”的魅力，希望你也一样。
鄂公网安备 42010302001612号 