》中有過(guò)深入介紹。本文重點(diǎn)介紹一些降低代碼認(rèn)知負(fù)載的具體方法。

認(rèn)知負(fù)載和工作記憶

在探討具體的方法之前，首先要簡(jiǎn)述下，認(rèn)知負(fù)載是如何影響工作效率的。認(rèn)知負(fù)載理論中最重要的概念當(dāng)屬大腦的工作記憶（如下圖所示），這是用來(lái)處理各種運(yùn)算和邏輯推理的地方，有點(diǎn)類似計(jì)算機(jī)的內(nèi)存，用于臨時(shí)存儲(chǔ)一些概念。相比于長(zhǎng)時(shí)記憶，工作記憶空間極為有限，也是我們學(xué)習(xí)和工作的瓶頸所在。

一般而言，工作記憶能夠同時(shí)處理的概念數(shù)量是7±2（也就是5到9這個(gè)范圍），而且，這是很難改變的。所以，不管是小學(xué)生，還是科學(xué)家，心算2位數(shù)的乘法對(duì)他們而言，難度應(yīng)該是差不多的。另外，我還發(fā)現(xiàn)，如果幾個(gè)概念互相之間具有較強(qiáng)的關(guān)聯(lián)，會(huì)更容易被記住。因此，軟件開(kāi)發(fā)中，一個(gè)非常重要的原則，就是盡可能減少同一時(shí)刻大腦需要處理的概念數(shù)量，尤其是那些不相關(guān)概念的數(shù)量。這些概念包括但不限于：變量名、方法名、方法參數(shù)、返回值、條件判斷、類型信息等等。

另外，當(dāng)前要解決的問(wèn)題（比如這個(gè)方法的返回值為什么不符合預(yù)期）或者要實(shí)現(xiàn)的目標(biāo)（比如實(shí)現(xiàn)某個(gè)特定的業(yè)務(wù)功能），也都會(huì)占據(jù)工作記憶的空間，因此，留給其他概念的空間就更少了。

如果同一時(shí)刻要處理的概念太多，大腦就會(huì)超載，之前記住的一些概念就會(huì)被清除出去（有點(diǎn)類似于緩存的清除策略）。表現(xiàn)出來(lái)的現(xiàn)象就是，看代碼的時(shí)候，經(jīng)常看到后面忘了前面，需要倒回去再來(lái)一遍。甚至有時(shí)候需要反復(fù)看多遍，直到將這段邏輯載入長(zhǎng)期記憶（有點(diǎn)類似交換空間）?？上攵?，這種情況下，對(duì)效率的影響有多大。

軟件開(kāi)發(fā)中，在宏觀的架構(gòu)層面，可以使用關(guān)注點(diǎn)分離的思想，讓我們某個(gè)時(shí)刻只需要關(guān)注某個(gè)較小的模塊，同時(shí)盡可能減少與其他模塊的關(guān)聯(lián)；除此之外，在具體方法和代碼層面，也有一些值得注意的小技巧，能夠顯著提高代碼的可理解性和可維護(hù)性。

面向認(rèn)知負(fù)載的代碼調(diào)優(yōu)

起個(gè)好名字

好的名字，能夠清晰地表達(dá)概念的含義和作用，讓我們?cè)谧x代碼的時(shí)候不需要花費(fèi)額外的認(rèn)知能力去思考，從而降低了認(rèn)知負(fù)載。好的命名需要具備相關(guān)性、精確性和區(qū)分性。

相關(guān)性，指的是名字需要與其所表示的概念強(qiáng)相關(guān)，并且是在當(dāng)前的上下文中相關(guān)。對(duì)于表示業(yè)務(wù)概念的變量名和方法名，不要自己隨意命名，而是要盡量用專門(mén)的領(lǐng)域相關(guān)詞匯（有些研發(fā)同學(xué)對(duì)于自己不了解的領(lǐng)域概念，可能直接用機(jī)器翻譯出來(lái)的單詞，很容易失去相關(guān)性），對(duì)于技術(shù)相關(guān)的名字，最好能夠體現(xiàn)出背后的設(shè)計(jì)決策和模式(xxxFactory、xxxPipeline等)，那些不具備相關(guān)性的名字，很容易被逐出工作記憶，從而影響對(duì)代碼的理解。

精確性，指的是名字所指的概念和范疇最小化，沒(méi)有隱藏含義，不需要二次思考。我曾經(jīng)在某家公司負(fù)責(zé)交易系統(tǒng)，我們上游的促銷(xiāo)系統(tǒng)中，有個(gè)用來(lái)表示優(yōu)惠活動(dòng)適用對(duì)象（比如，是針對(duì)商品還是運(yùn)費(fèi)）的字段，叫bizType，讓人云里霧里，不知道其前綴biz所指為何物。在業(yè)務(wù)系統(tǒng)中，凡事皆可叫biz，加不加這個(gè)前綴，幾乎沒(méi)有區(qū)別，因此，這個(gè)名字的含義太寬泛了，應(yīng)該縮小范疇（比如改成targetType，就是一個(gè)更好的選擇）。太寬泛的命名，需要額外的思考，而額外的思考也會(huì)占據(jù)寶貴的工作記憶，大大降低效率。

區(qū)分性，指的是多個(gè)名字之間不能引起混淆，尤其當(dāng)它們同時(shí)出現(xiàn)的時(shí)候。還拿上面促銷(xiāo)系統(tǒng)舉例，就在bizType所在的同一個(gè)類中，還有一個(gè)字段叫promotionType，表示優(yōu)惠的計(jì)算方式（比如，是打折還是直減等），這兩個(gè)字段名的區(qū)分性就不好。還有個(gè)更加極端的例子，在我們交易系統(tǒng)中，用來(lái)表示商品優(yōu)惠金額和優(yōu)惠后的價(jià)格這兩個(gè)概念的字段，分別叫skuPromotionAmout和skuAmountPromotion，是不是這么對(duì)應(yīng)的可能我記錯(cuò)了，因?yàn)楫?dāng)時(shí)我就記不住。這樣的命名，不僅需要額外的思考，還會(huì)把名字與之接近的概念一股腦兒全引入工作記憶，讓大腦不堪重負(fù)。

延遲加載概念

變量聲明或定義，應(yīng)該盡可能靠近它被使用到的地方，這樣既可以推遲概念被加載到工作記憶中的時(shí)機(jī)，也能夠減少同一時(shí)刻駐留在工作記憶中的概念數(shù)量，相當(dāng)于給大腦減壓。另外變量定義和使用放在一起，也能夠讓這兩處代碼形成一個(gè)完整的概念，從而進(jìn)一步降低認(rèn)知負(fù)載。其實(shí)對(duì)于計(jì)算機(jī)內(nèi)存來(lái)說(shuō)，也是類似，推遲定義變量的時(shí)機(jī)，也是一種GC友好的編碼方式。最糟糕的定義變量的方式，莫過(guò)于在函數(shù)或方法最開(kāi)始的地方，一股腦兒把需要用到的變量全部定義或聲明出來(lái)，這種方式，一上來(lái)就把我們的工作記憶塞滿，等到讀到使用變量的地方，很有可能已經(jīng)忘記了變量含義，又得回過(guò)頭去溫習(xí)，效率非常低下?？匆粋€(gè)假想的例子，以下兩種寫(xiě)法，運(yùn)行結(jié)果完全相同，但是認(rèn)知負(fù)載差異巨大：

上圖左邊的寫(xiě)法，大腦里面同一時(shí)刻需要處理的概念數(shù)量最大可以達(dá)到10個(gè)（記住入?yún)⒑瓦@個(gè)方法的目的包含在內(nèi)）并且定義的地方和使用的地方相隔較遠(yuǎn)，這意味著我們需要保持這種高強(qiáng)度的認(rèn)知壓力較長(zhǎng)時(shí)間；而右邊的寫(xiě)法，同一時(shí)刻需要處理的概念數(shù)量不超過(guò)5個(gè)，且需要時(shí)才加載進(jìn)工作記憶，讀起來(lái)就非常輕松。

如果業(yè)務(wù)邏輯確實(shí)比較復(fù)雜，必須要定義很多變量，還是有辦法可以降低認(rèn)知負(fù)載的，那就是把邏輯上相似或者互相關(guān)聯(lián)的變量歸為一組，放在一起，用空行隔開(kāi)，以突出分組的用意。這樣安排，是利用了鄰近性法則，使得大腦自動(dòng)把相似的物體歸為一類，減少需要記住的概念數(shù)量，降低認(rèn)知負(fù)載。

提前回收概念

很多方法在執(zhí)行處理邏輯之前，都要先進(jìn)行很多校驗(yàn)，比如判斷入?yún)⑹欠窈戏?，判斷?quán)限是否足夠，判斷當(dāng)前資源的狀態(tài)等等。一種寫(xiě)法是使用多層if嵌套——所有條件都滿足后，在最內(nèi)層的if語(yǔ)句塊中寫(xiě)處理相關(guān)的代碼，這就會(huì)形成“箭頭型”代碼。

這種寫(xiě)法的問(wèn)題在于，每一層if判斷都會(huì)形成認(rèn)知負(fù)擔(dān)，并且這個(gè)負(fù)擔(dān)需要一直帶下去 ——你得時(shí)刻記住，在哪些條件下才執(zhí)行到當(dāng)前位置。如果一些if條件本身很復(fù)雜，那情況會(huì)更糟，你甚至還沒(méi)讀到真正執(zhí)行處理邏輯的位置，就精疲力盡了。

更好的方式，是使用“衛(wèi)語(yǔ)句”，把嵌套的if語(yǔ)句寫(xiě)成多個(gè)平級(jí)的形式，每當(dāng)一個(gè)if條件不滿足的時(shí)候，就直接返回（或報(bào)異常）。這樣做的好處，是每看完一個(gè)if語(yǔ)句塊，你就可以安全地在思想上放下它（從工作記憶中移除），相當(dāng)于做了一次“垃圾回收”，然后，就可以繼續(xù)輕裝上陣，更好地理解后面的邏輯。這樣寫(xiě)出來(lái)的代碼，雖然方法可能會(huì)長(zhǎng)一些，但是理解起來(lái)更輕松。

上圖中這個(gè)示例，我們假設(shè)if條件很簡(jiǎn)單，都只有一個(gè)變量，那么，左邊的方式，當(dāng)你看到內(nèi)層執(zhí)行處理的代碼時(shí)，工作記憶里面此時(shí)需要記住的概念數(shù)量是6(算上方法名和參數(shù)名)，而右邊的方式，工作記憶中同一時(shí)刻的概念數(shù)量不超過(guò)3。實(shí)際中，差異可能會(huì)更大。

可能很多人都知道“箭頭型”代碼的問(wèn)題及其優(yōu)化方法，不過(guò)，只有深刻理解了背后認(rèn)知方面的原理，才能夠靈活運(yùn)用這個(gè)思想，提前給讀代碼的人減負(fù)。比如，最小化變量作用域就是該思想的另一個(gè)很好的實(shí)踐，我們應(yīng)該盡可能把變量定義在使用它的最內(nèi)層的塊中（比如if、for、try塊等）中， 另外，在很多語(yǔ)言中，甚至可以單獨(dú)使用{}來(lái)顯式定義一個(gè)塊，塊中的變量只在塊中有效，塊結(jié)束后，其中的變量也就不可見(jiàn)了。

上圖示例代碼中使用了顯式的塊作用域，塊結(jié)束后，我們大可以放心地“忘掉”其內(nèi)部出現(xiàn)過(guò)的變量a和b，因?yàn)槲覀冎篮竺嬖僖膊粫?huì)用到了，這樣就可以提前給大腦減負(fù)。（熟悉垃圾回收機(jī)制的同學(xué)可能也知道，這種寫(xiě)法還能夠提示垃圾回收器，塊內(nèi)部的變量可以被提前回收掉了。）

最小化方法傳參

上文提到過(guò)，讀代碼時(shí)，方法調(diào)用的參數(shù)也是需要載入工作記憶中的概念，因此，寫(xiě)代碼時(shí)，如何傳參，也很有講究。

減少顯式概念傳遞

方法參數(shù)是概念，方法傳參本質(zhì)上就是概念的傳遞，而概念是需要消耗認(rèn)知資源的， 所以，應(yīng)該盡可能減少方法參數(shù)。那些有著10個(gè)以上參數(shù)的方法，光是理解方法簽名，就夠我們喝一壺的了。因?yàn)殡y以理解，也就難以使用，還有可能被誤用，尤其是在多個(gè)參數(shù)類型相同的情況下。

首先要避免的就是傳遞冗余參數(shù)。如果某個(gè)參數(shù)能夠根據(jù)其他參數(shù)算出來(lái)（或者進(jìn)行額外查詢就能獲得），就是冗余的，應(yīng)該考慮去掉。（有時(shí)候，出于性能方面的考慮，可以做些妥協(xié)）。

在確實(shí)需要傳遞很多參數(shù)的業(yè)務(wù)場(chǎng)景下（通常是創(chuàng)建一些業(yè)務(wù)資源，比如用戶、商品、訂單等），應(yīng)該把多個(gè)參數(shù)封裝成對(duì)象（比如CreateOrderRequest）進(jìn)行傳遞。很多時(shí)候，我們其實(shí)是在瀏覽代碼，不需要搞清楚遇到的每個(gè)方法的細(xì)節(jié)，而僅僅是為了找到我們真正感興趣的部分，所以這種封裝參數(shù)的做法，能夠顯著地降低認(rèn)知負(fù)載。

如果是對(duì)象的構(gòu)造方法需要大量參數(shù)，可以考慮使用Builder模式，通過(guò)鏈?zhǔn)劫x值，一次賦值一個(gè)字段，既增加了可讀性，也能夠避免出錯(cuò)。

減少隱式概念傳遞

對(duì)象參數(shù)，如果被不合理地使用，反而會(huì)增加認(rèn)知負(fù)載。對(duì)象參數(shù)中的字段，是隱藏在對(duì)象后面的概念，如果我們點(diǎn)開(kāi)這個(gè)對(duì)象，想看看方法調(diào)用的細(xì)節(jié)，這些概念也會(huì)被加載到工作記憶。有時(shí)候，某個(gè)方法實(shí)際只用到了入?yún)?duì)象中很少的幾個(gè)字段，卻要求傳入整個(gè)對(duì)象，通常，這都是不合理的。

舉個(gè)例子，假設(shè)在創(chuàng)建訂單的場(chǎng)景中，需要調(diào)用一個(gè)計(jì)算運(yùn)費(fèi)的方法，該方法只需要用到用戶地址id、商品總件數(shù)和商品總重量這三個(gè)字段，那么傳遞包含大量其他字段的CreateOrderRequest對(duì)象就不太合適，因?yàn)楣饪磪?shù)不看方法實(shí)現(xiàn)的話，你不知道計(jì)算運(yùn)費(fèi)需要用到哪些信息，很多原本不需要的字段，成了干擾和負(fù)擔(dān)。另外，這種簡(jiǎn)單粗暴的傳參方式，也會(huì)導(dǎo)致方法難以使用和測(cè)試——在拿不到CreateOrderRequest對(duì)象的場(chǎng)景下，直接實(shí)例化一個(gè)新對(duì)象，僅僅賦值需要的那幾個(gè)字段后傳下去，這既不方便，也埋下了坑。

避免不必要的函數(shù)調(diào)用和過(guò)深的嵌套

函數(shù)的最佳代碼行數(shù)是多少，或者不應(yīng)該超過(guò)多少行，這兩個(gè)問(wèn)題一直沒(méi)有確切的答案。真相是，這本身是一個(gè)偽命題，真正的問(wèn)題是，函數(shù)如何實(shí)現(xiàn)，認(rèn)知負(fù)載最小。上文我們說(shuō)過(guò)，有時(shí)候，長(zhǎng)一些的函數(shù)，反而比短一些的函數(shù)更容易理解，只要它同時(shí)塞進(jìn)我們工作記憶中的概念更少。

函數(shù)調(diào)用也是有開(kāi)銷(xiāo)的。對(duì)于計(jì)算機(jī)來(lái)說(shuō)，得保留調(diào)用點(diǎn)的上下文，同時(shí)為被調(diào)函數(shù)創(chuàng)建新的上下文，函數(shù)返回后得恢復(fù)之前保留的上下文；對(duì)于人腦來(lái)說(shuō)，也是類似的過(guò)程，進(jìn)入新的函數(shù)后，在我們的工作記憶中也會(huì)發(fā)生上下文切換。如果被調(diào)用函數(shù)做了很多的事情，封裝了足夠的復(fù)雜性，調(diào)用這個(gè)函數(shù)就是值得的，因?yàn)榭傮w而言，認(rèn)知負(fù)載被降低了（所有概念不至于全部在一個(gè)函數(shù)里面，一股腦兒塞進(jìn)工作記憶）；相反，如果，被調(diào)函數(shù)僅僅只做了很簡(jiǎn)單的事情，或者相對(duì)實(shí)現(xiàn)代碼來(lái)說(shuō)，參數(shù)非常多，就有點(diǎn)得不償失了。

如果實(shí)現(xiàn)邏輯不是很復(fù)雜，不斷地調(diào)用嵌套的函數(shù)，一次只做一點(diǎn)事情，反而給讀代碼的人增加障礙，就像話不一次性說(shuō)完，不斷賣(mài)關(guān)子一樣。

另外，有些時(shí)候，我們看代碼，就是想搞清楚某個(gè)細(xì)節(jié)的來(lái)龍去脈，或者查清某個(gè)bug的根本原因，因此，需要不斷跟到函數(shù)調(diào)用的深處。就像過(guò)深的調(diào)用堆棧會(huì)讓程序報(bào)StackOverflow異常一樣，過(guò)深的函數(shù)調(diào)用，也會(huì)讓大腦認(rèn)知超載。

總結(jié)

限于篇幅，本文并沒(méi)有面面俱到地覆蓋所有我能想到的點(diǎn)，另外，寫(xiě)得太多，可能也會(huì)讓大家認(rèn)知超載，反而得不償失。重要的是，希望越來(lái)越多的程序員們，能有這個(gè)意識(shí)，不僅要面向計(jì)算機(jī)優(yōu)化自己的代碼，更重要的，是面向我們的大腦優(yōu)化代碼，讓代碼更容易理解一些，造福自己，也造福他人。

更多精彩文章，歡迎關(guān)注微信公眾號(hào)：技術(shù)凌云