此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 8.3 Replace One/Many Distinctions With Composite 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 8.2 Extract Composite 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 8.1 Form Template Method 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 7.6 Replace Conditional Dispatcher with Command 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 7.5 Replace Implicit Tree with Composite 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，所使用的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 7.3 Move Embellishment to Decorator 的具體演練。
此系列文章是我閱讀《Refactoring To Patterns》過程中實際演練的筆記。閱讀過程中發現若沒有相當的 Design Patterns、Refactoring 底子，此書真的不易閱讀，必須伴隨實際操作才能更理解每個步驟具體的方式，故在這記錄之餘也跟各位分享。
書中是使用 Java 的程式碼作為範例，而我比較熟稔 C#，在 GitHub 上找到了相當完整的 Refactoring To Pattern C# Sample Code ，可直接作為演練程式碼。而我的演練環境為：Visual Studio 2017、ReSharper、VsVim。過程中會因應 ReSharper 的功能，所以有些許的調整以便更「優雅」的進行重構。
此篇是關於 7.2 Replace Conditional Logic with Strategy 的具體演練。
繼 [軟體開發] 淺談軟體開發 再接著聊聊軟體工程師如何面對這一片困境，從一個最小的面向談起 ― 自己。
Unit Test 在使用 TDD 開發時，除了單元測試的角色之外
更像是需求的描述者
但回歸到真正的實務情境上，往往遇到的不是從無到有的開發
而是從既有的架構中去新增額外的功能
於此， Unit Test 更像是重構時的保險裝置
追蹤了91大甚久～也見過不少次
歷經一番佈署爭取，終於讓老闆讓我去上課啦～～XD 感謝老闆！
先說結論，今天真的充實，也完全不覺得乏味
九個小時一下子就過了～～
之前也算有自行牛刀小試 TDD，很多卡關點今天完全解惑！
但後面竟然還有整整兩天課的內容，實在讓我非常期待！！
※ 本文僅雜記一些零碎的心得～
測試覆蓋率，沒錯，是個數字...
是個很可能出現在 KPI、驗收規格文件等地方的需求
只要把 unit test 上的 Assert 都拿掉，全部的 Function都呼叫一遍
就能輕輕鬆鬆的 100％ 了呢～
某種程度上來說的確很表面很沒意義
要如何讓這個數字具有價值也更有意義呢？
良好的物件封裝是 Production code 最基本的設計需求。
擁有良好的物件封裝，才能擁有更符合 FIRST 的 Unit Test。
一般測試會有三種需要驗證的狀況，最麻煩的物件互動該如何驗證？
該如何設計才能保持測試的獨立性，提高程式的可測性？
測試框架能夠提高撰寫 Unit Test 的便利性，增加導入的誘因！
好框架，不用嗎？
Unit Test。
從踏入軟體工作就聽過的名詞～
但以往只知道是小小的測試，就是要補一堆很廢的文件
以示對自己程式碼的負責。
腦中浮現的就是很不想面對的名詞，但又好像聽起來很有道理必須面對。
回想過去，沒有好的工具、沒有明確的 Unit Test 定義，完全就是放給他爛
最近自己也開始著墨這個部份～ 上完課終於有全面的瞭解啦！！
