构建小系统

小系统并不是野心更小的系统。而是系统中每一个活动部件，都能解释清楚自己为什么存在。

复杂度有持有成本

每一个依赖、抽象和配置文件都会索取注意力。它的成本很少在引入当天就显现出来。它出现在以后——当有人必须更新它、调试它，或者决定它是否仍然被需要的时候。

这并不意味着复杂度总是坏的。它意味着复杂度应该买到有价值的东西：

• 更好的体验；
• 更安全的约束；
• 对重复工作的显著减少；
• 或者一种无法简单表达的能力。

质量同样是一种约束

另一个方向上的错误，是把“删除”当作优雅的唯一度量。一个产品的代码可以很少，却依然给人粗糙的感觉。

问题	有用的检验
它改善了体验吗？	继续考虑它。
能否在不损失质量的前提下更简单？	简化它。
简化会让它变简陋吗？	停止简化。

最好的结果，落在复杂度预算与质量底线之间。

目标不是最小的实现，而是足以完整承载想法的最小实现。

让系统可读

当一个系统的结构与其目的一致时，它就更容易被拥有。把内容放在写作者期待内容所在的地方，把视觉规则放在设计师期待视觉规则所在的地方。优先选择描述产品而不是描述框架的命名。

清晰是会复利的。它让下一个决策变得更便宜。