程式碼品質還重要嗎？關鍵在這一點——Capital One 的 Max Kanat-Alexander

Capital One 的軟體工程主管 Max Kanat‑Alexander 主張：程式碼品質只對「耐久型」軟體有意義，對「拋棄型」軟體則無關緊要——真正的目標是讓嚴謹的成本低到「該不該嚴謹」不再是個昂貴的抉擇。這場 16 分鐘的演講，大半篇幅都在建立一套用來思考這條分界的框架：軟體成功的雙因子模型（理解，以及據此執行）、修改風險的分類、四變數的拋棄性量表，以及一組能壓低工程嚴謹成本的實務做法。標題提出的問題，直到最後一分鐘才給出直接答案。

Kanat‑Alexander 把這場演講定位為一種修正：一方面針對社群媒體上把問題簡化成「是或否」的論調，另一方面也針對資深工程師「要看情況」的反射性回答。他的答案是：要看四項可量測的屬性——失敗的後果、替換的成本、依賴關係、維護的成本——而 AI 程式開發工具即將讓這個光譜的某一端變得極為普遍。讀者讀完應該帶走三樣東西：這套框架、他點名用來壓低嚴謹成本的具體做法，以及他對軟體生態將如何在耐久型與拋棄型之間分裂的預測。

軟體的一切成果，歸根究柢都取決於理解與據此執行

Kanat‑Alexander 開場先丟擲一個他視為地基的論點：你想用軟體達成的任何事，都只取決於兩個因子——理解，以及根據這份理解去執行。他把這個說法一路延伸到對齊模型、擴充套件系統、推動採用。除錯器、可觀測性、評估（evals）、測試之所以存在，唯一理由就是增進理解、或增進依據理解採取行動的能力。「我們在程式碼品質這個領域所做的一切，完完全全只為了這兩件事，」他說，並明確把「正確性」排除在獨立理由之外。

對軟體工程師而言，有兩種理解最重要：

• 系統的實際行為是什麼——不是檔案上寫的，而是它具體做了什麼。
• 我要如何正確且安全地修改這個行為。

他用規模來說明為什麼「結構」正是程式碼存在的全部意義。在一個微不足道的小系統上，理解不過是被告知它做什麼（「它會印出 hello world」），修改也只是改一行。但在真實系統上，行為量實質上是無限的：他秀出 Chrome 背後開源專案 Chromium 的程式碼庫地圖，說他根本無法用言語描述它整體的行為。他能描述的是某個元件——他指著 Chromium 的 URL 解析器——而這正是程式碼存在的理由：把結構強加上去。

他用兩支都會在 Linux 機器上印出 hello world 的程式來舉例。左邊那支具有「hello world」的身分與結構；右邊那支只是一連串赤裸的指令，沒有任何可辨識的身分。在幾行的規模下，這差異微不足道；到了數百萬、數十億行，這就是「能被人掌握」與「無法被人掌握」之間的差別。他主張，可讀性與可測試性向來都只是這個更深層屬性的代理指標：系統具有可理解的結構。

修改風險會非線性疊加，而兩種風險都源自理解

每一次對系統的改動都帶來兩類風險，Kanat‑Alexander 說兩者都源自理解出了問題。第一類是改動本身引入了問題——而「問題」比「bug」更廣：專案比預期拖得更久、對使用者行為錯誤，或預算超支。第二類是改動讓未來的改動更難，提高了未來出問題的機率。第一類源於理解系統的困難；第二類源於讓系統變得更難理解。

他聲稱，他讀過的每一份事後檢討（post‑mortem）都能歸結到這兩個因子——生產環境設定太難理解、有人把東西搞得無法理解、湧現出來、根本無法理解的特性。

關鍵的動態在於：第二類風險會餵養第一類，形成一個非線性疊加的惡性迴圈。理解的難度不會隨系統規模線性成長，而是隨時間複利累積。每個系統終究會走向一種狀態：每一次修改都伴隨某種問題；有些甚至走到完全無法修改的地步——他舉例，1 億到 5 億行的主機（mainframe）程式碼庫，其代價不只反映在程式碼上，也同樣反映在組織問題與時程上。

flowchart TD
    A["對系統的改動"] --> B["風險 1：引入問題"]
    A --> C["風險 2：讓未來改動更難"]
    D["理解系統的困難"] --> B
    C --> E["系統變得更難理解"]
    E --> D
    D --> F["風險非線性疊加成長"]
    F --> G["每次修改都伴隨問題"]
    G --> H["系統變得無法修改"]

他承認有個反駁：未來的模型或許有無限的複雜度處理能力；但他把這點擱置，認為對他的論證並不必要——因為他認為模型現在正在做的，是另一件更具影響力的事。

AI 即將讓拋棄型軟體普遍十萬倍

Kanat‑Alexander 的核心預測是：模型正在催生一類一直存在、但即將變得「比其他任何形式的軟體都普遍十萬倍」的軟體——拋棄型軟體。他定義它的方式，是「讓程式碼品質變得重要的每一個條件都不存在」：失敗的後果極小或不存在、人類依賴者很少且幾乎沒有依賴它的系統、幾乎不需變更管理、替換成本趨近於零（幾小時或幾天內就能換掉）、維護成本基本上為零。在那個世界裡，程式碼品質存在的目的——防止那些疊加風險——根本不存在，所以程式碼品質也就不重要。

他的例子很具體：不喜歡作業系統內建的計算機，自己寫一個；想幫小孩辦派對，就為那一場派對寫個派對規劃工具，用完就丟。

耐久型軟體——那種活上好幾年、被數千或數百萬人依賴、失敗後果可能造成業務災難、維護需求龐大——是多數工程師今天花最多時間的東西。他預期這類軟體會繼續存在，並仍將是世界上最重要的軟體。他的預測談的是「數量」，不是「重要性」：耐久型系統的絕對數量很可能會增加，因為 AI 工具讓打造耐久型軟體更容易；但數量最多的會是拋棄型系統。

四個變數，把任何系統放上拋棄性光譜

這場演講的操作核心，是一條從「完全拋棄型」到「完全耐久型」的量表，工程嚴謹的程度則依系統在量表上的位置按比例投入。四個因子決定一個系統落在哪裡：

| 因子 | 拋棄型（低） | 耐久型（高） |
|---|---|---|
| 失敗的後果 | 極小或不存在 | 可能造成業務災難 |
| 替換的成本 | 趨近於零——幾小時或幾天 | 非常高 |
| 依賴關係 | 使用者少、幾乎沒有依賴它的系統 | 數千或數百萬使用者與系統 |
| 維護的成本 | 幾乎免費或不重要 | 龐大 |

他補上一條實務者的經驗法則：寫程式寫得夠久的人都知道，寧可假設系統比預期更耐久——四個因子都比你以為的更高。這條光譜不是非黑即白；沿著光譜改變的，是投入工程嚴謹的力道有多少，無論是當下還是長期。

你可以把系統「工程化」成更拋棄型

Kanat‑Alexander 不只替系統分類，他主張你可以主動把系統往拋棄型那一端推——並稱這可能是一門新的軟體工程學科，有別於在耐久型系統裡提升嚴謹度。他點出四個槓桿：

• 更隔離的環境。 只部署到一個僅能存取你自己資料的環境——沒有客戶資料、沒有個人識別資訊。部署到那裡的東西全都是拋棄型的。
• 強制獨立。 禁止其他生產系統對該環境發出 inbound API 呼叫。
• 備援。 保留一套老舊、笨重、難用的備份系統。如果有人想在上面 vibe‑code 出更有效率的前端，就讓他們做——當那個 vibe‑code 出來的東西掛掉時，耐久型的備援會接住他們，「它一定會掛。對吧？沒關係。掛了也無所謂。」
• 限縮範圍。 給一個人的計算機、給一場派對的規劃工具。

他提醒，這裡還有很多可談，而「鼓勵拋棄性」是這個領域尚未充分探索的方向。

便宜的嚴謹勝過精準的預測，因為你一定會誤判光譜位置

演講中最可付諸行動的部分，是他對估計誤差的回應：你永遠不可能 100% 正確判斷一個系統落在光譜何處，所以槓桿最大的動作是壓低嚴謹的成本，而不是把分類做到完美。如果嚴謹很便宜，系統在量表上的位置就沒那麼要緊，改變主意——「我本來以為這是拋棄型的，現在它需要變成耐久型」——也會變得容易。他指出，這是一組有別於工程嚴謹本身的實務：關於如何降低嚴謹成本的實務，而這正是他職涯中投入極多心力的一個領域。

他點名五項，並說明每一項背後的道理：

• 標準化。 重點不在「老闆說了算」——而在於標準消除可能性。系統裡沒有 PHP，就沒有 PHP linter 要評估、沒有 PHP 實務要學、沒有 PHP 安全漏洞要補。同樣的邏輯適用於限縮前端與後端框架的數量，以及統一 RPC 協定。代理（agent）或許能為每一種變體生成對應工具，但那個成本你每一次都得付。
• 內嵌於工作流程的工具。 程式設計師不必選擇去執行、也不必理解它——它自己就會發生。它必須可靠（誤報少）且快速，讓人感覺免費。如果它免費又快速，連拋棄型軟體也能套用。
• 讓測試更容易。 不是問「我們怎麼把測試做得更好」，而是「我們怎麼做到讓沒有人需要去想怎麼把測試做得更好」——每個測試都快速且具確定性，無須任何人成為測試專家。這需要在測試基礎設施上重本投資。他身為測試負責人長年的夢想——每個團隊都發布自家服務的記憶體內假物件（in‑memory fake）——如今是 coding agent 能產出的東西，但前提是你選擇去做，並讓所有人都能用。
• 最大嚴格度。 把 lint 規則全面開到最嚴，絕不妥協。這能省下大量爭論。linter 有時會判錯，但只要誤報率低、後果不至於災難性，就無所謂——你換來的是免於未來問題堆積。百萬行的程式碼庫上事後補裝 linter，會產生十萬行的改動；一開始就做，便宜得多。

他說這題他能講十個小時，但只剩大約五分鐘，並把這份清單定位成一門大得多學科裡的幾個面向。

答案：拋棄型軟體不需要，耐久型軟體需要，而且不必昂貴

Kanat‑Alexander 收尾時，把「要看情況」換成一個明確的決定。程式碼品質重要嗎？拋棄型軟體，不重要。耐久型軟體，重要。至於第三個問題——它一定得昂貴嗎？——他的答案是不必，因為嚴謹的成本本身就是一個你可以壓低的工程變數。

「拋棄型軟體：不需要。耐久型軟體：需要。而我們還能回答第三個、甚至更有意思的問題：它一定得昂貴嗎？不必。」

值得留意的綜合觀察是：他論證的兩半其實往相反方向拉扯，而他並未完全調和。前半說嚴謹程度取決於系統在拋棄性量表上的位置；後半說最好的做法是把嚴謹做得便宜到量表不再要緊。如果後半大規模成功，那套四變數框架就從決策程式退位成過渡工具——在嚴謹仍然昂貴的現在有用，等到內嵌工作流程的工具、記憶體內假物件、最大嚴格度都成為預設，就沒那麼有用了。他「拋棄型軟體將以十萬比一壓倒耐久型軟體」的預測同樣沒有量化、沒有出處；這是一位職涯都投在耐久型那一端的人所做的方向性押注，讀者應把這個比例當成修辭，而非背後有模型支撐的預測。他留下的開放問題是：這門「為拋棄性而工程」的新學科，作為一套實務體系，除了他勾勒的四個槓桿之外，究竟長什麼樣子。