什麼叫做好的程式？
大家的答案都不一樣，甚至在自己不同的職涯階段，答案也都不一樣。
對我現階段來說，就是儘量滿足 “simplicity”，也就是「簡單設計」。
參考：https://martinfowler.com/bliki/BeckDesignRules.html
要設計出很簡單(simple)的作品，一點也不容易(easy)，得內化不少技能。
基本原則其實很精要，（留意順序）
* Passes the tests
* Reveals intention
* No duplication
* Fewest elements
1. 針對第一點「通過測試」，也就是不管你的設計多好，都要先確保它執行符合你的預期，要確認你的預期符合需求。
撰寫測試，並通過測試，才能輕鬆的滿足這第一要點。
2 與 3，這兩者的順序有兩派，有些人覺得「理解意圖」要比「消除重複」優先，有些人則覺得要反過來。
我自己覺得這兩者在開發過程中是可以同時滿足的，所以一樣重要。
但在 legacy code 裡面，我會覺得「呈現意圖」要比「消除重複重要」。
原因是，當具備一定的工程實踐技能，搞懂需求、情境、限制時，要消除重複非常容易，但如果容易誤解原本代碼的意圖，或需要很多時間才能猜測代碼意圖，這仍是某種程度的賭注。
4. 第四點是 simplicity 最重要的限制，當能滿足前三點時，用「越少的元素」越好。
越少的元素包括比較少的 class, interface, 參數個數, 回傳的內容, 物件之間的互動次數, 物件之間的相依關係。
通常為了消除重複，（甚至是可測試性），大家容易把單純的東西搞得特別複雜，開始亂套 design pattern 跟胡亂透過繼承來避免重複的過度設計最爲常見。
要解決任何一個依賴，都可以透過新增一層中間層來解決，大家往往更傾向「學習」、達到「低耦合」的設計，卻忽略了「高內聚」其實才是「物件」跟「互動簡單化」的核心。
—
補充一下，我已經兩年避免使用「可讀性」這個字眼，因為你覺得好讀，他不一定覺得好讀。
每個字讀起來都懂，你卻看不出它想幹嘛，它的意圖、流程、目的，都得再經過作者翻譯一次，你才知道程式的意圖。（還要經過翻譯，代表程式本身呈現的意圖跟作者想表達的，中間還有一段落差。）
Intention-driven 的設計還是很重要，避免把代碼層級的東西攤開在 public 的流程中，導致抽象干擾(Abstraction Distraction)的壞味道。
消除重複的目的則是在於「可維護性」，往往一些重構的壞設計，都是基於為了消除重複而把系統以錯誤的方向來重構，常見的例如把重複的代碼放到父類別裡面，來讓子類可以共用，或是 default 的行為放在父類，每個子類可以決定如何加工或覆寫，而延伸出來繼承鏈的大問題。
寫得有些冗長了，想體會簡單設計的挑戰、實作、學習、突破，到實務上的逐漸內化，請參考：https://dotblogs.com.tw/…/201907-evolutionary-development-t…
#七月梯次已額滿，下一梯次還在猶豫是要在十二月，或是2020年二三月。您如歸有興趣先卡早鳥，請您一樣先填七月份的報名表單，待下一梯次確定日期後，我會依序第一時間通知您，以讓您擁有更大的機會取得早鳥的資格。
也可以參考過去學員上完課沈澱之後的心得：https://dotblogs.com.tw/hatelove/2019/06/16/133316
