早上參與了這個討論 部落格：成長，就是不斷向自己妥協的過程 ，此處做下記錄方便後續回顧和引用。
多年以前上過史丹佛的一個開放課程 —— CS 106A: Programming Methodologies ，看的是 2008 年版，當時由語速很快幽默的 Mehran Sahami 教授主講。
有興趣的同學可以瞭解下，Bilibili 上有雙語字幕視訊 史丹佛大學公開課：程式設計方法學 。
課程內容現已記不清，但是程式設計多年偶爾會想起課程中他多次提及的一句話，憑著大概意思找到了 《Refactoring: Improving the Design of Existing Code, 1999》 一書中作者 Martin Fowler 有類似的觀點：
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
翻譯過來大概是：
任何傻瓜都能寫機器可執行的程式碼，而優秀的程式設計師寫的程式碼傻瓜都能看懂。
這跟我一開始對程式設計的認知相駁：
程式設計不應該是以執行效率為最高標準嗎？
在這之前，我常用的變數是 $a ，對的，當然是 $array 的簡稱。並且所有陣列型別的資料，都命名如 $a = User::all()->toArray() 。那如果在一個方法裡有兩個陣列怎麼辦？那第二個陣列我就會命名為：$_a = Topic::all()->toArray() 或者 $a1 = Topic::all()->toArray()。函式和方法名也是比較隨意，本著執行效率優先，儘量使用比較簡短的命名，例如 getTopicType() 我會命名為 gtt()，簡短好記寫起來也不費勁。
因為當時學過一點 C 和編譯原理的我知道，變數名你怎麼命名，問題不大，機器都能順利執行。
當然，我已經好久沒這麼寫程式碼了。多年以後偶爾看到有朋友或者同事這麼寫程式碼，也會心一笑。
為什麼？
為什麼要寫傻瓜都能看得懂的程式碼？
首先應該認識到，商業軟體一般都很複雜，複雜到需要一個團隊來維護。而以上觀點就是在團隊程式設計這個前提下提出來的，在團隊開發裡，編寫高可讀性至關重要。
可讀性不僅影響開發效率，還會影響程式設計愉悅性，想想你每接觸一個專案就要去熟悉一大堆不規範的編碼方式，很快你就會對程式設計產生厭惡心理。
可讀性不僅僅表現在變數和方法的命名上，軟體架構選項、設計模式的選擇和新增，這些都會影響其他人對專案理解難度。可讀性的程式碼會增加維護成本，從而降低軟體的健壯性和穩定性。
所以不要在某個地方學了 Repository 和 Command Bus 設計模式，就迫不及待的在公司專案中使用。對於商業專案，每一次新的設計模式引入，都要非常謹慎，建議和團隊成員充分討論後再操作。可以從下面幾個問題開始：
- 是否增加了學習成本？
- 是否增加了維護成本？
- 是否會降低了開發效率？
簡而言之，這是一個『軟體工程（Software Engineering）』的範疇，需要考慮的不止是軟體編碼，還需要把軟體參與者、專案管控和商業效率等因素考慮進來。
結語
Laravel 框架作者和 laracasts.com 作者在往期的 Laravel 播客 中提到，他們會用 50% 的時間來編碼，剩下的 50% 的時間來考慮如何命名。因此可見，Laravel 的優雅是有原因的。