You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy.
-Jackie Stewart, racing driver
“机械同情”一词最初由 Jackie Stewart 创造，用于捕捉赛车手的特征，他们需要对赛车的工作原理有深刻而直观的理解，以便从车辆中获得最佳性能。
Martin Thompson 在讨论他的 LMAX 架构时，将这个术语应用于软件开发，该架构利用了对云系统功能的低级和直观理解，以最大化其性能。Thompson 维护了一个 博客 多年，主题是这个话题，值得回顾并阅读那里的帖子。
在这篇简短的论文中，我想提出另一个概念和设计原则，即 架构同情：
架构同情是一个软件片段采用并符合另一个软件片段的架构设计的特征
这是我在设计 htmx 和 hyperscript 时一直牢记的设计原则，我想写下来作为参考，以便其他人思考、批评并改进它。
htmx 在架构上对 Web 抱有同情，因为它采用了 Web 的底层 REST-ful 架构：以 REST-ful 方式与超媒体服务器交换 超媒体。在实际可行的范围内，htmx 从现有的 Web 基础设施中获取设计线索：
htmx 试图 融入 Web 现有的概念架构，而不是取代它。
这与构建 Web 应用的 SPA 方法形成对比。大多数 SPA 框架与原始 Web 模型几乎没有架构同情。相反，它们在很大程度上 取代 了 Web 的原始 REST-ful、面向超媒体的架构，转而采用更像厚客户端的架构，通过 类似 RPC 的固定数据格式 网络架构交换信息。
如果一个新软件与原始软件保持架构同情，将获得以下优势：
当然，像任何设计原则一样，使用架构同情时存在权衡：
我喜欢指出的一个非软件的架构同情例子是中世纪大教堂：这些大教堂往往由许多不同的建造者和建筑师（当时的情况如此）在几个世纪内建造、重建成和改进。然而，在这些世纪中，它们能够与早期工人的工作保持高度的架构同情。
工人们不是专注于建造的激进新方法，而是专注于维护一个连贯的整体，并在该框架内注重他们个人贡献的工艺。是的，沿途有一些华丽和变化，但这些通常不会为了创新而牺牲整体的概念连贯性。
在软件开发中采用架构同情的思维方式，通常意味着牺牲你想做事情的方式，转而采用原始软件做事情的方式。虽然这种约束有时会让人感到不适，但它也可以产生工艺精湛的软件，这种软件和谐且与现有软件很好地契合。