一句话
能用更少假设解释的方案,通常更值得先验证。
核心逻辑
- 数一数每个解释依赖多少假设。
- 先验证最便宜的关键假设。
- 复杂性必须付出明确收益。
例子
网站样式错乱,先看移动端断点和容器宽度,而不是假设浏览器、框架和构建系统一起出了问题。
常见误区
- 把“简单”误解成“粗糙”。
- 忽略真实世界里确实存在的复杂性。
面对多个解释时,优先选择假设更少、结构更短、验证成本更低的那个。
能用更少假设解释的方案,通常更值得先验证。
网站样式错乱,先看移动端断点和容器宽度,而不是假设浏览器、框架和构建系统一起出了问题。