反馈速度，才是开发真正的速度上限

开发中的很多等待，看起来只是几秒钟：类型检查、测试启动、页面刷新、部署完成。它们重复几十次以后，就会改变一个人愿意验证多少次自己的判断。

短反馈鼓励小步前进

当单个测试能在一秒内返回结果，开发者更愿意先验证一个边界，再继续下一步。当完整反馈需要二十分钟，人会自然地把更多改动攒在一起，最后得到一个很难定位的失败。

因此，“提高开发速度”首先不是让每一步写得更快，而是让错误更早、更靠近它产生的位置出现。

选择真正的公共边界

测试数量不是目标。一个穿过真实路由、真实内容模型和真实渲染层的浏览器测试，通常比十个紧贴内部函数的测试更有价值。

好的测试描述读者能做什么：发现文章、按主题浏览、切换阅读主题。它不关心页面被拆成几个组件，也不统计某个内部函数被调用了几次。

构建系统也是反馈系统

静态类型、内容 schema、生产构建和浏览器验收分别捕获不同种类的问题。它们应该从快到慢排列，并且都能在本地复现。

真正高效的工作流不是没有失败，而是每次失败都足够具体，能够直接指向下一步动作。