北京
二十年前，Herb Sutter寫下了著名的《免費午餐結束了》。那份午餐是硬件：你只需編寫普通的單線程代碼，來年更快的芯片就能自動讓它跑得更快，完全免費。后來主頻停止增長，代價變成了明確指令——想要更高性能，必須親手并行化你的代碼。
現在，第二份免費午餐也走到了盡頭。它運行的時間遠比第一次要長，其信念簡單如初：靠增加開發者就能規模化軟件開發。它終結的方式與Sutter描述的情形如出一轍，背后的結構性根源一致，甚至連最后遞過來的賬單都幾乎一字不差。
把問題拆到最底，只有一個詞：規模化。不是軟件運行時的彈性擴展，而是構建軟件這項活動本身的規模化。你期望產出隨團隊規模增長，但現實并非如此。Fred Brooks在五十年前就給這一失敗命了名：向已延期的項目加人，只會讓它更延期。根源從來不是偷懶，而是溝通。把n個人扔進一個糾纏復雜的任務里，需要兩兩協調的對子數量會按n(n-1)/2增長。所以當團隊規模越過小型團隊的界限后，新增的勞動力大半耗在了保持所有人步調一致上，而非產出實際成果。
今天再問答案，條件反射式的回復已不再是“加人”，而是“加AI”。這里必須直言不諱：AI被兜售為那個最終能讓軟件開發規模化的事物，而它做不到。AI攻擊的是單個工人的成本。每個代理寫代碼更快、更便宜，但它完全無法撼動那個把并行協作人數死死封頂的耦合度。將一群代理投向一個糾纏的系統，你只會得到Brooks定律的放大版：合并沖突爆發，代理們對同一個設計持有互不一致的想象，平方級的協調曲面完整保留，甚至不再有過去那種用來軟化它的隱性人類默契。根本性的限制因素紋絲未動。
兩種看似輕松的答案歸于同一種失敗，而指出這一點正是后續一切論述的核心。軟件開發之所以無法規模化，是因為工作本身是強耦合的。在這一點改變之前，添置更多工人，無論是人還是合成體，收獲只會越來越小。
每一場真正想要實現開發規模化的嚴肅嘗試，其底層邏輯都是對工作進行切分，讓不同部分可以齊頭并進。微服務把系統切成服務，分給不同團隊。垂直切片按功能切分。領域驅動設計按限界上下文切。離岸外包則是將整塊領域交由另一群人負責。切割依據各有不同，但策略路數高度一致。
這些嘗試也往往在同一個地方停下腳步，這一點極具啟發性。它們依據了錯誤的鍵值來劃分。按名詞切，按領域對象切，按白板上畫出的服務邊界切，最終得到的各個部分仍然需要同步變更。因為真正迫使代碼發生變動的東西，并非你所沿之切割的那條線。于是各部分在新的邊界兩側依然耦合，你試圖消除的協調成本重新浮現，化為跨服務的服務編排、共享數據庫以及無休止的對齊會議。切分的本意是解耦，但如果沿著變動理由之外的那條線去切，得到的不過是分散在不同容器里的強耦合。系統結構上分開了，認知負載卻一克都沒少。
所以，這份持續了幾十年的“堆人就能堆出產出”的信念，正是軟件行業的第二份免費午餐。和當年的單核性能提升一樣，當這頓飯吃干抹凈，擺在眼前的不會是另一個自動加速的臺階，而是一紙必須重新學習如何構建系統的艱難賬單。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
