fcamel's blog

為什麼要寫 unit test？為什麼要先寫測試？

2009-06-13T01:02:40Z

這篇說明寫 unit test的好處，以及為何先寫 unit test 再實作，比實作完再補 unit test 更好。這裡先列出摘要：

測試碼可以簡省手動測試的時間，但有錯時無法告訴我們錯誤的源頭在那。
unit test 可以告訴我們錯誤的源頭在那，可是 unit test 有時間成本和維護成本。寫過多 unit test 反而有害。
TDD 藉由先寫測試避開 unit test 的成本問題，並帶來其它好處。

為什麼要寫測試碼？

吃燒餅那有不掉芝麻，寫程式自然要驗證程式是否正確。想像平時我們如何驗證程式？大概就是寫一寫，執行看看，看看輸出符不符合預期，換些不同輸入，再看看結果，有錯再改，改完再重跑．．．。測試碼可以協助我們自動化驗證，省時省力。

也許有人會懷疑寫測試碼不划算，功能常改變，到時測試碼又要重改。這個問題視情況有不同種解法，比方用較「便宜」的方式寫測試，像是準備好輸出入檔，用 shell script 執行，配合 diff 看輸出是否一致。或是用 scripting language (如 Python) 寫簡單測試。而更根本的解法，個人認為是配合 TDD，待後面說明。

手動執行測試，執行個三十年，每次花的時間還是一樣，也許還會因為手酸變慢。但寫測試碼則相反，我們會愈寫愈快，愈寫功能愈好。

為什麼要寫 unit test (單元測試)？

首先介紹不同級別的測試碼，由小到大依序為：

unit test：測試對象為單一函式。
integration test：測試對象為數個單元函式的複合體。我沒特別區分這個和 unit test [*1]，以下兩者一起用 unit test 表示。
system test：測試整個系統。
acceptance test：客戶驗收用的測試。將使用情節或使用需求轉成 acceptance test，藉以確認產品滿足客戶要求，方便起見，以下以 system test 統稱。

備註 *1：在談論 mock 時，unit test 和 integration test 的差異較明顯，本文不談這個議題，總得讓大家有意願寫測試，再來談如何寫測試才有意義，你說對吧。

以測試的觀點來看，system test 的 test case 夠多，system test 應該能涵蓋到大範圍的產品碼，如此一來也達成我們一開始提的「驗證」目的。從實務觀點來看，寫愈多測試碼，負擔愈多，規格變動時要改的東西也多。更何況 unit test 著眼點更細，變更實作方式也有可能得改 unit test。如此一來，為什麼要寫 unit test？

首先，unit test 著眼點比 system test 小，也意味著當測試結果不對時，unit test 可以指出更明確的問題點，而 system test 只能粗略地和我們說輸出不對，接著我們得比對正確和錯誤的輸出，開始推測 bug 在那，並用 debugger 設中斷，或在程式內輸出訊息一步步找出問題源頭。相信大家都能明白除錯的痛苦。而 unit test 可以協助我們釐清那些程式是對的，那些是錯的，將問題範圍縮小。若 unit test 寫得好，幾乎用不到 debugger 和輸出訊息，光看那個 unit test 錯誤，就知道 bug 在那。

除了幫自己省時間外，unit test 也可幫助別人維護和理解程式。維護的人不如自己熟悉，難免不小心改爛程式，unit test 可以減少這類問題，也讓原作者安心給其他人修改。新手要閱讀程式時，unit test 可看成是各函式的使用範例，相信大家都同意讀例子比讀全部程式碼來得容易吧。好的範例有時比註解還有用。

為什麼要先寫測試？

好吧，若讀者大人耐著性子看到這裡，想必已對測試碼已有些心動，也認為寫 unit test 有那麼幾分道理，那先寫測試和後寫測試有什麼差別？若後來寫的程式不管用，需求變更，先寫測試不是搬磚砸自己的腳，自找麻煩嗎？事實上正好相反。

我們得先問自己，為什麼程式會不管用？為什麼需求會變更？去除客戶或主管找麻煩的因素外，一部份原因為思慮不週，寫的功能不夠貼近目標。如同產品一般，沒試用過我們不會明白產品的缺點在那，函式也是一樣。先寫測試碼就是先想像要如何使用即將要寫的函式，在寫測試碼的同時，我們同時也在設計函式。有時會發現難以測試，而想出更簡潔的介面。當我們能輕鬆寫出測試碼時，也意味著目標函式易於使用，之後才方便重用。

再者，先寫測試，相當於先列需求，規範中的輸入為何？預期輸出為何？可能有什麼例外情況？於是，我們接著寫出的程式，一定是有用的。我們不會忽然想說「要不要加個 foo()，之後大概會用到吧。」先寫測試，確保之後寫出的每一行產品碼都是有意義的。同時，我們寫的測試碼也是有意義的，若事後再補測試，不明白加入一個 unit test 有何幫助，有時會多寫不必要的 unit test，如同前面提過，測試碼不是萬靈丹，它也同時是負擔，需求變更時，有時也得一併改測試碼。

除幫助設計、減少寫冗碼的機會外，先寫測試還方便我們之後進行重構。沒有測試碼的重構是很危險的，而沒重構的程式碼也是很危險的 [*2]，就像在底層不穩的地基上不斷加蓋偷工減料的高樓一般。先寫測試的好處還有一點，早寫早享受，先寫測試，就能先自動化驗證，省去所有手動驗證。

備註 *2：為什麼要重構？這是一個值得獨立討論的議題，主因為減少隱藏的 bug 和強化程式碼的可讀性，並更容易重用，以及增加新功能。詳見 Martin Fowler 寫的《重構：改善既有程式的設計》

綜合以上所言，先寫測試花費的時間，可以攤算在設計時間，以及減少寫無用程式、減少手動驗證、縮短除錯的時間，所以先寫測試不見得會增加額外時間，我們只是把投入不划算事上的時間，先拿來寫測試。

特別加贈：何時該寫新的測試碼？

雖然寫測試好處多多，也別卯起勁來狂寫，最後卻覺得投資沒回本，浪費過多時間寫測試。遵照 TDD 的原則，先依規格寫測試，別浪費時間寫也許有用的測試。

那麼，何時才是跳出 TDD 迴圈，另外加寫測試的時機呢？依我個人經驗，我發現以下三個情況，都是寫新測試碼的好時機：

在程式裡輸出訊息找錯誤：與其花時間寫 print、看輸出訊息、再回頭砍掉 print，不如寫個 unit test，之後能持續受惠。
執行 debugger：同上，你還是得花時間設中斷，一步步看訊息，不如寫個 unit test，之後能持續受惠。
不知錯誤在那，該如何進行下一步：這表示一次貪心實作太多功能，把目標縮小，一步步補 unit test 吧。

另外，在解 bug 時，先寫個 unit test 重製問題，再開始除錯。如此一來可確保自己明白成因，之後同樣的 bug 也不會再出現。

超級加贈：若 TDD 這麼好用，為啥它不遍及？

施主，這個問題得問你自己啊，快來加入推廣 TDD 的行列吧！

說正經的，雖然上面將寫 unit test 和 TDD 說得如此美好，寫 unit test 不是簡單的事。若寫得不好，就會有「改變實作，也得改變測試」的副作用，或是測試執行過久，不方便反覆執行，或是寫出無用的測試。如同學習 design pattern 一般，unit test 也有 design pattern，對沒接觸過寫測試碼的人來說，相當於要花「兩倍」時間學習。加上前面提到大家可能有的誤解，使得 TDD 難以落實。

另一個可能是，若你的組織同時有兩批人馬對同一產品進行開發和除錯，程式碼分成兩個 branch：一個加入新功能，一個除錯。重構會造成程式碼難以合併，決策者因而選擇不頻繁重構。並且，這類組織可能有龐大的人力另外進行測試 (可看成是 system / acceptance test)，而誤以為不需要 unit test。

然而，長遠來看，第一個理由顯然是偷懶，只是把現在的問題延後到日後再解決。趁早把除錯的時間省下來，投資到 TDD 這積優股吧。第二個情況可能是公司考量，專業分工使得公司容易找人和培訓，我沒在這類公司工作的經驗，不知能如何對應。

詳細的 TDD 風險，可參照 What is the downside to Test Driven Development?。結論是團隊要有熱情學一堆新技術，或是有個經驗老道的開發者帶才適合用 TDD。不過，我個人的觀點是，現實世界的選擇不是非一即零，不是所有程式都能 TDD，若成本過高用 TDD 不划算，那就暫時別花時間學相關技巧，挑軟柿子吃。至少，有用 TDD 的部份就能享受到 TDD 帶來的好處。別因為一些可能想見的問題，而全盤否定使用 TDD。

我對 TDD 充滿熱血，請問如何入門？

好吧，這個標題是我寫來自 high 的。若有興趣的話，可以參考 The Bowling Game Kata 的投影片，由設計保齡球計分程式的小例子，一步步展示 TDD 進行的過程，相信跟著例子走一次必能有所啟發，親身體驗 TDD 如何帶來新設計。若能自己先寫一遍，再來看投影片，感受會更深。或是參閱我之前寫的介紹文：《TDD 推廣：背景知識和簡介》以及《最近用 Python + TDD 心得（與 Java 做對照）》。

以有涯逐無涯，殆矣。

2009-05-11T15:14:05Z

近幾個月學習狀況不錯，學習效率好也能持久，但總覺得愈學愈多，愈學愈累，偶爾會有種茫然的挫折感。忽然想到莊子的這句：

吾生也有涯，而知也無涯。以有涯逐無涯，殆矣。

原本我曲解了這段話，還振奮了一下，想說要更認真地追求知識。忽然，我發現莊子的本意反而是點出恰到好處的生活方式，於是我的世界改變了。

體悟到這點後，我決定晚上十點後停止電腦科學相關的學習，改看看動畫、或翻翻閒書，或偶而像這樣寫寫 Blog 也不壞。待之後多存點錢，買了電鋼琴還可以來個「彈琴復長嘯」。不知為何，我覺得自己可以用更自在的方式追求更深的知識，讓生活過得趨於平衡。

忽然，又有兩年半前相似的體悟，到外邊小晃了一圈，我似乎走回正確的路了。即使不知道方向，不知道終點何在，我明白自己正踏在想走的路。

題外話，看到現在學習程式語言和機器學習的進展，不禁懷疑過去為何期望這麼久，卻遲遲沒有行動。才想起以前還有許多想做的事，像是增加電腦科學的廣度認知、寫 3D 遊戲、參加各式比賽、做研究寫論文等。許多事若沒有親身嘗試，只會念念不忘，難以打消念頭。經過前幾年的嘗試，才能像現在般沉澱心靈，專心在最有興趣的幾個點上。

空之軌跡

2009-05-02T06:23:38Z

如果不全破的話，是不是故事就可以持續下去永不結束？玩完《空之軌跡》系列後，這樣的想法浮現在我腦裡。這是去年十一月、十二月的事了，愈是喜歡一個作品，愈難下筆。

《空之軌跡》是 Falcom 公司出的系列作，分別為《空之軌跡 FC》、《空之軌跡 SC》、《空之軌跡 The 3rd》。FC 和 SC 的劇情直接相連，當初全破 FC 後發現劇情急轉直下，嘴裡雖然碎碎唸罵著 Falcom 沒天良，還是立即買了 SC 回來玩。沒想到 SC 故事又比 FC 更龐大，算算兩部玩下來，花了我一百小時，這輩子從來沒這麼密集地玩同一作品。

全破 SC 後，全身充斥著滿滿的感動，又一次地為自己無法以言語表達感動而感到無力，很想分享澎湃的情感，卻擠不出一個字來。就像做了一個很長很美好的夢一般，夢醒後又回到現實世界，接著是深沉的失落感。為了紓解這種失落感，只好上 ptt 看著大家的心得，放著《空之軌跡》的背景音樂，透過不同人從鍵盤下傳達過來的感動，暫時沉浸在《空之軌跡》的世界，直到心情恢復平靜。

只是，一聽到劇中音樂時，又會陷入短暫地感傷，懷念著約書亞、艾絲蒂爾等人。劇中主題曲的歌詞寫得很好，配合歌詞聽音樂，很自然地融入當時的情景。想說的話太多卻無法述諸文字，只好藉由音樂穿插帶出我片段的感受。

《銀の意志、金の翼》，這首當作早晨起床音樂挺不錯的，情緒會很 high。FC 尾聲出現這首時，立即提昇戰鬥氣氛至最高點。

《星の在り処》 (星之所在)，FC 片尾曲。配合歌詞聽著，想到艾絲蒂爾當時的感受，眼眶情不自盡地溼了。 ( 含歌詞的版本見這裡，畫質音質較差。 )

《I Swear》，SC 片尾曲。SC 的結束，暗示著艾絲蒂爾等人的旅程暫時到一段落，今後她們也會繼續活躍著。整首歌充斥著希望，但想到故事到此完結，失落感也隨之來襲。

於是我忍不住買了 The 3rd，只為多看他們幾眼。劇情方面，The 3rd 穿插許多支線劇情，帶出各角色之後的發展，大大滿足玩完 SC 的失落感。不過主線劇情相較 FC + SC，遜色不少。在看完 The 3rd 的片尾，畫面上映出「Thank you for playing」的字樣時，我更想和制作小組道謝，謝謝他們做出這樣感人的作品。也不禁想著，那一天我才能參與這樣的大作，將我的感動傳出去呢？

最後，以 The 3rd 的片尾曲，《空を见上げて》，做為結尾吧，可惜只有音樂無畫面：

再見了，《空之軌跡》，謝謝你帶給我這段美好的日子。期許著有那麼一天，我也能將你傳達給我的感動，透過我的雙手，制作出足以感動他人的作品。

Python 排序的技巧

2009-05-01T17:23:08Z

用 Python 排序時相較於 C、Java 多了效率議題。由於 Python 內建函數 (built-in function) 是用 C 實作的，排序時盡可能用內建函數效率會快上不少，詳細的數據比較可以參見 Python Cookbook，這篇做個簡單的整理。

背景知識

本篇需要 list comprehension 和 map 的基本觀念，若不清楚的話可以先了解它們再往下看。

排序 list 和 dict

先來看程式碼：

d = { 'a': 2, 'b': 1 }
# return keys ordered by key
print sorted(d)                                      # ['a', 'b']
# return values ordered by key
print map(d.get, sorted(d))                          # [2, 1]
# return keys ordered by value
print sorted(d, key=d.get)                           # ['b', 'a']
# return values ordered by value
print sorted(d.values())                             # [1, 2]
# return (key, value) pairs order by key
print sorted(d.items())                              # [('a', 2), ('b', 1)]
# return (key, value) pairs order by value
print sorted(d.items(), key=operator.itemgetter(1))  # [('b', 1), ('a', 2)]

上面的程式列出所有排序 dict ( 在一些語言裡稱為 hash table) 的方法，這裡用到幾個技巧，分別說明一下。

return values ordered by key：Python 的 method call 其實和 function call 差不多，obj.func(x) 相當於傳回 func(obj, x)，所以 d.get 一樣可以傳進 map 裡，結果是會取回 d 的 value。關於 function 和 method 的說明，可以參考《理解 python 的 method 和 function 兼谈 descriptor 》

return keys ordered by value：同上的技巧，注意參數 key 有做最佳化處理，使得 d 的每個元素只會呼叫一次 d.get ( 而不是比較次數 O(N*logN) 次 )，不用擔心取 key 的函式會被重覆執行。

return (key, value) pairs order by value：這部份的 code 和排序 list 一樣，關鍵在於用了 operator.itemgetter，它的文件說明摘錄如下：

Return a callable object that fetches the given item(s) from its operand.
After, f=itemgetter(2), the call f(r) returns r[2].

以程式碼來表示的話，類似於這麼寫：

1 2	def itemgetter(n): return lambda r: r[n]

只要資料轉成 list of lists 的形式，就可以用 operator.itemgetter 處理。轉成 list of lists 的時間和資料數量成正比，相對於套入用 python 寫的 comparator 來說，快上不少。module operator 裡有許多好用的函式，在套用 map、max、sort 等內建函式時，可以配合使用，一來不用自己重寫小函式，二來內建函式用 C 實作，速度快上許多。

Decorate-Sort-Undecorate (DSU)

若要比較的方式比較複雜，像是希望有 stable sort，或是比較的 key 不只一個，可以套用 DSU 的解法。這裡以 stable sort 為例 (程式引用自 Python Cookbook)：

def stable_sorted_copy(alist, _indices=xrange(sys.maxint)):
    decorated = zip(alist, _indices)
    decorated.sort()
    return [ item for item, index in decorated ]

DSU 的關鍵在於先把每筆資料轉成 [key1, key2, ..., original item] 的形式，如此一來內建的 sort 就會依 key1, key2, … 的順序排序，排好後再取回 original item。同樣的，排序 object 依欄位值或 method 傳回值，都可以套用 DSU。而 stable sort 的情況比較不同，是將資料轉成 [original item, original position ]，排序後再取回 original item。

附帶一提，xrange 是 generator，使用 generator 好處可以參見 PEP 289: Generator Expressions。

參考資料

Python Cookbook 第二章 Searching and Sorting：有詳細的例子一步步解釋各種寫法，並分析優劣。
Sorting Mini-HOW TO - Sorting by keys：這篇比 Cookbook 的介紹精簡許多。
Functional Programming HOWTO：這篇清楚地說明許多重要的基本觀念。

備註

發表這篇後，才發現去年的今天我在寫 Ruby。物換星移，忽然有淡淡的懷舊感傷。

關西行：廁所大賞

2009-04-28T13:49:49Z

從日本玩回來都快過一年了遊記還沒完成，還是直接寫最有興趣的這篇，剩下的就隨意吧。

說到旅遊方面的事，我可能沒什麼特別自信，但去一個旅遊景點先找廁所這件事，我可是很在行呢！這回去關西特別搜集了多所精美廁所外觀，在這裡和大家分享一下。為什麼沒拍廁所內部呢？一來是內部沒差太多，都是現代化設施；二來是我不想在一個人旅遊時以妨礙風化的罪行被逮補。這次的特集裡，最可惜的是沒拍到清水舞台下面的廁所，那間可說是此行中的冠亞軍之選，但人潮太多，我在那等了十多分鐘都抓不到拍照的時機。

廢話不多說，首先是金閣寺的廁所：

所照片所示，以金閣寺的名聲來說，未免太普通了點，失敗失敗。

上面這張是龍安寺石庭旁的廁所，也是相當普通。再來這張就有點意思了：

仁和寺的廁所看來比較有點格調，為了怕我自己認不出來是廁所，故意選照得到水管的角度。以在關西的第一天來說，就仁和寺的廁所有在水準之內。希望這些水準低下的廁所外觀沒有掃了大家逛大阪的興致，比較正常的風景照和介紹請參見《關西行：抵達京都、前往洛西》。

再來這張是風俗博物館內部的廁所，由於該館很小，外觀．．．就是一扇門，只好改拍內部意思意思，可以看到中間還放了幾個小裝飾。喜歡源氏物語的人可以去看看，詳見之前寫的《關西行：京都洛中》。

再貼這類照片下去，相信大家很想關網頁了，只好提前先拿出最有冠軍相的平等院廁所！

是不是看起來相當雅緻呢？而我個人相當中意的伏見稻荷大社，相當地可惜，山中的還算上得了檯面，可是在人潮多的神社旁邊，卻是相當現代化的外觀，真是太不專業了。

( 神社外的廁所 )

( 山中的廁所，拍這張花了我一點時間，雖然在山中，人潮也不算少 )

關於上兩間廁所之外的正常介紹，請見舊文《關西行：京都洛南》。

下面這兩張是二条城的廁所，馬馬虎虎，將就將就啦，護城河和城牆這麼美，為什麼廁所卻沒那種霸氣呢？

而下面這張現代化的廁所，竟然位在清水寺，裝個屋瓦並不會改變現代化外觀的事實，真是太令人失望了。所幸在清水寺下面的廁所相當雅緻，為清水寺扳回一些面子。只可惜人潮過多我沒能照成，可說是本次旅遊的一大憾事。

這部份的相關介紹，請見《關西行：京都洛中二条城及洛東清水寺》

最後這張是大阪城公園的廁所，外觀看來頗為氣派，但如同水柱邊泛黃的痕跡所示，廁所內部實在太髒啦！

就這樣，本次的廁所大賞到一段落，感謝各位帶著被玷污的眼睛耐心看完。不知大家心目中關西最漂亮的廁所是那間呢？

最後的最後，我不得不說，TD-Post真是好用啊！

寫 Blog 好幫手 TD-Post！

2009-04-25T15:32:56Z

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 WordPress 吃的格式，順便藉機練習 TDD，沒想到寫了十小時才完成。剛好最近在看虎x龍的動畫，就將它命名為TD-Post (Tiger x Dragon Post) 吧。

緣起

換過多家 WordPress 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。

寫 Blog 最惱人的事有幾點：

得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。
加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 TDD 我就重貼了許多次。
無法用自己慣用的編輯器。若能用 Vim 寫 Blog，速度必能大增啊！

功能簡介

對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 PmWiki、DokuWiki、TWiki，其中以 PmWiki 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 Trac 的 wiki 格式。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。

接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，TD-Post 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 TD-Post 的位置， TD-Post 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。

程式下載

本程式採 BSD License ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 TDD 流程寫的，測試碼應該很完整。這裡是一些相關資訊：

下載：http://code.google.com/p/td-post/downloads/list
程式語言：Python
程式碼總行數：682 行
測式碼：346 行 ( 主要是準備測試的例子 )
非測試碼：336 行
實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。

其它

有原始碼有真相，最後附上本文的原始碼：

為了方便寫 Blog，寫了個小程式讀 wiki code 產生 [http://wordpress.org/ WordPress] 吃的格式，順便藉機練習 [http://en.wikipedia.org/wiki/Test-driven_development TDD]，沒想到寫了十小時才完成。剛好最近在看[http://zh.wikipedia.org/wiki/虎與龍_(小說) 虎x龍]的動畫，就將它命名為[http://code.google.com/p/td-post/ TD-Post] (Tiger x Dragon Post) 吧。
 
==== 緣起 ====
換過多家 [WordPress] 用的編輯器後，我還是找不到滿意的工具。為縮短寫 Blog 的時間，我決定自己做一個。
 
寫 Blog 最惱人的事有幾點：
 1. 得輸入麻煩的 HTML，特別是要匹配結束標籤特別麻煩。而且 HTML code 不易閱讀，改文章時很不方便。
 1. 加超鏈結很麻煩，常用的幾個超鏈結，得重附貼多次，像 [TDD] 我就重貼了許多次。
 1. 無法用自己慣用的編輯器。若能用 [http://www.vim.org/ Vim] 寫 Blog，速度必能大增啊！
 
==== 功能簡介 ====
對我來說，寫 wiki code 相當方便，所以輸入格式決定用 wiki code。但 wiki 格式有許多種，我比較常用的有 [http://www.pmwiki.org/ PmWiki]、[http://www.dokuwiki.org/ DokuWiki]、[http://twiki.org/ TWiki]，其中以 [PmWiki] 語法最簡單，但原始碼沒後兩者好讀。最後聽從 York 的建議，採用 [http://trac.edgewall.org/ Trac] 的 [http://trac.edgewall.org/wiki/WikiFormatting wiki 格式]。選它的主要原因除好讀好寫外，我特別喜歡它 Preformatted Text 的格式，很適合用來貼程式碼。
 
接著，針對第二點問題，加上自動補超鏈結的功能，只要寫過一次超鏈結，[TD-Post] 就會自動記下來，自動補上對應的位置。像在這段裡，因為我在第一段已寫過 [TD-Post] 的位置， [TD-Post] 的超鏈結都會自動補上。初步估計，以後寫一篇 Blog 至少可以省十分鐘，所以差不多用個六十次．．．這幾天的辛勞就．就回本啦。
 
==== 程式下載 ====
本程式採 [http://zh.wikipedia.org/w/index.php?title=BSD许可证&variant=zh-tw BSD License] ( 簡單說就是隨便使用 )，歡迎大家玩玩。雖然沒什麼註解，但我照 [TDD] 流程寫的，測試碼應該很完整。這裡是一些相關資訊：
 * 下載：http://code.google.com/p/td-post/downloads/list
 * 程式語言：[http://www.python.org/ Python]
 * 程式碼總行數：682 行
 * 測式碼：346 行 ( 主要是準備測試的例子 )
 * 非測試碼：336 行
 * 實作時間：原本預估兩小時完成，卻花了約十小時。大概是一小時查語法、一到兩小時寫測試。其中花最多的時間在解決 list 和 performatted text 的衝突，這部份從開始實作到結束花了三小時才解決。
 
==== 其它 ====
 
有原始碼有真相，最後附上本文的原始碼：{{{
#!html
_QUINE_
}}}
 
身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 [http://en.wikipedia.org/wiki/Quine_(computing) Quine] 那樣的技巧，只是單純地取代關鍵字。

身為資工人，這段原始碼當然也是自動貼上的啦，不過我沒用像 Quine 那樣的技巧，只是單純地取代關鍵字。

中翻英，線上翻譯測試－ Google Strikes Back！

2009-04-22T14:47:06Z

( 這篇寫於 2008-10-26，不知為啥從 Blog 裡消失了，所幸 Google Reader 裡有備份。 )

剛才無聊看看 Google Analytics ，發現本站最熱門的文章還是那篇《中翻英，線上翻譯測試》，我不知該說什麼，這不是件令人高興的事啊。總之，一時興起又來測看看。

最近 Google 翻譯似乎變強了，果然有在學習啊！輸入問題如下：

我要代替月亮來懲罰你

兩年前 Google 的回報令我很失望：

I want to punish you replace Moon

沒想到現在 Google 幾乎翻對了！

I want to punish you in place of the moon

google 一下會發現有不少人提到類似的句子，附帶一提，個人心目中最完美的翻譯是：

In the name of the moon, I will punish you!

其它家翻譯結果沒什麼變，就不再貼了。

另外再測了之前亂測的中文詩詞，有些變化，不過說不上是變好變壞，都很糟就是了。看來博大精測的中文仍是機器翻譯無法跨越的高牆，也是國高中生們無法跨越的牆啦。

強化 Python 在 Vim 裡的顏色

2009-04-23T02:02:06Z

我習慣用 putty 連 Unix server 開 screen，再用 vim 寫 Python。這篇記錄如何改善 Python 的顏色。

啟動 256 色 terminal

首先將可用的色彩數增加為 256 色，先確定 putty 為新版 ( 舊版 putty 沒支援 256 色)。接著參照《讓 Vim、Screen 支援 256 色》將 Screen 和 Vim 設好，記得先用文末提到的 Colortest 測試是否有符合 256 色，成功的話，數字 0 ~ 15 為原本的 16 色，16 ~ 231 為新的顏色 (6 x 6 x 6)，232 ~ 255 為新的灰階色。可配合 Colortest 看到數字值和顏色。

這裡備忘該篇提到的步驟：

在 ~/.vimrc 加入：
1
set t_Co=256

在 ~/.screenrc 加入：

1	termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'

更新 Python script 偵測的格式

更新 syntax/python.vim，讓 Vim 偵測出更多種格式，像是行末多的空白，或是空白行有含空格都會被偵測出來。做法如下：

下載最新的 python.vim 並放到 ~/.vim/syntax/ 下。
編輯 ~/.vimrc，加入
1
let python_highlight_all = 1
以顯示所有 python.vim 有偵測的格式。參照 python.vim 開頭的註解，了解細部選項。

替換顯示的顏色

下載 Vim color scheme: Wombat256.vim，並放到 ~/.vim/colors/ 下。
在 ~/.vimrc 裡加入
1
colorscheme wombat256

如此一來就有漂亮的顏色啦，wombat256 的 screenshot 見這裡。

備註

這個網站有提供許多不同的 color scheme screenshot，可惜沒附 Python 的 screenshot。

最近用 Python + TDD 心得（與 Java 做對照）

2009-04-20T09:24:22Z

最近又用 Python 寫了些程式，剛好和之前用 Java 進行 TDD 做個對照。

若不知道 TDD 的人，可以先參考這篇，TDD 的概念是依以下三個步驟寫程式 ( 順序相當重要 )：

先寫簡單的單元測試，並執行它。
用最簡單的方法實作需要的功能，讓程式能通過測試。
重構程式，並確保重構後的程式仍能通過測試。

實作部份不需多談，這裡先分別對步驟一「寫測試碼」和步驟三「重構」討論，再分享一般性的一點心得。

寫測試碼

Python 寫起測試碼比 Java 簡單許多，可以輕易地抽換所有既有物件，如 module、function、class、method。下面是一個簡單的抽換 method 的例子：

class MyClass(object):
    def hello(self, msg):
        print msg
 
def new_hello(self, msg):
    print msg + " (by replaced method)"
 
obj = MyClass()
obj.hello('Testing rocks!')  # Testing rocks!
mystub = stub.Stub()
mystub.replace(MyClass, 'hello', new_hello)
obj.hello('Testing rocks!')  # Testing rocks! (by replaced method)
mystub.restore(MyClass, 'hello')
obj.hello('Testing rocks!')  # Testing rocks!

註解表示該行輸出結果，其中 Stub 是我寫得一個簡單 class，只有十行多，可以替換和還原物件。可以從 MyClass.hello() 的輸出看出，stub.replace() 後 MyClass.hello() 被換為 new_hello()，stub.restore() 後則換了回來。完整的程式碼請看這裡。

方便抽換物件有什麼好處呢？舉例來說，若 class A 有兩個 method B 和 C，其中 B 用到 C ( B 會視 C 傳回結果改變程式流程 )。為了方便測試 B 的行為，得先控制 C 的傳回結果。若是 Python 的話，照上面的例子透過 Stub ( setattr() ) 替換 A.C 即可。但在 Java 的情況，除非將 C 當作參數傳給 B，讓測試程式有機會傳「假的 C 」給 B，不然難以控制 B 內部行為。寫新程式時還有機會改設計，對於舊的程式，修改程式是個災難。用到別人的函式庫或沒程式碼就無解了。不論 Java 有何解法 ( 如採用 injection 的方式 )，解法愈麻煩，表示大眾愈不願意做，因此降低測試碼的品質，連帶影響 TDD 效果。

Mock library 部份，Java 有 EasyMock，Python 有 Mox，兩者用法差不多。後者是前者改來的，學一套兩邊都可以用。

重構

由於 Java 的特性 ( static type )，重構工具相當成熟，我慣用 Eclipse 的重構功能，離開它就不太想寫 Java。其中我最常用的功能是改名稱，包含 variable、method 、 class、 package 等。好的名稱是好程式碼的必要條件之一，好的名稱可以省去冗長的註解、縮短理解程式的時間，同時也有助於作者釐清邏輯，減少犯錯的機會。若發現名稱很難取，也許表示該 object（method / class / package）功能沒規範好，之後容易遇到問題。寫程式難免會犯錯，寫一段時間後才發現命名不夠精確，得回頭修改。若有好的重構工具，改起來快又沒風險，可以提高重構的意願。

反觀 Python 因為 dynamic type，程式碼本身提供的訊息不足（得執行後才清楚全貌），難以透過工具重構。我找了一下相關工具後沒看到滿意的。Eclipse 的 PyDev plugin 有提供重構，但試用後結果是錯的，改 module 名稱時沒動到檔名，執行後才會發現程式碼爛了。另外試了 Rope ，可以正確改名，可是速度有點慢，操作相當不直覺 ( 之後再來試看看 ropevim )。為了長遠發展考量，或許可以試看看自己弄個簡單版的改名工具或改 Rope，工具的功能可以少，但要快、容易操作且結果正確。

結語

只有在三個步驟都確實做到時，TDD 才能發揮應有的威力。依我目前一點點的實作心得，Python 容易寫測試碼、卻不方便重構；而 Java 正好相反。現在我大多有照 TDD 的流程寫程式，即使寫個一小時的小程式，也會用 TDD 。有時寫寫覺得卡卡的，才發現忘了先寫測試碼。

另外，測試碼的範圍抓得準 ( 別測太細，也別懶得測核心) ，效果才會好。我初用 TDD + Python 時就矯枉過正，寫太多測試變成「over-testing」，省了 over-design 的負擔，卻多花時間寫不必要的測試碼、又增加日後維護的成本。

養成 TDD 習慣的關鍵，在於寫測試碼的功力，像是如何準備 fixture ，如何改善函式介面以利測試。為了寫測試而改變函式介面並不是本末倒置，通常這會降低函式之間的關聯性，將功能明確切開，讓每個函式的輸入輸出都很乾淨（有簡單的輸入，才方便準備 fixture）。而乾淨的輸入輸出意味著函式更容易被組合使用。

軟體開發技巧的待讀書單

2009-03-15T05:12:16Z

經過這陣子的評估，終於列出了夢幻般 (?) 的讀書清單。我的做法是先在網上看到有人推薦，到書局翻一陣子，再回來查 Amazon 的評論，最後決定是否有必要看。附帶一提，待這書單決定後又查了一下，結果發現每本書都有得到 Jolt Award，一瞬間好像以為 Jolt Award 不值錢了 :-)。

以下依暫定的閱讀順序依序說明，除前兩本外，後三本都有中文版：

1. Test Driven Development by Examples

Amazon 評論 4 顆星，由 Kent Beck 所著。全書只有 200+ 頁，用大量的例子，一步一步說明怎麼進行 TDD，相當易讀。這裡有別人寫的詳細書評。

2. xUnit Test Patterns: Refactoring Test Code

Amazon 評論 4.5 顆星，不過只有七筆評論，樣本略嫌不足。在書店試翻的感想是：好書但不易讀，而且實在是太厚了。ThoughtWorks 專出這種書嗎？

3. Refactoring to Patterns

Amazon 評論 4 顆星，但評論兩極化落在 3 和 5，最中肯的評論為： "Good ideas, but needs refactoring"，值得一讀，但不好消化。讀過 Martin Fowler 的 Refactoring 並有一段實戰經驗後的最佳書藉。本書中文版《重構－向範式前進》，且是侯捷合譯的。

4. Head First - Head First Object-Oriented Analysis and Design

Amazon 評論 4 顆星，評論裡指出本書適合初學者，另外最多人同意的評論 (Decent Introduction to OOA&D) 指出：本書不夠簡潔，並有不少小錯，若有第二版才值得推薦。

5. Head First - Design Pattern

Amazon 評論 4.5 顆星，且是壓倒性的一堆 5 顆星。Head First 的書以易讀出名，但通常也寫得很厚，需要花不少時間消化。對照過於精簡典雅的 Design Pattern Bible Book，這本書親切不少。附帶一提，在書店還有看到 Head First - Algebra，真是太有趣了！可惜是教國中代數，不是教線性代數。

依目前心得來說，有四件事要學：

寫出良好的測試程式 - book 2
寫出良好的 OOP- book 4, 5
提昇重構技巧 - book 3
TDD (其實就是上述三者的綜合體) - book 1

前往軟體開發聖殿之路是很遠的，希望一個月至少能解決一本，並持續地應用到實戰中，半年後就出師啦！

備註

這裡補充我曾看過且大力推薦的書藉：

Effective Java Programming Language Guide：Joshua Bloch 所著。中文版只有第一版，但原文已有第二版，我只看過中譯第一版。本書適合偶而拿出來重習學習，薄又易讀。若不認識 Joshua Bloch，至少也應該用過他做的 Java Collections Framework。
重構：改善既有程式的設計：Martin Fowler 所著，淺顯易懂的好書。說明何謂壞程式碼，以及如何一小步一小步安全地修正壞程式碼。