Bowling Game Kata

看了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題目

書 - 完美程式設計指南

Ch2 自我維護
程式釋出前都要做unit test,即使是只改一點點

測試人員存在的目的是找尋程式員沒找到的錯誤，寫程式的人應該自己找尋自己製造的臭蟲。

coding時
1.用防禦性程式寫作,但別隱藏錯誤(bug)
2.加上除錯檢查(ex:assert) - 印出錯誤方便debug

*維護程式的發行版跟除錯版。發行版用來打包發行，除錯版用來盡可能快速抓蟲。
*除錯檢查巨集是寫出除錯檢查的快速方式。用它們來捕捉不應該發生的非法狀況。不要把這些狀況跟錯誤狀況混在一起；錯誤狀況在最後的產品中一定得被處理掉。
*用除錯檢查巨集來核對函式參數，並警告程式原有東西是未定義的。你愈嚴格定義你的函式，核對它的參數就愈簡單。
*一旦你寫好了一個函式，把它重新檢查一遍，並問問你自己，"我假設了什麼條件一定成立的嗎？"如果你找到一個假設條件，用除錯檢查巨集檢查這條件是否永遠成立，或者重寫程式以去除這樣的假設。也問問自己，"程式中哪裡最可能出錯，我怎樣才能自動找到錯誤？"盡可能將捕捉錯誤的測試放在愈早執行到的地方愈好。
*教科書鼓勵程式員防禦性的寫程式，可是記住這種寫作方式會隱藏錯誤。當你寫出防禦性的程式時，用除錯檢查巨集來提醒你自己是否有"不可能"發生的狀況發生了。

Ch3 增強子系統
檢查你的子系統，問問你自己，程式員們可能會怎麼誤用它。加上除錯維護敘述跟核對檢查來捕捉不好找跟常見的錯誤。

如果你不重複找尋，就修不好錯誤。找尋任何可能造成隨機行為的東西，把它們從除錯版程式中拿掉。將未初始化的記憶體以某個垃圾值填滿只是一種去除隨機行為的辦法，那樣子如果有參考到未初始化記憶體的情形發生，你就可以在每次執行到出錯的程式時都能重複同樣的現象。

如果你的子系統釋放記憶體（或其他資源）然後製造垃圾，請清理被釋放的記憶體中的內容，讓裡頭的東西看起來像垃圾；不然別處的程式可能會繼續使用這些已釋放記憶體中的東西而不被察覺。

類似的，如果你的子系統有些可能會發生卻不一定發生的行為，加上除錯碼來確定這些行為一定會發生。讓每件事都發生過可以增進你捕捉到較少執行到的程式中出現的怪異現象。

確定你的測試工作在程式員沒注意到時都在進行著。最佳的測試方式就是那些完全不用在乎它們的存在的測試。

如果可能，將測試碼建立在子系統裡頭，而不要寫在它們上頭。不要等到子系統已經寫好了，才來想辦法查對它們的動作正不正確。對每個你考慮的設計方式，問問你自己，"我該怎樣徹底查對這個實作？"如果你發現幾乎不可能或難於測試這個實作方式，好好考慮一下是不是該換個設計方式，即使那表示拿程式大小跟執行速度為代價來讓系統可被測試。26

在拿掉一個讓程式跑得很慢或吃很多記憶體的查核測試前，多想一遍。記住，查核程式碼不會出現在發行版的程式裡。如果你發現自己想著，"這些測試太慢了（或太大了）"，停下來，問問自己，"我該怎樣讓這些測試繼續留著，而讓程式跑快一點（或變小一點）？"