關於 design pattern interface ，我們在網路上蒐集到這些相關的討論、資訊與評價

這是上課中錄的一小段影片，這個例子是讓大家自己從無到有完成 SequenceEqual() 的功能後，再透過重構來設計出更有彈性的 API。
　
進行方式是，先給大家測試案例來描述需求，請大家完成代碼通過測試之後，Live demo 帶著大家一步一步把更有彈性的 API 設計重構出來。
　
※ 你沒看錯，二十幾個 lab 都是先從測試紅燈開始，用測試來代表實務的需求
　
三天的【C#進階設計-從重構學會高易用性與高彈性API設計】培訓中，你會學到很多 C# 的基本功，包含：
　
👉 var, anonymous type, yield, extension method

👉 interface, delegate, lambda

👉 generic, covariance, contravariance

👉 IEnumerable, IEnumerator, HashSet, Stack, Queue, IEqualityComparer, IComparer…

👉 iterator pattern, decorator pattern

還有大量的重構手法，以及用 IDE 來有效快速產生與重構你的代碼與 API。
　
三天之後，ReSharper/JetBrains IDE 的重構跟產生功能，你大概就一輩子都不會忘記了。
　
【C#進階設計-從重構學會高易用性與高彈性API設計】，8/16~8/18 三天，額外開放 2 個保留名額。

>> 課程介紹請見：https://dotblogs.com.tw/hatelove/2019/02/18/csharp-advance-api-design

>> 上一梯次學員心得，請見：https://www.facebook.com/pg/91agile/photos/?tab=album&album_id=1149191585255458&__tn__=-UC-R

※ 錯過這一梯次，我個人預估下一梯次大概要再等快一年。
　
💡 課程介紹的文章中，還有 Zip() 的示範影片唷。💡

什麼叫做好的程式？
　
大家的答案都不一樣，甚至在自己不同的職涯階段，答案也都不一樣。
　
對我現階段來說，就是儘量滿足 “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

JavaScript 函數庫究竟有多豐富？

持續早上 JavaScript 與 jQuery 的話題...有人問我說，「JavaScript 的函數庫究竟有多豐富？」雖然不至於如佛家說的「如恆河沙數」或「如天上繁星」，但「族繁不及備載」的程度是一定有的。請參考底下這一篇：

20 JavaScript Libraries to Simplify Development Tasks
http://codegeekz.com/javascript-libraries/

其中，最常見的有下列這幾種（我個人接觸經驗認為的啦）：

1. jQuery（2006）
- 以「最短程式碼、最大生產力」見長。短短幾行，就能寫出威力十足的網頁特效。
- https://zh.wikipedia.org/wiki/JQuery

2. YUI (Yahoo! User Interface) (2005)
- 提供豐富的使用者介面（表單、導覽列…）
- http://en.wikipedia.org/wiki/YUI_Library

3. ExtJS（2006）
- 基於 YUI 上建立的。
- 提供大量美觀的視覺介面。
- 2010 年改名為 Sencha（日本話的「煎茶」）。
- http://zh.wikipedia.org/wiki/Extjs

4. Prototype (2005)
- 支援標準的物件導向機制，補足 JavaScript 與正規物件導向語言之間的鴻溝。
- 有些次要 Bugs 沒處理，評價兩極化。
- http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework

5. script.aculo.us
- 基於 Prototype 之上而建立的。
- 目前為止，最強的動畫函數庫！
- http://en.wikipedia.org/wiki/Script.aculo.us

6. MooTools (2006)
- 基於 Prototype 之上而建立的。
- 強調「模組化」與「物件導向」，適合拿來開發大型的 JavaScript 程式。
- http://en.wikipedia.org/wiki/MooTools

7. Dojo (2004)
- 用於「跨平台」、「快速開發」等目的的函數庫。
- 可寫出「讓不同瀏覽器，執行效果都相等」的 JavaScript 程式碼。
- http://en.wikipedia.org/wiki/Dojo_Toolkit

8. AngularJS（2009）
- 令人注目的後起之秀，由 Google 主導研發。
- 最早是為了做出「單一網頁架構（Single Page Architecture, 簡稱 SPA）」，就是那種所有東西都放在同一頁，一直捲就會動態載入的網頁。Google 已經將它用在「圖片搜尋」的結果頁，成為目前製作「SPA」時的不二選擇。
- 很強調 JavaScript 與 DOM 的「鬆散耦合（Loosely Coupled）」。認為與 DOM 結合得太緊密不利於程式碼重用，故大量利用 Design Pattern 中的「Dependency Injection（相依注入）」（也就是在 JavaScript 與 DOM 之間多加一層軟體層），降低 JavaScript 與 DOM 之間的耦合程度。
- http://zh.wikipedia.org/wiki/AngularJS

上述這些函數庫，最後都會轉化為 JavaScript 語言，然後丟給瀏覽器去解譯。感覺上，JavaScript 快成了網頁世界的「組合語言（Assembly）」了... XD。

這裡有所有 JavaScript 函數庫、軟體框架的功能比較，請參考：
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks