0 1
50億美元的豪賭，寫出軟體工程的聖經
有一本書，廣為人知，經常被引用，偶爾被閱讀，但很少被遵循。
這本書是50多年前出版的，被譽為軟體工程「聖經」的《人月神話》。
布魯克斯在寫這本書之前，是IBM System/360 作業系統專案的開發經理。
System/360則是IBM的一場豪賭，總共投入50億美元（相當於今天的400億美元），可以說是一把梭哈。
如果這次押注失敗，IBM就得當場關門。
System/360的目標現在聽起來有點「可笑」：用同一套架構覆蓋從小型到大型的全部機器，所有機器都運行同一套軟體，建造同一套作業系統OS/360。
計畫從1961年開始，IBM整體動員了數萬名員工參與設計、製造、測試、生產與支援工作。
在一個連「軟體工程」概念都存在的年代，2,000多位軟體工程師，竟然開發了數百萬行程式碼。
不出意料，專案出現了嚴重的混亂，複雜度被嚴重低估，需求不斷變化，專案不斷延長。
布魯克斯後來形像地描述：軟體開發就像“焦油坑”，表面看似平穩，但動物一旦掉進去，越掙扎陷得越深，很難脫身。
這些經驗直接催生了後來著名的布魯克斯定律：
「向已經延誤的軟體專案增加人手，只會使專案更加延誤。」— Brooks’s Law
專案結束以後，布魯克斯意識到：軟體開發的失敗不是因為程式設計師不努力，真正的問題在於管理方式、溝通結構和複雜系統設計，於是他把IBM的踩坑經歷整理成了一本書：《人月神話》。
02
50年前的預言，撞上今日的AI編程
《人月神話》和現在火熱的AI程式設計有什麼關係呢？
它提出了兩個軟體開發的核心概念：本質複雜性和偶然複雜性。
1.本質複雜性：
這是和問題本身固有性質相關的複雜性，例如作業系統核心設計，需要管理內存，進程調度，設備驅動，各個領域會互相糾纏，互相影響。再例如航空航太控制系統，涉及極高的即時性，多感測器融合，安全約束等。
這種複雜性無法透過更好的工具或方法完全消除，它決定了軟體系統本身的「難度下限」。
2.偶然複雜性
它來自工具、方法或環境本身的複雜性，不是問題本身固有的。這種複雜性可以透過更好的工具、語言、框架或方法來減輕甚至消除。
例如早期大家都用組譯語言，寫程式需要手動管理暫存器、記憶體地址，軟體開發極為複雜，效率極低，但是Fortran, COBOL等的高階程式語言以後，效率一下子就飆升了。
用一句話來總結：
本質複雜性= 你必須要解決的問題
偶然複雜性= 你可以透過更好方法消除的麻煩。
很明顯， AI程式設計可以極大程度地消除“偶然複雜性”，現在它已經接管了大量繁瑣、重複但必要的工作，無論是理解程式碼庫，生成程式碼，還是測試、調試，都乾得相當不錯。
那麼問題來了，大模型能解決本質複雜性嗎？
那些最聰明的頭腦都搞不定，更別說現在的AI編程了，最近很火的AI寫瀏覽器/編譯器頻繁翻車很好地說明了這一點。
即使是最先進的AI，也不能讓問題本身變得簡單，離開了人的指導，在複雜的領域，AI程式設計也無所適從。
但是，AI能把人工處理本質複雜性的負擔降低，讓人更專注於本質決策。
例如，我要設計“設計分散式資料庫一致性協定”，AI可以產生示意圖、提供多種演算法實作、檢查潛在死鎖。設計仍需人決定，但可以少做很多低階推演和文件工作。
再例如我想重構一個大型遺留系統，由於舊系統業務非常複雜，部門之間還有依賴，資料遷移有風險，這些都是本質複雜性，用工具無法消除，但是AI可以自動梳理程式碼依賴圖，標記風險模組，自動產生迴歸測試。
0 3
複雜性不會消失，只會轉移
AI程式設計很強，但是它很可能會走上前輩們（高級程式語言，各種輔助工具）走過的同一條道路：
工具變強->偶然複雜性被削弱->軟體系統變得更大更複雜->本質複雜性更強
原因很簡單，當實現成本下降，人類不會停在原來的複雜度水平，產品經理會加功能，市場會要求差異化，客戶會定制需求，公司會做更多整合……
這直接推動功能數量，模組數量，互動路徑，狀態空間飛速上升，本質複雜性迅速增加。
幾十年前，一個程式設計師用彙編只能寫簡單的軟體，如今用Java、Python可以輕鬆寫出複雜的系統。
用匯編寫的OS/360，百萬行就是巔峰，現在Linux 核心有3000萬行程式碼，Windows 10有5000萬行程式碼，Chrome，3000萬行程式碼，而現代的雲端系統更恐怖，是數億行程式碼等級的程式碼宇宙！
現在AI程式來了，程式碼的成本變得近乎為零，天知道未來的軟體會長成什麼樣子。
