Andrej Karpathy 推薦的關于軟件開發文章"Cognitive load is what matters"，非常值得一讀

“認知負荷才是關鍵。這或許是最真實卻最少被實踐的觀點?！?-Andrej Karpathy

在軟件開發的世界里，充斥著各種流行語和最佳實踐。然而，有一個問題常常被忽視：認知負擔。這并不是一個抽象的理論，而是開發者每天都在面對的現實困境。代碼越難理解，開發者的時間和精力就浪費得越多，而這些成本最終都會轉化為團隊的生產力損失

什么是認知負擔？

簡單來說，認知負擔就是開發者在完成任務時需要思考的量。當你閱讀代碼時，你的腦子里需要同時裝下變量的值、邏輯流程、函數調用順序等信息。而問題在于，人類的工作記憶容量有限，通常只能同時處理 4 個左右的信息塊。一旦超過這個閾值，理解能力就會直線下降。

想象一下，你接手了一個完全陌生的項目，前開發者使用了各種“高端”架構、炫酷的庫和流行技術。結果呢？你還沒開始寫代碼，認知負擔已經爆表了

認知負擔的兩種類型

1. 內在認知負擔：由任務本身的復雜性引起，無法避免。例如解決算法問題或實現復雜業務邏輯

2. 外在認知負擔：由信息的呈現方式引起，與任務無直接關系，比如代碼風格怪異、命名不清晰等。這種負擔是可以大幅減少的，也是我們應該重點優化的方向

實戰案例：如何降低外在認知負擔？

1. 簡化復雜條件語句

if (val > someConstant && (condition2 || condition3) && (condition4 && !condition5)) {
    // 什么鬼？讀到這里已經頭暈了
}

改進后：

isValid = val > someConstant;
isAllowed = condition2 || condition3;
isSecure = condition4 && !condition5;

if (isValid && isAllowed && isSecure) {
    // 條件清晰，變量名一目了然
}

通過引入中間變量，我們不需要再死記硬背每個條件的細節，認知負擔瞬間下降

2. 繼承噩夢

AdminController -> UserController -> GuestController -> BaseController

修改某個功能需要從 BaseController 一路查到 AdminController，甚至還要考慮 SuperuserController 的影響。認知負擔？爆表！

解決方案： 優先使用組合而非繼承。組合模式雖然看起來不夠“優雅”，但卻能極大降低理解代碼的成本。

3. 太多小方法，類，模塊

過多的小方法、小類或小模塊，會讓項目變得支離破碎。要理解一個淺模塊的作用，你往往需要先搞清楚與之相關的所有模塊，簡直是噩夢

解決方案：深模塊，簡單接口，復雜實現

例如 UNIX 的 I/O 接口，雖然底層實現有幾十萬行代碼，但接口只有 5 個簡單的調用：

open, read, write, lseek, close

這樣的設計隱藏了復雜性，讓開發者更容易上手

減少選擇，限制語言特性

編程語言的新特性總是令人興奮，但特性過多反而會增加認知負擔。你不僅需要理解復雜的代碼，還要猜測作者為什么選擇某種特性

解決方案：限制選擇，保持特性獨立性

正如 Rob Pike 所言，語言特性可以有，但它們必須是正交的，互不干擾。

架構設計：簡單才是硬道理

層次化架構（Layered Architecture）本應隱藏復雜性，但實際上卻增加了跳轉和追蹤的負擔。每一層的抽象都需要占據開發者的工作記憶，這種設計往往得不償失。

解決方案：避免過度抽象，遵循實際需求

不要為了優雅的架構而添加無意義的層，抽象層應該為功能擴展服務，而非制造額外負擔

結語：認知負擔，開發者的隱形成本

代碼的復雜性不應該成為團隊的負擔。無論是通過清晰的命名、簡化的邏輯，還是合理的架構設計，我們都應該盡量減少外在認知負擔

記?。航档驼J知負擔，不僅是對自己負責，也是對團隊負責