🔧 阿川の電商水電行
複雜性為何會破綻？
從計算量與認知負荷的角度探討，軟體的極限。這是一個與過度學習有關的主題，特別是在資訊過載的時代。
知道我們的大腦在何時會飽和，以及何時理解會追不上..這個結構不僅是工程學的基礎，也可能是重新技能培訓的基石。
引言
在軟體開發中，有一個常識是「複雜性會產生問題」。
- 為何變得複雜後會出現破綻
- 從何時開始可以稱之為複雜
- 何時人類的理解會跟不上
- 技術負債為何會突然膨脹到「無法處理」的階段
我們試著以三個角度來解析軟體的複雜性：
重點在於，不是處理「複雜的程式碼」，而是處理「複雜性本身的本質」。
1. 複雜性是人類無法承受的「計算量爆炸」現象
軟體的複雜性常常被描述為計算量的爆炸。
O(N)→ 仍可追蹤O(N²)→ 事情變得模糊O(2^N)→ 無法理解
但這在人的大腦中一樣會發生。
人類的工作記憶被認為只能保持 7±2 個單位^1。這是心理學的經典研究，但對工程師來說，這意味著「認知的計算量限制」。
※後續的研究認為，實際容量約為 4±1 個單位（如 Cowan 2001）
換句話說，當程式碼設計超過O(理解)的瞬間，人類便會崩潰。
人類的工作記憶被認為「只能同時處理 5～9 個資訊單元」[^2]，複雜的設計很快就會觸及這一上限。
2. "設計的計算量"不是由程式碼行數決定，而是由「關係數量」決定
複雜性不是由程式碼量來決定的，而是由關係（依賴、約束、流程）的數量來決定。
例如：
- A 知道 B
- B 引用 C
- C 非同步更新 A
為了理解這些，人類必須追蹤 A-B-C-A 的閉環。
這對大腦就如同深度優先搜尋（DFS）的負擔。
關係越多，理解的計算量呈指數倍增加。
程式碼是線性增長的，但理解成本是指數增長的。
因此，設計會突然崩潰。崩潰的過程不是漸進的，而是當超過某個閾值時，瞬間崩潰。就如同超過臨界點的化學反應一樣。
依賴關係數量的增加，將使得「依賴管理成本」在開發速度之前就會爆炸^3。
3. 認知負荷是「看不見的」技術負債
複雜性之所以會破綻，並非技術問題，而是因為超過人類可處理的信息量的極限。
高認知負荷的設計通常有以下徵兆：
- 一次讀完仍然無法理解
- 規範與程式碼之間的對應不明
- "這裡變更會影響哪裡？" 無法看見
- 評論呈現疲乏
- 錯誤以「面」而非「點」的形式出現
這些都是「計算量過多」「容量超限」的症狀。
技術負債應該被視為：
"認知負荷如同利息般累積的現象"
技術負債不僅僅是「延遲修正」，而是堆積在開發者腦中的認知負荷本身^4。
4. 架構的本質是「控制計算量」
設計不是畫出漂亮的圖。
本質只有一個：
"將理解所需的計算量逼近
O(1)"
為此架構才存在。
- 分層隔開 → 保持認知對象的穩定
- 限定責任 → 縮短計算路徑
- 設置邊界 → 切斷關係
- 設計API → 抽象化認知
美觀的設計是有原因的，不是因為它好看，
而是為了最小化大腦的負擔。
5. 「複雜性的破綻邊界」依賴於"團隊"，而非個別個體
認知負荷因人而異。
- 初學者很快就會達到
O(爆炸) - 老手可以承受到
O(某種程度) - 設計者能承受
O(能抽象噪聲)
換句話說，複雜性的破綻邊界是團隊特有的，而不能用一般化的"正確性"來評估。
技術可以移植，但認知的極限無法移植。
在某個專案中成功的設計，可能在另一個團隊中卻會崩潰，原因就在於此。
6. 在實務中防止「複雜性爆炸」的方法
總結在實務中有效的複雜性控制原則。
① 減少關係性（切斷依賴）
- 整理由事件驅動引發的依賴
- 禁止雙向引用
- 設計一個"A 不認識 B 的世界"
簡短範例
僅保留 UI → UseCase → Repository，不直接讓 UI 呼叫 Repository。
② 使閱讀接近 O(1)
- 程式碼必須能在"第一次看到"就理解
- 初次無法理解的設計太過複雜
簡短範例
「這個函式是做什麼的？」最好在一個畫面內講清楚。
③ 用「結構」而非文檔來説明
- 如果設計需要文檔來補強，那麼它已經不再是
O(1)的設計了
簡短範例
將文件和責任對應，讓「這裡是〇〇層」的說明不再需要。
④ 在評審中觀測"認知負荷"
- 評審的摩耗是結構的疲勞
簡短範例
如果 PR 中不斷出現「這裡難以理解」的評論，應懷疑設計的結構疲勞。
⑤ 了解團隊的認知極限
- 不是老手的極限
- 應在團隊的最低標準下進行設計
簡短範例
以「新人也能追蹤的結構」作為基準，排除依賴於老手的隱性知識。
結語
複雜性的問題可以理論上解釋，但在實務中幾乎很少被提及。但是，軟體的崩潰總是發生在「人類無法再理解的時候」。
軟體的極限並不是計算資源，而是人類的認知資源。
當這個觀點被確立後，設計、評審和架構的見解會大不相同。
重要的不是避免複雜性，而是尋找能夠與複雜性共存的方式。
George A. Miller, The Magical Number Seven, Plus or Minus Two（來自 Britannica 的解說）
https://www.britannica.com/topic/The-Magical-Number-Seven-Plus-or-Minus-Two-Some-Limits-on-Our-Capacity-for-Processing-Information
[^2]: “工作記憶通常能同時處理 5－9 件資訊。”
Cogntive Load Theory 簡介，威斯康星醫學院
https://www.mcw.edu/-/media/MCW/Education/Academic-Affairs/OEI/Faculty-Quick-Guides/Cognitive-Load-Theory.pdf
慢速產品開發？依賴是原因
https://blog.zeroblockers.com/p/slow-product-development-dependencies-are-the-cause
認知負荷 – 無意識的敏捷
https://unconsciousagile.com/2024/01/28/cognitive-load.html
原文出處：https://qiita.com/Sakai_path/items/415dc71f3463c0c4471b
神文！
軟體的極限並不是計算資源，而是人類的認知資源。
很有啟發性！