Written with AI assistance from the source video. The video is the authority.
12:23Chris Williamson
Log in to leave a comment
No posts yet
打磨架构规范并在脑海中模拟异常情况是一件很美妙的事，因为脑海中的代码没有Bug且完美无缺。但如果不打开编辑器而是一味地陷入长考，那就不叫谨慎，而只是恐惧，也就是对失败的恐惧。为了规避不确定性而制定的大型设计文档，一旦开始实际开发，往往会在第一个需求变更时土崩瓦解。
为了拯救那些陷入分析瘫痪（Analysis Paralysis）而浪费时间的开发者，我整理了一套打破完美主义、今天就能抛出原型的做事方法。
在写下一行代码之前，对比各种框架和架构的行为会带来极高的认知负荷。执着于发生概率不到0.1%的错误处理，或者在需求还没出来时就急着搭建抽象层，这属于典型的损失回避反应。
根据麦肯锡（McKinsey）和领导力智商（Leadership IQ）对财富500强企业的调查显示，因决策困难和过度分析而浪费的时间每年超过53,000天。换算成人工成本，相当于2.5亿美元的资金在没有任何产出的情况下付诸东流。由于过早优化，开发者个人的生产力也会削减40%以上。
如果觉得脑海中的模拟时间变长了，就必须通过系统来强制终止。只需将极限编程（XP）中的尖峰解决方案（Spike Solution）模式应用到日常开发中即可：
如果连续两周被困在规划阶段，说明的不是规范不足，而是缺乏执行上下文。此时，应该关掉所有设计文档，设定30分钟的时间箱（Timeboxing）。
完成度30%的原型去掉了所有的异常处理、数据库连接和UI精致度。只看输入值后能否得出想要的结果。硅谷的产品团队用实际运行的原型来代替抽象的需求文档开会，原因也正在于此。只有亲自点击界面，不确定性才会消失。
以延迟成本（Cost of Delay）来计算，4名周薪2,025美元的工程师如果连续两周反复开架构会议，就会产生16,200美元的直接和间接损失。
| 评估项目 | 规范驱动开发 | 原型优先开发 | 效果 |
|---|---|---|---|
| 初始需求定义 | 2周~4周（编写文档） | 30分钟~1天（编写尖峰程序） | 节省90%的时间 |
| 规划修改会议 | 平均8次~12次（抽象争论） | 平均2次~3次（基于演示） | 减少70%的会议 |
| 方向性错误修正 | 重建整个结构 | 废弃30分钟的草案 | 最大程度减少返工成本 |
| PR审查速度 | 产生瓶颈 | 提前公开Draft PR | 审查速度提升30% |
如果思考与实现混杂在一起，写代码时就会总是忍不住回头看。这就是为什么要把一天的工作时间明确划分为分析阶段和无条件实现阶段。这与Basecamp的Shape Up方法论中所说的“固定的时间，可变的范围”原则相同。先确定时间，如果觉得在这个时间内无法完成，就直接放弃相应的功能。
当遇到卡壳的地方时，不陷入深度思考而选择绕过的标准，可以遵循马丁·福勒（Martin Fowler）的技术债务象限中的“故意且明智的债务”概念。如果是以后很容易修改的代码，最好选择目前最简单的权宜之计并提交代码。
杰夫·贝佐斯曾说过，当确定性达到70%左右时就应该做出决定并付诸行动。一直等到90%以上完美才行动，是在扼杀速度。
如果因为代码不完美而藏着掖着，以后只会招致更大的返工。Shopify工程团队上传Draft PR的目的不是为了接受完美代码的检阅，而是为了验证工作方向。
PR的大小最好控制在200~300行以下。加上“仅对算法结构方向接受反馈”的WIP标签再上传，也能减轻评审者的负担。
完美的虚拟架构永远无法走出脑海。今天编写的这一行虽显粗糙但能运行的草案，才会成为你的真实实力。当你抛弃完美主义的借口时，才能真正摆脱延迟成本的泥潭。