WadeHuang的學習迷航記

與難易度相關的讀書技巧： 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 原則，表示重複的邏輯該被重構成唯一且適當的物件或函式了。 新增功能時重構： 當我們試著增加新功能時，便有可能發現舊有的程式碼可以進行一些調整，而達成了必須重構所想要達成的目的。 但如果你在增加功能的時候，發現原設計就足以優雅地讓你將新功能擴充上去，那麼，這意謂著，還不太需要做什麼重構。 除錯時重構： 除錯的時候，你不僅會接觸到舊有的程式碼，而且，你通常得搞懂它真正的運作邏輯，當你真的懂了之後，就會知道如何用更清晰、簡潔的方式來改寫這段程式碼。 總結： 很多架構良好的程式，

這種已經推(push)上來的沒辦法更改 Commit Message 跟內容  怎麼辦！ 這種情況我會直接重切一條新的分支，重寫 Commit，底下是主要步驟： 把這幾次 Commit 的異動暫存(stash)起來 從開發前的 Commit 切新分支（for 重寫 commit 用) 把暫存(stash)的檔案套用到新分支 開始重寫 Commit 做完 Commit 就把新切出來這條分支上傳回自己的 Repo，重發 Merge Request。 第一次做可能不熟，所以底下是每個步驟截圖： 步驟看起來很多，但做熟的話其實就只有幾個主要步驟而已，會越做越快！ 1. 把這幾次 Commit 的異動暫存(stash)起來 2. 從在開發前的 Commit 切新分支（for 重寫 commit 用) 3. 把暫存(stash)的檔案套用到新分支 4. 開始重寫 Commit ​

Gitlab 合併請求（Merge Request ） 一般在團隊開發的時候，為了避免工程師直接對主要 Repo 進行修改，會要求工程師從 專案的主要 Repo 複製一份這個專案的副本（Fork）回來工程師的電腦進行開發/除錯。 工程師開發完成後，如果要把電腦上最新版本的程式碼上傳回 專案的主要 Repo ，就必須對 專案的主要 Repo 發送一個 合併請求 ，請 專案的主要 Repo 管理員進行程式合併。 當合併請求發送出去後， 專案的主要 Repo 管理員可以在管理頁面上看見你的合併請求，這時管理員會進行一次 Code Review，管理員覺得程式沒問題，就會將工程師的程式合併回主線。 若管理員覺得這段程式碼有問題，也可以 Close 這次的 Merge Request 。 另外 Merge Request 等同於 Github 的 Pull Request   - 可參考:  與其它開發者的互動 - 使用 Pull Request（PR） 上述流程如下圖： ​