定義：戰術型程式設計（tactical programming）的主要目標是「讓某個東西能動」，例如完成一個新功能或修掉一個 bug。

乍看之下這非常合理：寫出能跑的程式碼還能有什麼比這更重要？但戰術型思維讓你幾乎不可能產出好的系統設計。

為什麼戰術型有問題#

戰術型的根本問題是短視：

• 你想盡快完成手上的任務（也許還有硬性截止期限）
• 規劃未來不是優先事項
• 你不會花太多時間找最好的設計，只想趕快把東西做完
• 你說服自己：為了完成當前任務，加一點點複雜度、塞一兩個 kludge 沒什麼關係

系統怎麼變得複雜#

上一章已說過：複雜性是逐步累積的。

不是某一件事讓系統變糟，而是幾十、幾百件小事一起堆出來的：

• 戰術型寫法每次任務都會貢獻幾個小複雜性
• 每個都看似是「為了快點完成」的合理妥協
• 累積速度極快，特別是當所有人都在戰術型寫法時

接著會發生什麼？

1. 部分複雜性開始造成問題
2. 你開始後悔當初走捷徑
3. 但你又告訴自己：完成下個功能比回頭重構更重要
4. 重構長期看有用，但短期一定會拖慢進度
5. 你只好用 patch 繞過問題 → 製造更多複雜性 → 需要更多 patch
6. 最終 codebase 變成一團亂，這時要清理得花上好幾個月——進度上根本承受不起
7. 修一兩個問題又看不出明顯改善，於是你繼續戰術型下去

一旦走上戰術型之路，要回頭非常困難。

戰術型龍捲風（Tactical Tornado）#

幾乎每個軟體開發組織都至少有一位「戰術型龍捲風」：

• 一位產量驚人的程式設計師，速度遠超其他人
• 但徹底以戰術型方式寫程式
• 要快速塞進一個新功能，沒人比他快

兩面性#

• 管理層的視角：常被當作英雄
• 後續維護者的視角：留下滿地殘骸