編寫良好的代碼：如何減少代碼的認(rèn)知負(fù)荷

長沙7喜 2018-09-08

展開全文

Bug 少，性能好，容易修改。好的代碼影響深遠(yuǎn)，而且它可能是產(chǎn)生 10 倍工作效率的開發(fā)者的主要原因。盡管好代碼十分重要，但開發(fā)新手卻不得要領(lǐng)。關(guān)于這一主題的技巧多而冗雜，讓新手們?nèi)绾斡浀米?？“Code Complete(《代碼大全》)” 是這個主題的經(jīng)典，但內(nèi)容多達(dá) 960 頁！

我認(rèn)為應(yīng)該建立起良好的心態(tài)，這樣，不管你用什么語言或者庫，都會自然而然的寫出高質(zhì)量的代碼。這里我主要談到 5 個相關(guān)的概念。記住它們，輕松寫出寫出好代碼。

避免特立獨行

當(dāng)你讀到一些文章中的新技巧時，如醍醐灌頂，一定會想要寫點看起來很聰明的代碼，讓同行們眼前一亮。

問題是人們只是想修完 BUG，然后繼續(xù)處理其它事情。那些聰明的技巧常常只會成為一種消遣。我曾經(jīng)在“將神經(jīng)科學(xué)應(yīng)用于軟件開發(fā)”中談到，當(dāng)人們被迫花心思來理解你的某段代碼時，它們的“精神堆?！睍杆偬顫M，因而難以理解其中深意。

[譯者注：圖片中的注釋內(nèi)容：這在 C 語言中用于避免誤寫成 variable = null。最近它造成不少人困惑，但似乎并沒帶來多大好處]

不要在工作中使用太多可能需要額外解釋的個性化方式。

不要用“你的方式”來編寫代碼，只需要按照標(biāo)準(zhǔn)（的代碼規(guī)范）來編寫就好。再次強(qiáng)調(diào)，要寫讓人讀得明白，看得下去的代碼，讓人家能夠理解它。

分而治之

模塊化可以使復(fù)雜的代碼結(jié)構(gòu)變得清晰，除此之外還有很多方法可以達(dá)到同樣的目的，而無需創(chuàng)建更多函數(shù)。將長長的條件表達(dá)式保存為一到兩個變量就是個不錯的方法，可以避免調(diào)用函數(shù)的開銷。這些變量可以用在其它地方，甚至可用于組合更復(fù)雜的條件。

拆解問題的方法在于盡可能的讓每個部分保持集中，只影響局部狀態(tài)，不要混入不相關(guān)的問題，要避免副作用。編程語言和庫通常會帶來各自相應(yīng)的問題，避免這些問題可以讓你的代碼更專注于其表達(dá)的業(yè)務(wù)。單一責(zé)任原則就是通過集中代碼和局部化代碼帶來良好設(shè)計的例子。

[譯者注：圖中注釋內(nèi)容：這是不需要額外函數(shù)開銷的一種模塊化方法]

我喜歡利用變量來進(jìn)行邏輯劃分。

TDD（Test Driven Development，測試驅(qū)動開發(fā)）的成功實施表現(xiàn)出了它所帶來的好處，它迫使人們運用一些以前不受歡迎的準(zhǔn)則。無狀態(tài)的代碼曾經(jīng)被嫌棄又慢又沒必要（大部分老的 C/C++ 代碼中可以看到），然而現(xiàn)在每個人都在談?wù)摷兒瘮?shù)。就算你不采用 TDD，你也應(yīng)該學(xué)習(xí)它背后的原則。在新的模式下工作會讓你成為適應(yīng)性極強(qiáng)的開發(fā)者。

分離代碼并使其可分別處理

你寫代碼的時候面臨著什么樣的困難，你的計算機(jī)和工具也面臨著同樣的困難。代碼的復(fù)雜性，與需要進(jìn)行的預(yù)處理和需要處理的突發(fā)情況存在著或多或少的聯(lián)系。

現(xiàn)在暫時拋開那些額外的構(gòu)建工具所帶來的好處。它們需要你使用特定領(lǐng)域的語言，比如自定義模板，或者復(fù)雜的動態(tài)數(shù)據(jù)結(jié)構(gòu)，比如哈稀表。IDE 通常不善于處理這些東西，要找到相關(guān)的代碼段則更加困難。

盡量避免使用不能很好支持 IDE 的語言擴(kuò)展和庫。它們給你的生產(chǎn)力帶來的好處，遠(yuǎn)大于簡易配置和用簡潔語法保存擊鍵帶來的小便利。

[譯者注：圖中注釋內(nèi)容：使用神奇的字體串可能造成 IDE 不能正確識別你的代碼]

ServiceLocator 是與 IDE 整合不佳的一個設(shè)計樣例。

另一個保持 IDE“整合度”的相關(guān)方法是避免編寫特殊的代碼。多數(shù)語言都提供了編寫動態(tài)代碼的能力。如果濫用這些特性，比如特殊的字符串、特殊的數(shù)組索引和自定義模板語言特性等，會產(chǎn)生難以連接的代碼庫[譯者注：這里的連接應(yīng)該是指相互關(guān)聯(lián)的關(guān)系，連接最直接的影響是在使用 IDE 等工具進(jìn)行重構(gòu)的時候可以自動根據(jù)連接關(guān)系修改相關(guān)引用]。一般說來，那些只有你一個人才能看懂的特性會讓你摔跟頭的，因為如果 IDE 不能理解這些代碼，在你想進(jìn)行結(jié)構(gòu)調(diào)整的時候，IDE 就沒法幫你進(jìn)行重構(gòu)。

讓程序可讀

致力于可預(yù)測的架構(gòu)。這種架構(gòu)下你的隊友要進(jìn)行某項查找就會很容易，可以節(jié)約不少時間。一旦你為項目確定了一個整體的架構(gòu)，就一定要把主要元素放在顯眼的位置。使用 MVC？把模型、視圖和控制器放在他們自己的目錄下，不要放在三個深層次的目錄中，也不要放在幾個不同的地方。

我在前面談到了模塊化。也存在過度的模塊化，讓定位代碼這種事情變得艱難無比。IDE 可能會帶來一些幫助，但通常你往往會讓 IDE 忽略庫目錄，因為其中有很多不相關(guān)的代碼，或者它的索引需要人工處理一些問題，就會造成兩敗俱傷的局面。盡量使用較少的庫，選用那些盡可能多覆蓋你需求的庫。

庫和工具也可能成為新人的障礙。我最近使用 EcmaScript 7 (babel) 構(gòu)建了一個項目，后來我才意識到我們的初級開發(fā)人員一直因為想搞明白它而卡在那里，這對團(tuán)隊的生產(chǎn)力造成了巨大損失。我低估了這對一個新手所帶來的壓力。不要使用對當(dāng)前來說太難掌握的工具，等時機(jī)成熟再使用。

這是我寫的一個 makefile 中的真實代碼。新手不需掌握過多的新技術(shù)。

讓代碼易于理解

如果你已經(jīng)做到了這一點，那我們來解決更重要的問題——選擇好名字，這是軟件開發(fā)中的重要部分。構(gòu)建工具在這方面不能提供幫助，原因很簡單，計算機(jī)不會真正知道解決方案背后的邏輯。你得通過文檔來解釋代碼，而與主題相關(guān)，且符合上下文，體現(xiàn)變量和功能的名稱就能很好做到這一點。語義化的名稱甚至可以減少對文檔的需求。

在名稱中使用前綴對理解它們很有幫助。這在過去是一種流行的做法，我認(rèn)為對這種作法的誤用導(dǎo)致了它的消亡。像匈牙利命名法這樣的前綴系統(tǒng)最初只是為了增加意義，但最后用于其中的上下文越來越少，終于少得只剩類型信息。