软件架构被高估，清晰简单的设计被低估
ABSTRACT
Gergely Orosz 文章（InfoQ 中译）。作者以重写 Uber 分布式支付系统、设计 Skype on Xbox One 的经历说明：一线科技公司的大型系统设计不用 UML/4+1/ADR/C4，也没有专职架构师；靠的是从业务问题出发、白板推演、简洁 RFC 文档、双方案权衡与广泛分发评审。核心主张：设计从简单始、以简单终，架构模式是事后归纳的词汇表而非目标。
核心要点
- 反常识事实：Uber/Skype 的大系统设计不用任何标准架构建模工具（UML、4+1、ADR、C4），只有方框箭头图；团队里没有「架构师」职位，高级工程师照样写代码，初级工程师也能挑战设计决策。
- 科技公司通用设计流程：从业务问题与成功度量入手 → 小规模头脑风暴 → 白板讲清方案（讲不清就是没设计清）→ 简洁文档（类 RFC 模板、少术语，初级工程师也能懂）→ 讨论权衡与备选 → 组织内分发收集反馈并设反馈时限。
- 工程文化是关键差异：高自主、少层级的组织用「基于常识的设计」；层级森严的传统企业才需要正式文档与架构师审批来降低沟通风险——工具没有绝对好坏，取决于环境。
- 简洁设计即目标：系统越简单越容易理解、发现问题与实现；架构描述语言要让经验最少的人也能看懂，如同简洁代码始于单一职责与清晰命名。
- 架构模式的正确定位：与 GoF 设计模式一样，是工程师对相似情境中相似选择的事后命名与记录，用于缩短沟通，而非拿锤子找钉子；无意中应用了某个模式是好事，倒过来为模式而设计是灾难。
- 提升设计能力的实践建议：把设计在白板上讲给同事听并求反馈；写成简单文档用可评论格式分享；永远设计两个方案并对比取舍；清楚自己优化了什么、权衡了什么、受哪些约束；主动评审他人设计、唱反调提更简方案。
- 元认知金句：启动新项目时别想「该用哪些模式与形式化方法」，先想「怎样设计出任何人都容易理解的最简方案」。
关键实体与概念
软件架构、系统设计、RFC 设计文档、白板推演、权衡（trade-off）、架构模式、工程文化、GoF 设计模式、RIBs
关联概念
来源回溯
- 原始文件：
raw/gamedev/软件架构被高估-清晰简单的设计被低估.md（evernote/FW-游戏3研发技术 导入）
时效性评估
- 仍有效：原文 2019 年发表，「简单优先、双方案对比、文档评审」的设计方法论是长青工程智慧，与 编码规范与设计模式 中的 KISS/破窗原则互为印证。
- 已过时：无实质过时内容；ADR/RFC 实践在业界反而更普及，恰好印证其「轻量文档」主张。