Design Patterns : 时间教会我的关于架构的事
Source: Dev.to
请提供您希望翻译的完整文本内容（除代码块和 URL 之外），我将按照要求把它翻译成简体中文并保持原有的 Markdown 格式。
介绍
如果你是开发者，肯定已经接触过 Gang of Four 的书，或者为某个设计模式的考试而学习过。职业生涯初期，设计模式看起来像是“魔法配方”。但随着多年经验的积累以及大量系统投入生产后，我们会发现真正的高级水平并不是记住这些模式，而是知道何时不使用它们。
作为开发者工作了一段时间后，我发现设计模式像是一套共同的词汇。它们并不是用来让代码“漂亮”或复杂化的，而是让代码更可持续、易于沟通。当我说“这里用了一个 Adapter”，同事立刻就能理解其架构意图，而无需阅读上百行代码。
在本文中，我将分享我认为对任何想要或已经担任中高级（pleno 或 senior）职位的开发者必备的模式，重点聚焦于解决真实问题。
Strategy
技术债务最明显的信号之一是那种方法一开始只有一个 if，六个月后却变成了 15 个 else if 或者一个巨大的 switch。
Strategy 将规则与上下文分离。想象一个电子商务系统，需要为不同的运输公司计算运费。与其在结账服务中混杂大量逻辑，你可以把每个运输公司隔离到各自的类中。
高级视角
- 便于对每个策略单独进行测试。
- 允许在不触及已有代码的情况下添加新的运输公司（开放/封闭原则）。
Observer / Pub‑Sub
在现代世界，单体和同步系统是瓶颈。Observer 模式（或其演进为带消息的 Pub/Sub）允许系统的各部分在不相互耦合的情况下知道某事已发生。
如果用户完成购买，库存系统、发票系统和营销系统都需要被通知。以同步方式串联这些调用会导致，如果邮件服务失败，整个购买过程会卡住。
高级视角
- 设计弹性系统。
- 应用核心保持对其外围的独立（agnostic）。
- 在前端，我们每天使用它来处理全局状态和事件；在后端，它是面向事件架构的基础。
Adapter
Adapter 充当“边界”。您创建一个系统能够理解的接口，并将外部来的内容翻译进入该接口。
高级视角
如果短信提供商更换公司或更新 API，您只需更改 Adapter。系统的其余部分甚至不会感知到变化，从而保护领域不受您无法控制的外部因素影响。
避免过度设计
这里是我们区分经验丰富的专业人士和理论家的地方。高级工程师最大的陷阱是过度设计。
- 抽象是有代价的: 认知复杂性。对永远不会有第二种变体的情况使用 Abstract Factory 是浪费时间和资源。
- KISS（Keep It Simple, Stupid）: 最简单的解决方案往往是最好的。
- YAGNI（You Ain’t Gonna Need It）: 不要因为“也许有一天我们会需要它”而实现某个功能。只有在真正需要时才实现。
结论
掌握这些模式就像拥有一整套工具箱。但正如木匠不会用电锯来钉画框，资深开发者懂得为特定问题选择合适的工具。
保持思维清晰以做出架构决策，需要既关注代码也关注“机器”本身。关注健康和性能——例如补充 omega‑3 以保持专注和认知敏锐——可能决定成败，因为设计复杂系统是一项高强度的脑力运动。
那么你呢？ 哪个设计模式曾拯救过你的项目（或在哪儿误用导致灾难）？欢迎在评论区交流想法！
Tags: SoftwareArchitecture DesignPatterns Fullstack Programming Seniority CleanCode