首先在第二天中其實談的更多的是在於 Test-Driven 的部分，而第一天談的偏向如何寫出一個好的 A-TDD 案例
但在第二天開始，就不太會照固定的 Topic 進行講述，而且讓團隊成員就像一個真實的 Team 一樣， Daily meeting 、 Work with pair programing、 Choice task 等等
但我一樣將在過程中學習到相關的內容，分別整理到以下四個 Topic
Continuous Integration and CI Systems
在提到 Continuous integration 與 CI Systems 時，更多時候提的是
如何 Continuous integration
何時 Continuous integration
誰做 Continuous integration
而不是在提如何建構一個高效的 Jenkins pipeline 、如何設定 C# for Jenkins Building
在談如何 Continuous integration 時，其實一併就將其它要點做說明了。
簡單來說Continuous integration 其實代表的是團隊對於品質與交付的承諾
比如：團隊會頻繁的做 Check in 、每個小時都做一次、每個人都可以做。
如何思考團隊成員一起做到 Continuous integration 才是首要的任務
在這個例子中提到了 Google 的 Repository 只有一個，
也就代表著每個人都可以做 Git commit、push 、pull。但這當中也需要思考的是，我們是不是也要一個 Repository 就好？ 一個 Repository 放置所有的 Project 其實意味著，這些 Project 之間的相依性很重。也許就需要一個 Repository 來綜觀全覽，但現實中不一定如此
在這裡 Terry 跟大家提了一下，他們目前發佈新版本到 Production 環境上，包含測試完成只需要約六分鐘
Using your IDE
在這個環節中，我只能說 Resharper 真的蠻好用的…看到團隊成員用熱鍵 Move class 、 Inline variable 超快的…但我自已平常實在沒什麼用到，只有少少的重構時能用個 Rename 之類的
不過在這個環節中…在練習 Test-Driven KATA 時，專案居然被我玩壞了 (好險靠夥伴快速的又修復了)
Test-Driven Development
這當中 我們用了 buzzbus 題目做為 Kata 來練習 Test-Driven
也因為自已習慣使然，在寫 Just enough code 、Just enough test case 時，還是會想的太多太難
在這一課收獲我想是最多的，一個是 Just enough test case ，如何寫出下一個剛好的測試案例而不前進太多步是很難的。例如： 以 buzzbus 為例，當上一個 test case 為 inputNumber5 時，我下一個寫出的是 inputNumber15 ，這就超過太多了 ( 比較好的是寫 inputNumber6 ) 。
此外一個剛好的測試是可以在短時間寫完的，比如說五分鐘內就可以完成
當然在中間練習 Kata 的過程中，我們會在每一次寫的同時提到是否要重構
在重構的同時，我們也會移除原本一些重複到的測試案例，不僅僅是重構Product Code
而重構其實隱含著，在添加新的測試案例之前進行重構，可以讓你更容易的加入新的測試案例
from: Odd-e CSD course
中午吃飯時我問了 Terry ，我以為在寫測試只需要寫個大概就好，但事實上是你的心裡會先有一個預期的設計，透過測試去驗證你的設計、明白預期中的設計與實際上的落差有多少，也就是說我們透過 Testing to Learn 。而最有趣的是，在每一次寫測試往預期中的設計前進時，你的 Product code 會越來越泛化 。這是什麼意思呢？
Terry 解釋的很明白，一開始在寫測試時要記得 just enough 。 如果能寫 hard code 就寫 hard code ，當 hard code 不行時就寫個 variable 變數，再不行時就寫個 If 再往下時可能是個 for loop
當往預期目標前進時，就會發現測試案例與Product Code會越來越往泛化前進
以程式來說就像這樣 ： Harcode –> int num –> if (num) –> for in numbers –> List<T>
而這當中我也問了一下，如何拿捏泛化的程度？ 事實上跟目前 Business 也有關係，如果現在只要 A B 功能就行了，那麼就不用想到 C D E ，但如果你做到了 A B C 很有可能就要考慮 D E 情境了
但如果一開始就做完了泛化，意思是目前只要 A B 的功能，但你直接做完了 A B C D E
很有可能在之後的 C D E 情境發生時，你認為這個已經是好的設計，而不會去寫測試。
當需求變更時也就不能受到保護了。
所以透過 Test-Driven 事實上是更好的認識自已、從自我中學習的一種方法
此外，有經驗跟沒經驗的工程師的差別在於，有經驗的工程師會用測試去驗證預期的缺陷與差距，而沒有經驗的工程師通常就會認為這就是最好或是預期中的設計了。
事實上，從來沒有完美的設計，只有當下最好的設計
Testing Mistake
下午我與小夥伴在寫 Acceptance 的測試案例時，因為在討論 Function 是否應該回傳處理結果，引發 Terry 與我們做了一下討論。原因是他發現到我們是在討論 Class 的內容，而不是由最快最簡單的 Controller 來進行我們的測試案例撰寫。測試也是類似的想法，可以先由較簡單的 E2E 測試開始，再往 Unit Test 前進 。 記得一個要點 Just Enough Design and Testing
from: Odd-e CSD course
此外，Terry 也建議我們在討論 Function 是否應該回傳處理結果時，可以考慮 CQRS 方式來進行
將處理的Function 定義為 Command 而回傳結果這類的為 Query ，這裡其實有點 Pure function 的味道存在，因為不論 Query 執行多少次，都不會影響到 Command 裡的執行邏輯。但如果合併在一起時，很有可能 Function 就會因為要處理狀態，而改變了執行邏輯
回顧
在今天回顧的時候有提到幾個蠻有趣的東西
1. Task 衝突演變成關係衝突，原因是當 Task 沒有做好充分溝通時，比如相依性這件事團隊沒有好好的討論與解決，很有可能下一次就演變成關係衝突。一但變成了關係衝突，夥伴之間的合作就很難繼續下去了！
2. 在第一天中其實有介紹了 Working agreement ，Stanly 提到這其實是一種 Guideline ， Guideline 的意思是參考用，不一定要遵守。不像 Rule 這是必需要遵守的而且有可能會有懲罰
在 Working agreement 中，團隊成員是可以自行調整內容的，當然這也需要經過每一個成員投票來決定
3. 最後 Terry 提了一個 Feature not User Story 的問題。問題是這樣的 ： 為什麼 Cucumber 以前的擴展名是 .story 後來改成了 .feature 。 至於答案是什麼就留待看倌們先找找了 XD
對課程有興趣的同學，可以到以下網站找到相關的資訊