5.7  Golden Hammer（金锤）

图5-17  当你的工具只有一个锤子的时候，其他所有东西就都是钉子

5.7.1  背景

这是软件行业中最常见的反模式之一。供应商，特别是数据库供应商，常常会鼓吹使用他们不断成长的产品套件来解决机构中的大部分需要。考虑到采用特定数据库解决方案的起始成本很高，这些供应商常常会以低得多的价格提供对他们的技术的扩展，这些扩展可以与他们已经部署的产品很好地共同工作。

5.7.2  一般形式

如果软件开发团队在使用特定解决方案或特定供应商的产品方面具备了很高的能力，我们就把这种现象称为Golden Hammer。作为其结果，每个新产品或开发工作都被看做最好用它来解决。很多时候，这个Golden Hammer并不适合当前的问题，但团队不会投入很多精力来探索替代解决方案。

该反模式会导致错误应用某个受喜爱的工具或概念。开发人员和管理者乐于使用已有的方法，不愿学习和应用更合适的新方法。常见的“我们的数据库就是我们的架构”思维方式就是它的典型表现，在全世界的银行业尤其普遍。

鼓吹者常常会建议使用Golden Hammer及其相关产品套件作为一个机构中大部分问题的解决方案。至于采用特定解决方案的起始成本，Golden Hammer的鼓吹者会争辩说将来对技术的扩展可以让风险和成本最小化，这些扩展会被设计成可以和他们已有的产品共同工作。

5.7.3  症状和后果

  ● 对相当广范围内概念上不同的产品使用相同的工具和产品。

  ● 与行业中其他解决方案相比，采用的方案在性能和可伸缩性等方面较差。

  ● 采用特定产品、应用套件或供应商工具集才能最好地描述系统架构。

  ● 开发人员就系统需求与系统分析师和最终用户进行争论，常常鼓吹容易用特定工具解决的需求，并把他们的关注点从采用的工具不能满足的领域转移开。

  ● 开发人员与行业相隔离。他们表现出对替代方法缺乏知识和经验。

  ● 为了利用已有的投资而未能完全满足需求。

  ● 现有产品支配了设计和系统架构。

  ● 新开发活动严重依赖于特定供应商的产品或技术。

5.7.4  典型原因

  ● 使用相同的方法获得了多次成功。

  ● 在某个产品或技术的培训上进行了大量投入和/或取得了很多经验。

  ● 开发群组与行业及其他公司相隔离。

  ● 依赖于其他行业产品无法马上提供的专有产品特性。

  ● “Corncob”引发了该问题（参阅第7章中的Corncob反模式）。

5.7.5  已知例外

Golden Hammer反模式在下面的情况中有时也是有效的：

（1）定义了架构限制的产品是有目的的长期战略解决方案。例如，将Oracle数据库用于持久存储，使用封装的存储过程进行对数据的安全访问。

（2）产品是满足软件大部分要求的供应商套件的一部分。

5.7.6  重构方案

这个解决方案涉及哲学方面以及对开发过程的改变。从哲学角度来看，一个机构需要形成致力于探索新技术的理念。如果没有这种理念，就存在过度依赖特定技术或供应商工具集的潜在危险。这一解决方案要求采取两方面的措施：管理层对开发人员的职业发展做出更多的承诺，以及建立一个开发策略要求明确的软件边界声明来让技术移植成为可能。

需要有良好定义的边界来设计和开发软件系统，这样的边界可以提高单个软件构件的可替换性。构件应该把系统和它的实现的专有特性隔离开。如果采用明确声明的软件边界来开发系统，在构成边界的接口之处就有可能用新的实现来替换当前实现中所使用的软件而不会影响系统中的其他构件。类似于OMG IDL规范的行业标准作为在构件之间建立严格软件边界的工具，其价值是无法衡量的。

此外，软件开发人员需要跟上技术发展的趋势，既包括机构领域内的趋势，也包括整个软件行业中的趋势。通过一些鼓励技术思想交流的活动可以实现这一目的。例如，开发人员可以建立群组来讨论可能会在将来影响到所在机构的技术发展（设计模式、正在形成的标准和新产品）。他们还可以成立读书研讨俱乐部（书研会）来追踪和讨论说明软件开发新方法的出版物。我们在实践中发现书研会是交流观点和新方法时非常有效的办法。即使没有管理层的全面支持，开发人员也可以与有技术思想的人建立非正式的网络，来研究和跟踪新技术和解决方案。行业会议也是一种很好的方法，可以接触其他人和供应商，保持对行业走向以及开发人员可以使用哪些新方案的了解。

对管理层而言，另一个有助的步骤是建立采用开放式系统和架构的决心。如果缺乏这种决心，开发人员往往会认为为了达到短期目标而采取各种必要手段都是可取的。虽然在短期来看这种做法也许是可以令人满意的，但是其未来的结果可能会出现问题，因为需要花大量的精力来对过去的软件进行返工以便适应新的挑战，而不是把系统建立在由过去的成功所形成的坚实基础上。灵活的、可复用的代码要求在最初开发时就进行投入，否则就无法获得长期的效益[Jacobson 1997]。而且，在产品或项目开发中过分依赖特定技术或供应商工具集是一种潜在的风险。在测试如何把风险较低的开放式技术结合到开发工作中来这个方面，开发概念验证原型的内部研究程序相当有效。

另一个在管理层消除或避免Golden Hammer反模式的方法是鼓励雇用来自不同领域、具有不同背景的人。在开发解决方案时，团队可以从具有更广泛的经验基础中受益。与一支对相当广泛的数据库技术方案很有经验的团队相比，所有成员都是对同一个数据库产品具有经验的团队极大地限制了可能的解决方案的空间。

最后，管理层必须在软件开发人员的职业发展方面积极投入，并奖励那些主动改进自身工作的开发人员。

5.7.7  变化

Golden Hammer的一个常见变化是开发人员特别喜欢使用某个软件概念。例如，有些开发人员学到了一两个GoF模式[Gamma 1994]，就把它们应用到所有的软件分析、设计和实现中。他们找出可以套上这些设计模式结构的地方，并强行把它们应用在整个开发过程中，对模式意图和目的的讨论都不能动摇他们。只有通过教育和指导才能帮助大家认识到软件系统构造的其他可用方法。

5.7.8  示例

Golden Hammer反模式的一个常见例子是在以数据库为中心的环境中，除了数据库供应商提供的架构之外就没有别的架构。这样的环境中，在开始面向对象分析之前就已经设定了要使用特定的数据库。这样，软件生命周期常开始于建立E-R（实体－关系）图作为客户提出的需求文档。这种做法往往是破坏性的，因为该E-R图最终被用于说明数据库需求；而在理解系统和建模之前详细设计子系统结构的做法假定了实际客户的需求对系统设计没有什么影响。需求收集活动应该让系统开发人员可以理解用户的需要，直到结果系统的外部表现可以被用户看作是黑盒[Davis 1993]。可以相信的是，有许多系统根本不使用数据库就可以满足用户需求。但是，如果Golden Hammer反模式在起作用，这种可能性从一开始就被降低了，导致每个问题都需要使用数据库才能解决。

随着时间的过去，机构可能会把一些本来可以实现成独立系统的产品开发成以数据库为中心的。数据库发展成应用间互联的基础，它管理对数据的分布式和共享式的访问。此外，利用数据库的专有特性解决了很多实现问题，而这些专有特性都承诺将来会提供移植以与该实现数据库的技术发展保持同步。可是到了某些时候，它可能要与其他系统进行互用，这些系统要么没有使用相同的以数据库为中心的架构，要么使用了不允许对其信息进行不受限制访问的不同数据库。突然之间，开发变得极其昂贵，因为要在不同系统之间建立独特的、专用的连接“桥梁”。但是，如果在情况无法控制之前就考虑到这个问题，就可以建立一个共同的框架，根据标准接口规范如CORBA、DCOM或TCP/IP来选择用于特定领域的产品。

另一个例子是一个具有数个烟囱遗留系统的保险公司，它决定要转换到客户机/服务器模式，使用Microsoft Access作为持久存储的关键部分。该公司的呼叫中心系统的整个前端架构都是围绕着该产品的一个早期版本。由于一个拙劣的架构决策，其后系统的未来就完全受制于该数据库产品的开发途径。不用说，该系统只维持了不到6个月。

5.7.9  相关方案

  ● Lava Flow。如果Golden Hammer反模式在好几年间被应用于很多项目，就会导致Lava Flow反模式。一般来说，根据Golden Hammer的早期版本建立的较老部分就代表了整个应用中那些很少被使用的部分。开发人员不愿意修改这些部分。它们随时间而堆积起来，增加了应用的总体规模，但是只实现了用户很少使用甚至完全不会用到的功能。

  ● Vendor Lock-In。当开发人员主动接受供应商对应用Golden Hammer反模式的支持和鼓励时，就产生了Vendor Lock-In。也就是软件项目在设计和实现面向对象系统时主动承诺依赖于单个供应商提供的方法。