级别： 初级 Bill Hines, 高级顾问, IBM
2005 年 5 月 11 日 向客户提供技术和后勤方面的建议，使他们最有效地利用 IBM® 软件——同时 IBM 顾问也能发挥最大作用。
好的、坏的和最差的
还记得上小学的时候，你希望创作出一条最热门的流行语（就像“粗糙(gnarly)”这个词），梦想着它能够传播开来，成为世界有名的流行语，这样你就能够炫耀您是第一个使用它的人吗？是的，没有人愿意轻易放弃希望（我仍在努力），我现在就有一条流行语，希望能够流行开来……
正如每个人都听说过的一个术语“最佳实践” (best practice)。在围绕这个词语进行讨论的所有会议上，其使用和滥用次数达到了极点。而且，它在 IT 行业最常使用的词语中占有了一席之地——诚然，占有一席之地或许只是我个人的想法，遗憾地是，很少有人熟悉“反模式”这个术语。
模式是一个抽象的、可重复的且可重用的设计构造，例如架构或者运算法则。与之相反，术语“反模式”现在常用来表示一个不好的想法或“不好的实践”。基于这个原因，我认为反模式不是一个准确的名称，而应该称为“反实践”——与“最佳实践”相对。
作为一名 IBM Software Services for WebSphere® (ISSW) 顾问，我与美国国内的各种客户进行交流，因而能够直接观察到各种实践，有些实践会让客户获得成功，有些实践会产生问题，还有一些实践只会造成时间和金钱的浪费。这些实践有技术方面的，例如 WebSphere 产品配置问题；也有后勤方面的，例如，要让顾问做现场指导，一个公司应该做哪些准备。是的，这些东西我们早应该讲出来！在过去几年里，我曾帮助撰写过一本相当成功的书以及一些技术文章，光阴荏苒，我认为现在应该是将一些确实 有用的东西进行整理的时候了：向客户提供的一些技术和后勤方面的非正式建议确实可以让每个人都生活得很轻松。和我的 ISSW 同事们一样，我也非常信任 IBM 以及我们的产品，希望尽可能多做一些事情来帮助我们的客户获得成功。产生了这种想法之后，就有了下面的建议。它们只是我个人的一些想法，与我就职的公司、朋友、亲戚、至交或虚构的公司都没有关系。
1. 与心爱的人跳舞
我经常看到这样一种情况，设计和开发一些应用程序是为了将自己编写的“替换”代码用于 WebSphere Application Server/J2EE™ 基础设施的某些部分中。该代码可能实现了自己的线程、缓存、连接池甚至（但愿不会如此）安全基础设施。如果我必须亲临现场的原因是一种危急的情况 (crit-sit)，通常是由于这种自定义代码和试图做相同事情的 WebSphere Application Server 运行时之间的复杂交互所致。
公平地说，在 J2EE 和 WebSphere Application Server 成熟之前有时可能需要编写自定义代码。但随着时间的推移，这种代码很少像客户购买的产品中的代码那样牢固可靠、经过反复测试且性能良好。事实上，在为进行身份验证或授权而编写的自定义代码中通常很容易找到漏洞或对漏洞进行攻击。因此，无论您从公司内部权威或代码奇才那里听到什么，一定要对编写这种代码有清楚的认识——不要动摇！我经常并且一贯地催促客户停止不断地投资维护这种“系统”类型的代码，其原因主要是他们将大量的财力花费在现成的东西上。
不要在产品中保留这种系统代码，将这些高额的开发费用集中在业务逻辑上。
2. 利用 KISS
音乐家们绝不会强作欢颜——我听说他们不敢越雷池一步。您知道这意味着什么：我们在此只需要讨论这个短语——保持简短简单（Keep It Short and Simple，KISS）——的一部分，即“保持简单”(Keep It Simple)。此外，公平地说，大多数案例已经证明存在某种程度的复杂性（我想到了模型-视图-控制器模式），但是只有少数企业应用程序需要我们在这一领域经常看到的许多过于复杂的架构。这是因为将某位博士或者著名的技术专家在 ACM 期刊上发表的论文作为您的“实际”设计的基础通常不合理。在 Internet 论坛或行业期刊上公开的技术与此类似。有一些技术确实不错，但也有很多技术会引发灾难。有些模式，例如，拆分 Servlet 和 EJB 层、在 Web 服务器和 WebSphere Application Server Servlet 容器之间运行负载均衡器 (Load Balancer) 以及准同步消息传递，不仅过于复杂，而且对于大多数需求来说是多余的，对于性能和配置，这些模式简直是魔鬼。
根据实际情况评估每个建议的价值——谨记您的目标和环境，确保您希望尝试的架构和技术已经过验证并且非常合适。我的许多蓝调口琴琴友痴迷于能够与已故的 Little Walter 演奏出相同的“声音”，他们从职业演奏者买来经过认可、昂贵且复杂的数码音效处理器或器械，希望能达到 Little Walter 演奏的声音效果。但他们不了解的是，Walter 演奏出来的是来自灵魂的声音，经常演奏的是老曲子，而且当您在现场欣赏职业演奏者的演奏时，他们也经常演奏老曲子！
使用您拥有的并且用得得心应手的东西。千万不要接受看似“合适”的设计，这种设计只是其他某个人脱离实际的一种想法。邀请同行参加评审，如果在您的技术人员中找不到合适的人选，可以与 IBM 签约，让 ISSW 的某个成员来替您进行评审，并向您提供反馈。
3. 分享爱，公开您的代码
许多客户没有代码或架构评审过程。花一些时间来进行这些评审有很多好处，例如，加快初级编程人员的进步速度、增加重用、阻止恶意代码，以及在代码投入生产之前捕获错误和反模式，等等。在有严格的代码评审过程（即，只有经过多方评审才能将代码转到生产版本）的情况下，通常可以节省使用 Java™ 2 安全性的费用。
在进行这种一体化评审时，进行评审的任何人都要确保环境尽可能地友好且不受到任何影响，这一点至关重要。一开始就要消除利己主义。没有人能够凌驾于代码评审之上。代码评审将鼓励“用良心编程”——如果开发人员知道周末有人要检查他们的代码，他们中的许多人在这种压力下或许一半的工作都完成不了！
第一步，利用静态代码分析器浏览代码并搜索反模式，以确保遵循良好的编码实践。如果使用一些工具，例如 IBM Rational® Application Developer V6 中内置的某些工具，您甚至能够建立自己的规则。
4. 自包含 EAR 文件
在这方面我看到的许多问题都与“类加载器错误”有关——由于将 JAR 文件放到基础设施而在运行时引入错误类，致使引起复杂且难以调试的问题。J2EE 的一个主要准则是在企业归档 (EAR) 文件中应用程序应该是完全自包含的。然而，由于考虑到磁盘空间和其他一些特殊原因，许多企业对待 JAR 文件的做法是，应用程序可以共享系统类路径目录或共享库，因而使其部署、管理和运行时环境变得相当复杂。这可以通过数据库驱动器等工具来验证，该工具适用于部分基础设施和所有的应用程序，此外别无他用。
目前磁盘空间相当便宜，因而大多数情况下您只要坚持在 EAR 中使用它即可。
（有关该主题的详细信息，请阅读 Keys Botzum 对 J2EE packaging and common code 的酷评——我指的是 developerWorks 上的一篇文章。）
5. 勿因恶小而为之
一些严重问题的常见原因是，对各种无用信息使用/滥用 HTTP 会话。这种情况都是从一个编程人员决定在会话中扔一点东西开始的，接着另一个编程人员也这么做，同样又有一个编程人员加入进来，一直到您的可怜的会话看起来像一个受到污染的池塘，里面填满了旧的轮胎和洗衣机。
在最终期限即将来临的压力下，向会话中填充东西是一种常见的捷径。这对 JVM 堆的大小和性能的影响（尤其在使用持久性会话时）相当大。进行代码评审（请参见第 3 条）可以帮助避免这一问题。会话的大小应该为 2-4K，测量会话的大小有多种方法；例如，WebSphere Application Server 附带的 Tivoli® Performance Monitor 可以向您显示会话的大小。
然而，对这个问题负有责任的不只是编程人员。从拓扑/架构的观点来看，我们还经常看到网络非军事区（DMZ，您拥有一个非军事区，对吗？），由于对防火墙/端口问题或其他问题的快速修复，它们已经“受到污染”。对于任何可能的入侵者或攻击者来说，DMZ 是一个“无保护的”——“不利的”——环境。WebSphere Application Server 实例、数据库、消息传递服务器、邮件服务器或其他复杂的进程都不应该在这里运行。DMZ 应该包括一些进程，例如，在用户连接到达后端“受信任”区之前，Web 服务器或代理服务器将终止用户的连接。
保持干净。DMZ 中越复杂，暴露给饥渴和垂涎欲滴的攻击者的可攻击目标就越多。
6. RTFM
阅读一些不错的手册。（您认为它的意思是什么呢？）我的意思是说，通过参考文档或者搜索 Internet 上的资料可以解决许多问题。各种组织应该勤于维护一个好的知识库，并给出一定的时间让开发人员阅读。毕竟，PDF 格式的红皮书是免费下载的（您可以订购打印版）。IBM 出版社还出版了许多专门针对 WebSphere 产品的优秀书籍。Web 资源，例如，developerWorks 和 WebSphere Developer 技术期刊也是免费的，其中包括大量经常更新的信息。可以从 IBM 顾问甚至 developerWorks 论坛和专门用于 WebSphere 的 Internet usenet 新闻组 ((ibm.software.websphere.*). ) 上的其他客户很快得到问题的答复。
与昂贵的培训费用相比，这些资源都相当便宜，而且是不可或缺的。当然，这里假定您拥有有动力去做研究的技术人员。要培育这种环境，可以考虑召开每周一次的开发人员会议或“午餐学习”会议，要求参与人员讨论他们阅读到的或发现的有用话题。请不要误会。我确实喜欢与客户交流，但是如果将不必要的咨询访问费用花在我们的产品上，将会更好——我不希望拥有一个不公平的（和不准确的）名誉，即需要的咨询帮助只是正确地配置和使用我们的产品。
切实努力地解决问题。
7. 尽早测试，经常测试
通常，只要遵循合理的测试计划的提示，就可以避免看到这方面的问题。到目前为止，测试是可用的最好捷径。如果没有任何其他的最佳实践，则在发布之前进行合理的测试通常可以避免灾难性的结果。是的，测试费用相当高昂，但生产损耗可能会更大。现在不做，以后还是要做；不要剜肉补疮，等等。这些都是我们以前听说过的。我们的书中的第 16 章介绍了我们推荐的测试环境和步骤。另外，一定要让您的某个技术人员购买和阅读由 Stacy Joines、Ruth Willenborg 和 Ken Hygh 合著的书籍 Performance Analysis for Java Web Sites。他们都是这个主题方面的优秀人士，这本书也是我所阅读过的最好的 IT 书籍。
测试。立即开始。
8. 设计一张表！
……当然，对于顾问的到访，客户希望他们的付出能够获得最大的回报，而我们这些 ISSW 顾问也希望竭尽所能地向客户提供服务，使其满意。如果客户确实为顾问提供现场指导做好了准备，就很可能出现这样的情况。如果未准备好适当的工作区和 Internet 接入，不能搜索重要的内部数据库以找到重要的文档，或不能与内部开发和实验室团队进行交流，都将严重限制顾问快速解决问题的能力。
下面是一个简短但不可或缺的清单，清单中的各项浅显易懂，可以帮助您为下一次的现场指导做好准备，以使顾问能够立即投入工作：
- 为即将到访的顾问安排进入设备时所用的适当凭证，不要每天都把时间浪费在进入设备上。
- 确保技术人员中合适的人员知道顾问的计划到访时间，他们可以拟定计划以与顾问进行大量的交流。
- 在为您提供指导的顾问到访之前，与其进行交流，确保他们了解需要解决的问题，以使他们能够适当地进行准备。
- 最重要的一点是：在顾问进行现场指导时，让他们忙起来！
时间就是金钱。确保使其物有所值。
我已经介绍了很多，要超出讨论的范围了。这是我的想法，我坚持我的想法。相信我将想到（和听到）应该加入更多的反实践，但是让我们先把这些工作做好。如果有机会对其进行修改，希望它是一个全新的列表——至少看上去进步了！
参考资料
关于作者  | | |
Bill Hines 是 IBM Software Services for WebSphere 的一位认证 IT 咨询专家。他专门研究企业 J2EE WebSphere 应用程序的安装、配置、调优、管理、安全、故障诊断以及设计/架构方面的问题。 |
对本文的评价
| 
