有許多朋友透過上課跟參加教育訓練來加速自己學習成長的速度，而也有很多朋友常問我，怎麼樣可以讓上課的學習吸收效果最大化。
這篇文章簡單整理我的兩個想法：
當你願意身體力行這兩件事，自然知識就會從講師的外顯知識，到你的知識內化過程，透過回答問題跟文章記錄，就又會經歷一次由自己發動的外顯知識過程。這樣的經歷，才能確保自己真的理解。後續當然就是要透過不斷地練習，才能達到實務上真正的內化。
之前介紹了 Extract and Override 的技巧，使得不需改變 production code 對外的 API，也仍然可以在測試專案中建立一個 SUT 的替身，覆寫想要 isolated 的 dependency 就可以針對 SUT 做 isolated unit test 。
但手刻 SUT 的替身總是不如 mock framework 看起來便利，這篇文章要介紹使用 moq 來節省手刻 SUT 替身的 effort, 直接透過 moq 來 stub SUT protected virtual 的方法。
當想針對 github 上 repository 的某一個 branch 進行修改與 push 時，或是想要在本機切換 local git repository 的 branch 時，也可以直接在 Visual Studio 2015 設定。
介紹如何透過 Visual Studio 2015 直接連到 github repo，進行 commit/push/pull 等動作。
實務上撰寫的測試程式中，幾乎都需要針對 reference type 的物件或集合進行比對，然而大部分的 test framework 所提供的 Equals function 都是呼叫物件的 Equals()，也就是若沒有額外覆寫，仍然是比較 reference 的位址是否相等。
這篇文章介紹一個 Nuget 套件: ExpectedObjects，讓我們可以用簡單的 API 來針對物件、物件集合、組合式物件比較是否相等，還額外提供了部分比較的功能來因應實務上的需求。
什麼是 legacy code? 沒有自動測試保護的就是 legacy code 。
－Michael Feathers, 《Working Effectively with Legacy Code》
講直白一點，legacy code 就是沒爹沒娘沒靠山，被人射後不理的產物。
誰都可能欺負它、弄壞它，簡直就是一直像死了般卻仍在線上活著的產品程式碼。
如何讓 scrum 團隊透過 t-shirt size 來對專案範圍進行相對估算，使用 yesterday's weather 來評估團隊速率，進而估算出推估時程與預計的 deadline 之間落差有多大。
當專案面臨「插件」、「時程調整」、「priority調整」、「需求異動」、「作法異動」、「人員異動」時，就能以 estimation model 當基底來評估影響範圍，讓團隊能在在變化當下擬定眼前最佳化的決策，並提供相對客觀的資訊給 PO 與 stakeholder 溝通。
當瞭解單一個 story 怎麼使用 relative estimation 的原則估算出 story point 後，這篇文章將介紹怎麼運用同樣的精神，針對整個專案的時程進行推估。公式只有一個，而且再簡單不過了。
時程(schedule) = 範圍(PBI story points) / 速率(velocity)
為什麼要透過 The Three Laws of TDD 來限制 TDD 的過程，這近乎於不合理的三條限制法則，能帶來什麼好處？
TDD 是一種限制的美學。
在實務開發中，常使用簡單工廠（Simple Factory）以及策略模式（Strategy Pattern）來封裝實作細節，使得 context 流程抽象穩定，並達到開放封閉原則（Open/Close Principle, OCP）中所蘊含可抽換實作的彈性。
在 context 流程中，透過簡單工廠依據條件來取得 interface 的 instance 固然美好，卻往往因為與簡單工廠的 static function 直接耦合，而導致這段 context 流程無法進行 isolated unit test。
這篇文章的小技巧，就是要解決 developer 因可測試性而廢棄簡單工廠不用，反而大費周章改用抽象工廠（Abstract Factory Pattern）的問題。
對於第一次接觸 Scrum 或 Planning Poker 的團隊，在一開始的估算過程中，往往會產生一些摸不著邊際或尷尬的場面。大家不曉得到底該怎麼比較，比較的基底為何？我這樣估會不會跟大家不一樣，不一樣時是不是應該從善如流，下一次就跟大家估一樣？當估得比其他人高時，是不是我就顯得能力比較弱？這些疑惑，會使得團隊成員不容易享受於輕鬆輕快的估算流程，而影響了團隊的節奏。
因此，本篇文章將介紹一個基於相對估算的簡單遊戲：Dog Point。透過把軟體開發中的 story 轉換成小狗的情況，來幫助大家瞭解估算的運作方式、意義。
當 legacy code 不具備可測試性，又想為其建立 isolated unit test 且不影響所有使用到這個 class 的場景端，可以透過 extract and override 的手法，使用繼承+覆寫，就能達到很有效益的 isolated unit test ，是針對 legacy code 撰寫 isolated unit test 最好用的技巧之一。
要怎麼估算需求需要多費多少時間完成，要怎麼讓 PM/PO 與 team 可以快速達成共識，要怎麼避免人事物的干擾因素，這篇文章說明了在 Scrum team 中估算的方式、時間、效益、參與人員等…即使不是使用 Scrum ，也可以依據這些概念來找到最適合您們團隊的估算方式。
[.NET]快快樂樂學LINQ系列－Aggregate() 簡介
[SpecFlow]在測試程式中比較單一物件與物件集合
[.NET]快快樂樂學LINQ系列－Zip() 簡介
[Unit Testing]如何驗證兩個自訂型別物件集合相等
[Web Testing][Tool]FluentAutomation (More Behavior-Driven)
[ALM]Code Review Guidance
