一台安静的机器，通常意味着设计者替使用者做完了大部分决定。
好的构建工具不该让你读完它的文档才能用起来。它应该有一个能跑通的默认值集合，然后在你真的需要时，才把旋钮交出来。
我越来越喜欢这种顺序：
- 先把最小的闭环跑通；
- 再把闭环里的每一环做得可控；
- 最后才考虑把可控的环做成可替换的。
反过来做 —— 先设计可替换的抽象，再找地方用 —— 得到的通常是一堆看似灵活、实际没人用的接口。
复杂性不会消失，它只会被搬到不会伤人的地方。
这句话我在很多场合引用过。它解释了为什么静态站点生成器比 CMS 更让人安心：把复杂度提前到构建期，运行时就没有东西可以出错了。
当然，代价是构建期要处理的东西变多。这就是增量构建存在的理由 —— 让「提前处理」这件事本身也变得便宜。
至于什么样的复杂度算「不会伤人」，我的判断标准很简单：出错的时候，能不能在一分钟内定位到具体是哪个文件、哪一行。