編寫良好的程式碼：如何減少程式碼的認知負荷

剔除個人怪癖
當你讀了一些文章，它們吹噓的新的技巧進入了你的頭腦，然後你編寫了所謂聰明的程式碼，你的所有同行將會印象深刻。

問題是，人們只是想修復bug，然後繼續開發。你的這些聰明把戲通常只會造成分心。正“ 應用神經科學到軟體開發 ”中所說的，當人們必須看懂消化你的程式碼段時，他們“心理壓力”如果增加，就很難取得進展。

不要以需要解釋的方式太過於個性化你的工作。不要以“你的方式”編寫程式碼。只需遵循編碼標準，透過人們期望的方式進行編碼，使您的程式碼可預測並且易於閱讀。

劃分和征服它
複雜程式碼通常可以透過模組化來釐清，還有更多的方法來做這件事，將長條件語句的結果儲存到一個變數或兩個變數中是一種很好的模組化方法，而沒有函式呼叫的開銷。這甚至允許你將它們組成更大的條件，或者在別的地方重用結果。

利用變數來劃分邏輯:

valid_user = loogedIn() && hasRole(ROLE_ADMIN)
valid_data = data != null && validate(data)

if (valid_user && valid_data)  ...
<p class="indent">

使其離散和可加工
您的計算機和工具可能與您一樣難以處理程式碼，在前處理器和變數的數量與程式碼的複雜程度之間存在一些相關性。

讓我們暫時擱置這些額外構建工具的可能的好處。它們需要您使用特定於領域的語言，例如自定義模板，或複雜和動態資料結構（如雜湊表）。你的IDE通常不會善於處理這些東西，找到相關的程式碼段將變得更加困難。

避免使用與IDE不相容的語言擴充套件和庫。它們對您的工作效率的影響將遠遠超過更簡單的配置或使用更簡潔的語法從而節省幾個敲鍵的小好處。


使用ServiceLocator.get('servicename')是一個設計示例，導致與大多數IDE整合不佳。

另一種保持IDE的“整合”方法是避免魔術程式碼。大多數語言將為您提供更多動態程式碼的寫法。濫用這些功能，例如使用魔術字串，魔術陣列索引和自定義模板語言功能將導致更多的斷裂的程式碼庫。一般來說，只有人類才知道意義的功能都會導致你走這條路（IDE不懂這些功能背後意義），而且這是一條艱難的道路，因為如果你的IDE不理解程式碼，任何重構功能將是無用的，特別是當你想遷移到一個更靜態的架構。

使其可讀
努力建立一個可預測的架構。你的隊友會發現更容易找到他們想要的東西，這將大大減少他們完成一些工作所需的時間。一旦你同意了專案的整體架構結構，使明顯的主要元素位於突出。比如使用MVC模式將模型，檢視和控制器放在自己的資料夾中，而不是三個資料夾分佈在幾個不同的地方。

談到了模組化。還可能有過多的模組化，這通常會使程式碼更難以定位。你的IDE可能會幫助一些，但是通常你會因為它有太多不相關的程式碼，或者索引和手動處理問題而忽略庫資料夾之間的撕裂。這就不行了。嘗試使用較少的庫，同時又儘可能多滿足您的需求。

庫包和工具也可能成為新開發者的障礙。我最近使用EcmaScript 7（babel）構建了一個專案，只是到後來才意識到，我們的初級開發者正在卡住在某個地方試圖搞懂它。不要使用大家仍然太難以握住的工具。等待一個更好的時間再用。

使它容易消化
選擇好的名字是軟體開發中最大的問題之一。構建工具不太可能改進這一點，原因是計算機不能真正知道解決方案背後的原因。你必須記錄為什麼這麼做的原因。對有關的和上下文的變數和函式取名是做到這一點的偉大方法。 傳達目的的名稱甚至會減少對文件的閱讀需要。

在名稱中使用字首是一個很好的方式來給他們新增意義。這是一個慣例，以前是流行的，我認為濫用是導致它沒有變得流行的原因。像匈牙利語符號這樣的字首系統最初意在增加意義，但隨著時間的推移，它們最終以較少的語境方式使用，例如只是新增型別資訊。

最後，保持低迴圈能降低複雜性。這意味著條件語句的分支數量要儘可能少。每個額外的分支將不僅增加複雜和有害可讀性，更重要的是增加你必須跟蹤事情的數量。

Writing good code: how to reduce the cognitive loa