案例研究：物流中的超通用框架

一家非常大的物流公司聘请了一家咨询公司来建立一个网上商店来购买该物流公司的产品。该系统的核心是一个使用通用订单框架构建的专有订单引擎。我们检查了系统并发现以下行为：

• 一切都是命令。如果您想更改地址、购买商品或更改信用卡信息，则可以使用 Order 类并对其进行配置。该框架通过解析元信息和位掩码来确定要做什么。基于位掩码，SQL 语句已被组装。
• 系统只有两个数据库表：事务和主数据。这些表非常大，因为它们必须保存各种交易和各种主数据。Oracle 中的关系由深层的“先验连接”树进行管理。任何无法映射到表“结构”的内容都被装载在“数据”varchar2 字段中。通过了解哪个位掩码需要对 varchar2 字段进行哪种解析，框架知道如何处理数据字段。在许多情况下，框架将值解析为整数、长整型或字符串数​​组。
• 没有单元测试。该咨询公司表示，“该系统对于单元测试来说过于复杂”。

为不使用 Linux 的开发人员设置开发人员工作站花了近两周的时间。幸运的是，Linux 用户可以在几天内完成。有太多的脚本需要运行来启动 Weblogic 并使用特定的“框架插件”运行，但似乎没有人能正确执行。没有文档，一切都是反复试验。

系统的背景是什么？

• 它看起来像 Enterprise Java，但有很多特定的自定义实现
• Oracle数据库、Weblogic应用服务器
• 庞大的组织
• 组织销售数字产品的第一步
• 一家姐妹公司提供类似的服务，但开发成本低得多。这引发了审查。

什么是好主意？
人们相信构建一个通用的订单引擎，可以在客户的许多项目以及其他客户的项目中重复使用。

造成了什么不好的后果，为什么一切都不好？
实现新功能需要很长时间。理解代码库很难，但测试它更难。单元测试不可能，集成测试可以，但是反馈周期很长。应用程序领域本身很简单，但我们仍然遇到了您认为不会遇到的巨大问题。拥有两个通用数据库表的想法被证明是一个很大的性能瓶颈，需要非常具体的 Oracle 知识来解决。

遇到了哪些模式？

• 过度设计——客户想要一个简单的网上商店来销售一种简单的产品。该咨询公司提供了一个高度复杂的系统，理论上可以处理大量的产品。此外，该系统没有使用现有技术，而是重新发明了轮子。由于无法进行单元测试，因此他们提出了自己的集成测试框架和许多其他“此处未发明”的综合症解决方案。
• 误用通用性- 客户想要针对特定​​问题的解决方案：针对一种产品的网上商店。该解决方案是一个解决世界上所有网上商店问题的系统。然而，该解决方案无法正常工作，成本太高且速度太慢。
• 抽象偏见——一切都是秩序。产品的订单就是订单。而且更改地址数据或密码也是一个命令。一切都是命令，一个简单的 CRUD 应用程序就可以完成

情况是如何解决的？
原来的咨询公司被解雇了，并聘请了一家新咨询公司从头开始开发该系统。