andy74139 / tdd91_hw2_shoppingcart Goto Github PK

大部分 comment 都在各 commit 裡，幾點建議：

• API 在一開始就得依據已知的所有需求進行設計，所以在寫第一個紅燈時，API就不會隨便開。
• 最後的 PotterBook 那一堆 class 跟 interface 都是 over design，因為沒有意義，它就是 Book, 只是名字不一樣。
• 最終的 production code 命名看得出來試圖讓程式碼可讀性提昇，但對理解算法上幫助不大。
• 最大的問題在於，紅燈、綠燈的過程，綠燈都是一路硬幹，到最後再一次針對完整需求進行重寫。這樣是白費力氣。可以參考下面的 sample solution 歷程。

---

Sample Solution

2016 舊版

https://github.com/hatelove/PotterShoppingCart/commits/anotherRefactor
我的演算法也寫得不夠好， 但對外的 function 主流程很清楚：

1. 防呆
2. 整理出有幾套書
3. 加總每一套折扣完的總價

2017 版本

2017 新版 production code 作法 (中間過程因為一些緣故有漏 commit 檔案)

1. 取得總共幾套
2. 每一套依據折扣計算出該套金額
3. 加總每一套的金額

TDD 演進過程主要步驟

1. 產生 production code API
2. 計算總價 = 單價 * 數量
3. 計算一套的金額 = 總價 * 折扣
4. 將所有書分成 N 套
5. 對每一套計算折扣金額後加總

API設計要點

你在動手寫任何 code 之前，應該有眼前已知完整的需求，以這為前提，在第一個紅燈時把 API 設計好。既要考慮到眼前已知的所有需求，又不能腦補可能發生也可能不會發生的需求，並以需求的 domain 為主軸，命好名字，考量該怎麼用，API 才具備易用性，呼叫端才是最方便使用的。