WadeHuang的學習迷航記

書本連結 摘要 作者帶領讀者一探 Laravel 的原始碼，從框架技術角度介紹 Laravel 構建的原理，包含：框架的設計思想、如何應用新潮的 設計模式 與 依賴注入容器 建立框架。 心得 本書深度相當足夠，作者以幾乎逐行的慢節奏帶領讀者解讀原始碼。且不只介紹原始碼做了哪些事情，更帶出設計思維、理念。另外講解 PHP 新特性、解析設計模式等進階的用法時也不含糊。只要有花時間投入這本書，一定會學到不錯的設計觀念。 推薦度：3 難易度：3 適合讀者：設計模式初學者、Laravel 開發者 其他：學 Laravel 框架的人必學 可學習議題：Laravel 框架、設計模式、軟體設計思想、依賴注入容器原理 ​

Re-Engineering Legacy Software 書本連結 心得： 本書介紹如何處理一個遺留系統。相較一般重構技術的書籍，此書包含的議題更廣，包含： 如何決策重構還是重寫 、 利用 CI 工具系統性的追蹤重構成效 、 在團隊中傳播重構的知識 。 本書花較多篇幅在上述議題中，重構技術、技巧層面的知識則篇幅相當少。 但也因為本書的議題廣泛不拘泥於重構技術與技巧， 更讓讀者體會系統持續重構後的大藍圖 以及如何利用其他工具強化重構的成效。 適合讀者：學習重構、CI\CD 的 RD 前置知識：重構 其他： 可學習議題：重構、CI\CD、敏捷開發 ​

書本連結 摘要： 本書快速帶領讀者以真實世界中的範例學習每一種設計模式。本書一共有 16 種設計模式，每個模式 都會有小篇幅的介紹意圖、使用場景、範例程式碼。 注意： 本書是透過 Python 的語法特性實踐設計模式，而非只是承襲那些來自 Java 或 C# 的實作。 心得： 這本書很適合入門設計模式，作者用簡單易懂的文字講解每個 模式的意圖、使用場景 。並設計難易度適中的範例來示範如何使用每個模式。 相較過於抽象/簡單的範例，如形狀、汽車等等，本書的範例更容易理解引入設計模式的優勢。 本書可以算是展示設計模式的書，故深度不深 ，只能學到設計模式的基礎概念、表面知識。沒有程式「設計思想」的層面，故讀完此書仍無法在自己的專案中引入設計模式是很正常的。 適合讀者：剛入門設計模式的人 其他： 可學習議題：設計模式、Python 延伸書籍： 設計模式的解析與活用 kent beck 實作模式(Implementation Patterns) 重構與模式 ​

書本連結 摘要： 本書分成三大部分，分別為：基礎知識、設計模式、設計原則和程式設計技巧。 基礎知識： 如何用 JavaScript 實現設計模式的關鍵步驟、技術與知識。 設計模式： 使用 JavaScript 實現 14 種設計模式。 作者為了讓讀者了解 設計模式的實作方式有很多種 ，更是加碼每個模式都用兩種方式實作： 用 JavaScript 語言特性實現設計模式 用 JavaScript 模仿物件導向 Class 介面的風格實現設計模式 設計原則和程式設計技巧： JavaScript 不但可以應用物件導向 SOLID 原則，SOLID 在設計良好程式時同時也扮演相當重要的角色。 心得： 相當推薦入門學習設計模式的開發人員。 這本書是中文原文書，作者曾探是來自中國的資深工程師。 因此作者講解物件導向、設計模式的核心觀念時不需要語言轉譯。 少了語言的隔閡，加上作者精闢易懂的解說，讓讀者更容易理解設計模式。 此外，作者本身功力很深，書中不單單只有介紹設計模式這麼簡單，作者經常傳授高手的程式設計思維，並且總是點出關鍵重要的知識，也讓這本書變得更值得一看。 缺點： 由於出版日期較早，書中 JavaScript 的語法可用 ES6 取代。但書中傳遞的觀念絕對值得一看。 適合讀者：想入門設計模式的 RD、JavaScript 開發者 其他： 可學習議題：JavaScript、設計模式 ​

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 單一職責原則(Single responsibility principle) 定義： A class should have only one reason to change. 以一個類別來說，應該只有一個引起它變化的原因。 ”等等，這是在說人話嗎？還是我理解能力不夠好？“ 這是我第一次讀到 SRP 原則定義的反應，當時覺得 SOLID 每個原則都是文字天書。若你也有跟我一樣的反應，不要緊張，大家都經歷過這個過程。我將會在本文中以自己的體悟來講解觀念，實務經驗演示如何實踐 SOLID 原則。 單一職責原則是 SOLID 原則中看起來最容易明白，卻也是最容易讓人混淆的原則。因為很多人並不清楚 職責 是什麼，甚至誤以為一個類別只能做一件事。接下來的文章中會依序講解原則的目的；解決什麼問題；如何實踐。 目的： 提高程式碼的內聚性，讓程式碼更易於管理和重複使用。 解析： 什麼是內聚？ 在英文辭典中 內聚(Cohesion) 的同義詞為一致性、凝聚、結合等等，描述相關的事務如何聯繫在一起。在軟體開發中， 高質量程式碼通常是高內聚性的 ， 內聚 程式碼的特徵為： 每個程式碼片段都只關注一件事情 當每段程式碼只關注一件事情時，程式碼會更容易被理解和處理，且相較 低內聚 的程式碼來說更容易編寫。 什麼情況會造成低內聚? 當程式碼包含一個以上「互不相關」的邏輯或意圖時，程式碼的內聚性就會降低。 (一般而言，低內聚的程式碼代表高耦合 ^1 ) 程式碼的內聚性一但降低，閱讀與維護程式碼的難度就會提升 。當你必須從一個大函式裡面修改其中一小段邏輯，若不先花時間讀懂函式中每段程式碼之間的關係就直接修改程式碼，很容易破壞函式原先可正常運作的程式碼。為了避免對程式碼造成破壞，開發人員開發過程總是變成： 花費 80% 時間閱讀程式碼，真正編寫程式碼的時間卻只有 20% 。對於維護一個系統來說，這種情況除了相當浪費成本以外，也相當折磨開發人員的心情，更糟的是，每次回來維護又要重新讀一