Odd-e CSD Course Day 2

最新推荐文章于 2020-12-21 13:53:55 发布

weixin_30915951

最新推荐文章于 2020-12-21 13:53:55 发布

阅读量63

点赞数

原文链接：http://www.cnblogs.com/KingJaja/p/8614796.html

版权

首先在第二天中其實談的更多的是在於 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

繼續閱讀 Odd-e CSD Course Day3

對課程有興趣的同學，可以到以下網站找到相關的資訊

https://www.odd-e.com/

转载于:https://www.cnblogs.com/KingJaja/p/8614796.html