可讀性程式碼：為什麼、怎樣以及什麼時候
如果你對開發團隊進行問卷，大多數人會說“我們想要可讀性高的程式碼”。你甚至發現有些人認為可讀性比功能更重要。但是，當要求人們對可讀性做出定義時，他們的意見就會出現分歧。Laura Savino在ofollow,noindex" target="_blank">Explore DDD 2018 大會上的演講就是以這個作為前提。她闡述了為什麼我們想要可讀性高的程式碼、可讀性究竟意味著什麼，以及什麼時候必須優先考慮可讀性。
Savino擁有小學法語教師的背景，後來成為iOS開發人員和導師，因此，她能夠提供更多有關比較自然語言和程式語言的見解。剛開始學習新程式語言的程式員通常先學寫一個基本的“Hello，world！”應用程式。同樣，“Bonjour”、“Hola”或“Guten-tag”可能是學習法語、西班牙語或德語的人學會的第一個單詞。
正如程式設計師將迅速學會“Hello，world！”，口語也會很快進入中間階段。Savino舉了一個例子，在法語課上問一個同學是否願意在課後和你一起去喝咖啡（Voulez-vous prendreuncaféavelve moiaprèslescours？）。即使他拒絕了（Désolé，je ne peux pas prendredecaféprèslescours），在別人看來這是有史以來最無聊的談話，但你自己卻感覺飄飄然：你說了一個句子，然後有人理解它，因為你收到了適當的迴應，而你瞭解迴應是什麼意思。這就像在iOS應用程式中顯示資料一樣——它不是那麼吸引人，但當你第一次成功完成這個任務時，你的腎上腺素會飆升。
學習語言的高階階段超越了對語法的思考。你的目標已經超越了只是相互理解，你現在需要深入細節。這時候程式語言與人類語言之間的類比開始不再奏效，或者至少需要更深入的分析。
在進行程式碼評審時，經常會有人說，“我無法理解這些程式碼”，而另一個人（可能是作者）反駁說，“但這種方式更具可讀性”。Savino用這個例子來說明“可讀性取決是誰在閱讀程式碼”。讓可讀性變得複雜的是程式碼有兩種不同的受眾：其他開發人員和計算機。因為計算機如果無法讀懂我們的程式碼，它們很快就會告訴我們，我們自然會基於計算機的反饋做出調整。我們承認這種偏見的存在，有時候會在程式碼周圍加上人類可讀的註釋。但是，Savino警告說，“註釋並不能帶來具備可讀性的程式碼”。
Savino解釋瞭解讀文字或程式碼與流利閱讀之間的區別。她使用E. E. Cummings的詩“when serpents bargain for the right to squirm ”作為例子，一個美麗而複雜的作品需要閱讀多次才能真正開始理解其中的含義。當你在閱讀程式碼時遇到不熟悉的術語時需要經歷類似的過程——查詢一個，然後是下一個，然後是下一個，你就像進了一個兔子洞，直到你忘記了最初想要理解的內容為止。Savino警告說，雖然可以從深刻的理解中獲得快樂，但“寫詩與開發軟體不是一回事”。
相反，流利的閱讀是一種快速而正確的理解，不會佔用你的工作記憶。多年的閱讀經驗讓你能夠快速瀏覽文章並仍然能夠理解其中的內容。Savino認為，閱讀可讀性高的程式碼也是如此。當代碼很容易閱讀時，大腦可以騰出一部分發現其中可能出現的問題，讓程式碼評審更加高效。
在給出了高可讀性程式碼為什麼如此重要的原因之後，Savino探討了如何寫出高可讀性程式碼的技術。在與語言不流利的談話物件溝通時應該避免使用俚語，並使用明確的表達方式。在程式碼中，方法的命名可以用beginApp()，而不是releaseTheHounds()，並在每一步給出變數和呼叫結果，而不是將函式呼叫連結在一起。
Savino還探討了我們的本能模式匹配能力。在抽象層面，需要使用“斜視測試”來檢視程式碼的一般性結構，看看是否有任何異常的東西。在更低的層面，儘量避免使用看起來相似的字元和符號，包括!、I、l和1，這些可能會導致反模式匹配。最後，如果你正在做一些與眾不同的東西，那就以一種可以讓它從脫穎而出的命名方式。
對於作家來說，最好的建議是“瞭解你的受眾”。Savino說，當你的受眾是閱讀你的程式碼的人時，你應該更進一步，並信任他們。當有人告訴你程式碼不夠清晰時，相信他們，然後問他們因為缺少了哪些資訊導致程式碼難以閱讀。用他們的反饋來提高程式碼的可讀性。
最後，Savino提到了一些可讀性需要成為主要驅動因素的例子。簡單地說，一段程式碼越重要，它的可讀性就應該越高。Savino引用了美國宇航局噴氣推進實驗室的編碼指南 ，該指南指出，“任務關鍵程式碼不應該只是可以辯證的，還必須是絕對正確的”。與人類溝通有關的一個更為實際的場景是火災逃生標誌，在逃離火災時，人們不需要額外的努力看懂這些標誌。
你的團隊應該針對是否以及何時需要可讀程式碼展開討論。你的目標應該是所有團隊成員都能流利地閱讀程式碼。Savino最後鼓勵每個人進行“更少的解讀，更多的創造”。
檢視英文原文：Readable Code - Why, How and When You Should Write It