这一篇主要是对比两种编程心态：
中心主题
战术编程
追求尽快跑通
战略编程
为好设计持续投资一.战术编程
这是绝大多数程序员写代码时候的心态，目标是让手头的东西尽快跑起来，一个新功能或者是一个bug修复。
但复杂性是积少成多的，让系统变复杂的从来不是某一次的大事故，而是几百个小决定堆积到一起，并且复杂性会让你倾向于找补丁快速绕过，而补丁则会制造更多的复杂性，更多复杂性又会需要更多补丁，就会形成一个闭环。
1.1.人物画像(战术龙卷风)
几乎每个软件组织里都有至少一个把战术编程推到极致的人——原书称之为战术龙卷风（tactical tornado）。
战术龙卷风有3个特征：
①.产量
出代码的速度远超旁人
论快速糊出一个能跑的功能，没人比战术龙卷风更快。他 prolific(多产的，高产的)、高产、永远最先交卷——但工作方式是彻头彻尾战术的。
②.待遇
被管理层当英雄
管理者看得见的是这周上线了几个功能，看不见的是代码里埋下的依赖和晦涩。于是龙卷风拿到表扬、晋升和话语权
③.尾迹
身后是一片废墟
未来要和他的代码共事的工程师，很少把他当英雄。典型剧情：别人跟在后面收拾残局——而这些真正的英雄，反而显得比龙卷风慢。
二.战略编程
主要目标是好设计，顺便能跑
成为好的软件设计者的第一步是承认能跑的代码还不够，为了更快交差引入不必要的复杂性是不可接受的。
战略编程是一种投资心态，不走完成当前任务的最短路径，而是主动花时间改善系统的设计。这里的投资分为主动投资和反应式投资。
①.主动投资·别用第一个想到的设计
给每一个新类多花一点时间：先试两三个候选方案，挑最干净的那个(接口更直白，读的人认知负荷更低)
②.主动投资·预演未来的变化
想象系统今后可能要改的几种方式，确认在当前的设计下它们好做
③.主动投资·写好文档
把为什么这么设计留下来
④.反应式投资·发现设计问题就修掉
发现问题后不要无视，不要打补丁绕过，多花一点时间来真正修好它。
这里举个代码的例子，假设线上报了个bug，某张旧订单金额算错了。
f (inv.id === 8841) 是没人看得懂的晦涩（为什么偏偏这单减 20？下一个读代码的人无从知晓）；折扣规则散落各处则是下一次变化放大的种子。右边只慢了 15 分钟，却把「有哪些折扣」变成了一个可搜索、可枚举的事实。
三.应该如何投入
事前的巨额投资以及瀑布式的流程都是不可取的，理想的设计是要随着对系统的理解一点点的长出来的，正确的姿势应该是持续不断地做很多小的投资。
四.压力最大的地方恰恰是输不起的
早起的创业公司往往在设计上不花力气，出问题懒得清理，往往是等成功了，就有钱雇人来收拾了。
但这里就存在两个问题：
1.代码一旦变成意大利面，就几乎不可能修好，而且大概率要在产品的整个生命周期中付高昂的开发成本
2.好设计的回报来的其实很快
并且还存在隐蔽的第三层，烂代码会赶走最需要的人，如优秀的工程师，他们极度在意设计