看了Uncle Bob的建議，每天想來練一下Kata
而Uncle Bob又力推Bowling Game，所以原本想拿來當kata練一下不同的語言
沒想到實做之後，才發現這是個滿棒的kata
邏輯不會太難，但可能寫成超複雜的，滿多重構的行為，而且很適合當TDD的教材
把所有的team member都抓來練習一下
以下整理最近帶team member的心得
- Refactoring (clean code)
- 變數、method的命名
刻意讓team member命名滾球、局數
最後讓大家猜別人命名的意思
最後讓大家直接用保齡球的術語roll, frame
clean code: 不懂時，直接請domain expert命名，至少以後domain expert能夠說出這是什麼
- redundant code
去除重覆的程式
- decompose condition
讓程式變的更加clean, isSpare,isStrike,getSpareBonus那段
- 隱藏細節
上一段的延伸，有些team member把整段getSpareBonus做成calSpareBonus
感覺上沒什麼差，但在看code感覺差很多
- calSpareBonus
這個function叫做score(算總分)，因此這function最重要的事就是"算分數"
但這裡把算分的邏輯隱藏了，因此未來看code的人,不易注意到score被其他function異動了
int score = 0;//成員變數 - 總分
public int score(){
//略
if (isSpare())
calSpareBonus();
//略
}
- getSpareBonus
關於score的異動，能夠清楚掌握
而Spare的Bonus算法在這不重要，因此隱藏起來
讓程式更容易閱讀
public int score(){
int score = 0;//總分
//略
if (isSpare())
score += getSpareBonus();
//略
}
- Pair-Programming
自己開發會有盲點，跟幾個同事練習的過程中
在算跨局的輯邏會想的滿複雜的，但partner會參與討論 也許沒能討論出更好、更簡單的解法，但至少那段神邏輯有另一個人"看的懂"
- TDD
只滿足目前的需求即可
開發上，大家容易被分數算法綁住，因此一開始想把邏輯寫對
但這不太容易，因為算法還得考慮Spare, Strike，因此一次要把邏輯寫出來有點難
寫完，你也不會寫test case了，因為已經寫完繳卷了
這點最適合TDD指的只滿足目前的需求即可
先寫個最簡單的算法驗證，再來spare，再來strike，一個個拼出完整的邏輯
也許整個寫法得翻掉重寫，但令人放心的是test case已經寫好了
所以可以放心重寫
雖然一直說TDD很棒，但沒實際體會過，大家只會覺得很難達成
實際經歷好幾次的大改結構，但重新測試的時間，卻只是一瞬間
大家就能體會TDD好處
回想其實好久以前就看過這Bowling Game的練習(很多對話那個)
不過就只有用"看"的，沒有實際寫過，身體力行的體驗果然不一樣
大家也來kata一下
p.s. 不過我以為這保齡球算法的方法大家應該都瞭解
沒想到大家都忘了... 話說上次打應該也是5年前了...
更多的Kata題目
