是的，2020年五月，也就是一年前的 #TDD與持續重構 梯次，今天還有同學會在上面問問題，而我也樂於分享一下我的看法一起交流。
從他的發問例子，pull member up 加上 namespace 的 Money, 讓我想到他正在用 Ct 練習 Kent Beck 的 TDD by Examples part 1 的 Money Example.
所以順便分享了一下我覺得不要錯過的重點（美的地方）。
至於那個 builder 的視角，並不是書裡面寫的，而是我會想從 Expression 往下延伸嘗試的設計視角，這樣可以簡單的把一堆 計算 的內容跟組合封裝起來。
試過一次，覺得蠻有趣的，但畢竟不是真實產品等級，我的領域知識也還不足，不知道那樣的 builder 概念在該領域會不會碰到什麼不合適的使用場景就是了。
多嘗試，多從自己的輸出取得回饋，才能真的學到書本內想帶出來的知識點。
—
何況我還有 Kent Beck 可以請教 ❤️
補上在學員群組分享的片段：
—
好的抽象概念（隱喻）真的是可遇不可求，需要大量練習，如果大家有仔細看書的話，Kent Beck 也是在正式做這個例子十多遍以上，才領略到這個設計的角度。
這也是為什麼 一個足夠複雜 概念夠多的題目或需求，值得我們反覆練習
https://tdd.best/courses/classic-tdd-by-example-video-training/
我在這個影音課希望可以達到的效果也是如此，因為我自己一個語言做了十多遍（我目前有準備三個語言的版本 Java, C#, Python)，很多遍的設計角度都不一樣。
有一些在前面幾次直覺不可行的，在後面幾次的岔路時，我就決定走走看。
大部分直覺都是對的，但也有幾次走出很不一樣的路。
如果「只練一次」，是沒機會走出那麼多不同的設計角度的。
同樣的，如果寫程式太慢，或是取得回饋的週期過長，你能嘗試的設計方案就會跟著變少，能學到的東西變少，同時要追求「剛好且簡單」的解決方案，機率就會變低。
大家可以想想，如果是自己在做 Money Example, 在真實世界有時間壓力底下，可能這輩子都不可能想出這樣簡單的設計方案。
如果都只在真實工作才學習、練習，那技能就會一直停滯。
永遠都只能用那種直白、procedure式、脆弱的流程設計角度，因為只會這種方式，自然自己最快的完成方式 就只會有這種副作用、複雜度最大的設計方式。
所以要多練 讓自己有多種視角，TDD 也是一種先從使用端來設計的視角，所以易用性的設計角度，物件的互動角度才能在這種視角被凸顯出來。
python後面補0 在 Re: [問題] GUID 字串格式轉換- 看板Python - 批踢踢實業坊 的美食出口停車場
※ 引述《LwHow (Do)》之銘言：
: 0x798ffd60, 0xf10e, 0x4ac4, 0x89, 0x39, 0xc8, 0xbe, 0xab, 0xfe, 0x55, 0xb4
: 798ffd60-f10e-4ac4-8939-c8beabfe55b4
: 有一個重點就是，格式必須要符合寬度
: 例如 第一組資料如果是0xffd60，則我們必須把資料補滿為
: 000ffd60-xxxx-xxxx-xxxx-xxxxxxxx
: 其他欄位以此類推
我沒看你的程式, 不過按照你的需求, 假設最後面那組也是補 leading zeros
那麼可以這樣寫 (需要 Python 3)
# 把資料用逗號拆開, 每筆去掉前後空白和 0x 開頭
# 前三筆叫 first second third, 剩下的放到 rest_parts (會是個 list)
first, second, third, *rest_parts = [s.strip()[2:] for s in source.split(',')]
# 把 rest_parts join 起來叫做 rest, 然後組合成結果
# 每個 variable 後面的 : 代表資料格式, 後面格式符號的意思是：
# > 代表向右對齊
# 0 代表前面補 0
# 最後一位數字代表至少補到幾位
output = '{first:0>8}-{second:0>4}-{third:0>4}-{rest:0>8}'.format(
first=first, second=second, third=third,
rest=''.join(p.zfill(2) for p in rest_parts),
)
--
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.161.19.12
※ 文章網址: https://www.ptt.cc/bbs/Python/M.1500614456.A.B0F.html
... <看更多>