WadeHuang的學習迷航記

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 Why SOLID? 在 前一篇文章 中介紹 SOLID 對一個工程師的影響，這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則？ 軟體複雜的本質 專案經常會歷經「商業邏輯調整」和「快速且多變的需求」，這都不是開發環節所能控制的，但是一個專案會「遇到困難」常常是因為  糟糕的程式設計  和其他技術層面導致。 其中  糟糕的程式設計  又可分成三個因素： 程式碼變更 Bug 修復 複雜度控制 在添加功能前應該  閱讀代碼並細心設計 ，但實際上更常發生的是，開發者選擇 直接在程式碼上面堆疊新的程式碼 。 新舊版本  和  意圖不同  的程式碼錯綜複雜之下，會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug，從而導致另一個 Bug，然後一個接著一個，這樣的事情不斷發生。 在  沒有做過可擴展性設計的程式碼  上進行擴展功能，常常是火上加油！ 那為什麼不把程式「設計」成可擴展就好了呢？ 開發者知識普遍不足 一個充滿外行人的產業 開發者們來自不同的背景，且有大量不同的方式去解決問題，但是一個開發者應該具備什麼樣的知識體系，並沒有一個廣泛的共識。 更不幸的是，許多開發者在學校裡面學到的知識是過時的，學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能，但是 ... 掌握一門程式語言並不能使你成為軟體開發者，正如掌握一門自然語言並不能使你成為作家 學校所教的知識，並不是大部分軟體開發者的工作內容。 開發者也許能編寫一個可運行的程式碼，但若要 回頭去擴展程式碼卻 常 常 是艱難且冒險的 。 軟體開發過程中，開發者需要做出無數個選擇，加上每個開發者用不同的方法解決問題，助長了難以維護、難以擴展的程式碼。最終讓  系統設計的思想溝通  變得困難（ 工程師必須花費大量時間閱讀程式碼 ）。 不論是開發者還是管理者都需要對  軟體複雜的本質  做管理。為了編寫出更容易應對變化的程式碼，我們必須填補基礎認知方面的空白。 導入設計原則 若有一些

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 物件導向 SOLID 原則對工程師的好處與如何影響能力 前言 為了感謝部落格一直以來都有人在閱讀，讓我一直有經營下去的動力。所以想寫一個系列 學習 SOLID 原則 2 年後的心得文章。這心得文章包含自己使用 SOLID 兩年的總結，並且以自己的理解簡化 SOLID 原則，希望幫助新手工程師縮短「SOLID 原則是文字天書」的時間。 從第一次接觸 物件導向 SOLID 原則  至今已經兩年了，一開始覺得「SOLID 原則是文字天書」，到現在 Coding 時常融入 SOLID 的思想來「設計」程式。 所以 SOLID 原則到底是什麼？ 》SOLID 原則其實是物件導向「設計層面」的思維與定律。 大學時期程式設計課程中所學的物件導向，其實只是在介紹程式語言有提供  物件導向的哪些特性 ，卻 從未有人教導如何透過物件導向的特性撰寫程式碼 ，甚至沒人告訴你為什麼要用物件導向開發程式。 然而 SOLID 原則就是物件導向開發的指導方針，若以多個角度來看這些原則，會發現 SOLID 已經指出  物件導向的優點   以及 程序式程式碼隱晦的缺點 。但這不代表物件導向沒有缺點，要是沒有妥善運用 SOLID 原則的話，物件導向對專案的傷害絕對不比  程序式程式碼  低！但這留給後續的文章來解釋，首先來看看 SOLID 的好處與重要性。 SOLID 原則對專案的好處？  SOLID 原則對專案的影響很大，當專案一點一滴的導入 SOLID 原則的程式碼，不少複雜的程式碼慢慢被簡化，被 簡化的程式碼可以降低複雜度，讀懂程式碼的時間從原本需要花 20 分鐘閱讀，到只需要花費 2 分鐘閱讀 。縮短閱讀時間對專案來說是一件好事， 一般來說工程師「閱讀程式碼」的時間常常大於 「 新增/修改程式碼」的時間 ，畢竟要先讀懂才能動手嘛，因此  縮短閱讀 程式碼 時間 等於 縮短 「 新增/修改程式碼」 程式碼的時間 。 優點：降低程式碼複雜度 => 縮短閱讀程式碼的時間 => 減少維護專案程式碼的時間 你可能會覺得，為什麼 S

與難易度相關的讀書技巧： Tips 1： 若一直花時間讀太簡單的書，表示沒有累積新知識，只是在浪費時間 。 讀書目的是累積知識量、增進新觀念。 這時應該挑戰困難、進階一點的書。 Tips 2： 若 看不懂作者部分的內容，表示你跟作者仍不在同一個知識水平 。 這時需要找別的資源（網路文章、別的書籍）補充知識。 Tips 3： 若 看不懂作者一半的內容，表示跟作者的知識水平相差太多 。 這時應該放下手上的書，先學習 前置知識 再回來挑戰。 Tips 4： 不要讀到不懂詞彙的就立刻停下來查資料 。 應先快速讀過整本書、章節，讓大腦快速建立 書中的知識概念、詞彙關係 。 大腦建立起 詞彙關係 後，再回來查資料會更容易理解。 其他： 學習新知識的過程總是辛苦… ​

自學時常要 K 書培養知識，但是在資訊大爆大的時代，書籍的數量跟網路文章一樣多，品質也參差不齊。因此選書需要謹慎，若不仔細挑書就容易變成浪費時間。 平時選書會透過「 題材/範圍、深度、作者文筆、翻譯品質 」來決定要不要購買或花時間讀下去： 題材/範圍： 快速讀過目錄，檢查書本內容是不是圍繞在你有興趣的主題。 深度： 快速翻閱書籍內容，檢查書本的深度/難易度是不是符合你現在的需求。若深度太淺、太簡單則表示你不需要花太多時間閱讀這本書。反之深度太深、太困難，表示應該花時間學習前置知識。 作者文筆： 此項決定知識的吸收效率。快速檢查大小章節的前後順序，以及內文是否與章節有關聯。 作者若有系統性的把書籍章節、內文結構設計妥當，由淺入深。則閱讀書籍速度跟吸收知識都會很快。 若作者沒辦法有結構、系統性得組織知識，在閱讀書籍時，你必須時常前後反覆翻閱，並搭配網路搜尋文章補充知識，把破碎的知識從書中整理到腦海裡。 翻譯品質： 程式相關的書籍，多半是國外原文翻譯的書，若翻譯品質很差，輕則看得出戲（有些翻譯與句很怪，根本不像中文），重則扭曲作者原意，誤導讀者學習不對的觀念。 若遇到翻譯品質差的書籍，可以改換簡體書看（換譯者）或者搭配原文書一起看。 ​

The Art of Unit Testing: with examples in C#, 2/e 書本連結 摘要： 本書涵蓋了撰寫單元測試的基本知識，包含如何撰寫單元測試、使用隔離（模擬）框架，以及讓它們變得可維護、可讀、可被信任。並且講解在真實世界撰寫、管理和維護單元測試的最佳實踐。 心得： 第一、二章： 作者示範一個良好的單元測試應該具備哪些條件。 第三、四章： 作者以設計單元測試的角度，引用 Working Effectively with Legacy Code 的接縫技術講解如何透過接縫技術建立偽物件，讓單元測試的受測對象(SUT)可以隔離依賴，達到快速、獨立原則。 接縫技術是針對 Legacy Code 無法執行單元測試的處理手段 ，由本書的角度來學習接縫技術，會覺得為什麼要繞一大圈只為了產生偽物件(Stub/Mock)。因此建議直接去看 Working Effectively with Legacy Code 如何使用接縫技術讓多種情境的 Legacy Code 可執行單元測試。 第五章： 使用模擬(Mock)框架來取代三、四章節的接縫技術。 覺得此章節的安排不太洽當， 接縫技術是針對 Legacy Code 無法執行單元測試的處理手段 ，作者卻以取代接縫技術的角度來介紹模擬框架，可能讓讀者誤以為接縫技術是過時的測試手段。 也許是本書出版的年代較早 (1/e: 2009、2/e: 2013)，但現今的測試框架搭配模擬框架已經相當普及。若要講解模擬技術時，應該直接講解模擬框架即可，把接縫技術跟模擬技術分開講應該會更好！。 第七、八、九、十、十一章節： 介紹開發團隊在實務中如何進行單元測試，包含如何安排單元測試的檔案、舊系統引入單元測試的策略、如何讓單元測試好維護..等等。 若您的團隊還不了解怎麼進行單元測試，則相當推薦閱讀這些章節。 總結： 本書的深度不深，作者把讀者設定為單元測試的新手，從 0 開始講解單元測試，書中的內容大多是針對不良測試案例的叮嚀。 推薦給想學習單元測試又對單元測試不了解的工程師，本書將單元測試應該具備的概念都教完了，讀過後應該能少走不少歪路。 適合讀者：對單元測試不了解的工程師 可學習議題：單元測試技術 延伸學習：測試驅動開發（TDD)、行為

CodeIgniter 框架擴展：HMVC Hierarchical((階層式的))-Model-View-Controller（HMVC）模式，也可以叫做 Layered MVC。 為什麼需要 HMVC 單層 MVC 的限制 原 MVC 架構中只有單層 MVC ，單層 MVC 的設計本身沒問題，但隨著系統功能漸變多變複雜時，程式碼卻只能塞進單層 MVC 裡面，程式碼很快就會變得  巨大、縱錯複雜、互相耦合、難以維護 。試想一下，一個 Controller 內有 7、8 千行程式碼會容易維護嗎。 原 CodeIgniter MVC 架構(單層 MVC)示意圖： application |- controllers |- controllersA.php |- controllersB.php |- ...(所有 Controller 都只能放在同一層） |- models |- models1.php |- models2.php |- ...(所有 Model 都只能放在同一層） |- views |- views1 |- index.php |- footer.php |- ... |- views2 |- index.php |- footer.php HMVC 帶來的解決方案： 擴展 MVC 架構， 讓 MVC 底下可以再擴充一層或多層子 MVC ，讓單層 MVC 變成階層式 MVC，而這些擴充出來的 MVC，又稱作為模組、模塊(Modules)。 使用模組好處是： 使每個功能都可以獨立出來 因模組變得獨立，降低各個功能模組之間的耦合性 提高程式碼複用性 每個模組都有自己的 MVC 結構 HMVC 架構示意圖： CodeIgniter HMVC 擴展模組後，其結構(階層式 MVC)如下： application |- modules |- moduleA

重構定義： 在不改變軟體外部行為的前提下，改變其內部結構，使其更容易理解且易於修改。 目的： 重構的主要目的就是為了提升程式碼品質、 提升程式碼的可讀性 ，以及為了日後有新需求的變化時，程式碼可以 更容易修改或是擴充 （提高可維護性）。 優點： 1. 改進程式碼的設計： 消除重覆的程式碼，每個小功能被歸責到適當的物件中，讓程式碼的職責更清楚就會更容易維護。 將雜亂無序的程式碼，重構成一連串的 精心設計 的流程，讓程式碼更容易擴充。 2. 程式碼更容易被理解： 重構簡單的講，就是整理程式碼，可以透過 Clean Code 的規範 來整理程式碼，提升可讀性。 想想程式碼過一段時間後的第二個讀者，而且這個人常常是你自己。 3. Debug 更容易： 重構的過程中，會透過單一職責原則，依照程式碼的工作責任將程式碼整理至責任相同的類別中。有責任清楚的物件，就能更快釐清問題點，除錯速度自然能夠提升。 什麼時候可以開始重構？ 事實上，重構並不是一項需要額外撥出時間來進行的工作， 重構應該是在你的開發過程中持續在發生的事情 。 重構的活動，最理想的情況，就是透過持續不斷的整理，掃除那些有礙程式可讀性及可維護性的程式碼，讓程式碼持續盡可能地保持在一定健康的狀態。 既然重構是一個持續進行的活動，但又不是特意安排、特別撥出時間來做的工作，那麼，在什麼樣明確的時間點，應該觸發重構的進行呢？基本上， 重構的活動應該伴隨著我們一般開發過程中的主要活動來進行。這些主要活動包括了：增加新功能、修正錯誤、以及程式碼審查的時候，還有三次法則 。 三次法則： 同樣的事做三次，犯了 Don’t Repeat Yourself 原則，表示重複的邏輯該被重構成唯一且適當的物件或函式了。 新增功能時重構： 當我們試著增加新功能時，便有可能發現舊有的程式碼可以進行一些調整，而達成了必須重構所想要達成的目的。 但如果你在增加功能的時候，發現原設計就足以優雅地讓你將新功能擴充上去，那麼，這意謂著，還不太需要做什麼重構。 除錯時重構： 除錯的時候，你不僅會接觸到舊有的程式碼，而且，你通常得搞懂它真正的運作邏輯，當你真的懂了之後，就會知道如何用更清晰、簡潔的方式來改寫這段程式碼。 總結： 很多架構良好的程式，