美麗程式 第7章 美麗測試

學生時代,程式對我來說似乎沒有美不美的問題,只有可不可以交差的問題! 工作之後遇到 Ivan 才漸漸地會去思考”如何寫出漂亮的程式碼”這件事!

我不太愛跟別人討論編碼的事,我覺得有時這跟政治口水一樣,碰到不理性或固守陳規的人,最後往往是意見相左,更別提激盪出什麼創意的火花! 所以我喜歡看書! 書不會跟你爭論,沒有意氣之爭的狀態下,我也能好好靜下心來想想這到底是不是好的作法!

扯遠了! 反正會買這本書是因為覺得,工程師在工作上常常會檢視別人的程式碼,新手更可能被他第一次所接觸的程式碼而影響他往後的寫作風格.但我們如何知道我們看到的是值得模仿或學習的編碼風格呢?

我沒有時間/精力/興趣去看網路上有名的 Open Source 的原碼,但買一本書就能看到38位大師的一些思考方式,我相信這點時間是我這個編碼黑手需要付出的! 囧rz

(封面轉載自博客來)

內容簡介:

本書收集了軟體設計領域的大師級作品，每個作品都獨一無二，而又見解深刻。走在時代前驅的設計大師，引領讀者一章章走過解決特殊難題的優雅方案，並說明各個方案的迷人因素。這不是另一本設計模式書籍，也不是另一本探討軟體工程方法對錯的專著。我們希望讀者有機會站在軟體設計巨人的肩上，從他們的高度看世界。三十八位撰碼大師，把他們打造專案架構、判斷建置代價、決定打破成規的重要時刻，化為字字珠磯，呈現在讀者面前。

(圖片轉自詹姆仕布朗特 官方部落格)

不知為何,我看到 美麗程式 腦中就會浮現 詹姆士布朗特 唱的那句 “You are so beautiful” !

上面根本就是在勸敗(讀),以下就是個人超簡短的第七章筆記:

測試導向編碼(先寫簡單測試再開始編碼)的優點:

• 一開始便以第三方的角度來切入自己寫的程式,讓程式慢慢浮現出它所需要展現的功能,實作的成果也比較有模組化的架構.
• 在編碼初期給予編碼者對於自己寫出來的程式碼有一定的信心. 當然你不寫測試程式也是可以很有信心啦! XD
• 在專案中後期遇上架構的變動或重構時,也能馬上驗證程式碼的正確性.
• 撰寫一次測試碼! 之後受用一輩子(or 直到你換公司)!

如何寫測試程式(要怎麼測)? 以下按順序排列:

1. 基本: 寫些最基本使用程式碼的行為.
2. 邊界值: 寫些比較極端的使用情況.
3. 無窮無盡: 利用亂數or程式產生大量使用程式碼的行為,看是否都能正確通過測試.
4. 效能: 根據 系統時鐘 或是 執行次數 來檢視效能是否為自己預計範圍內的結果.

結論:

測試程式 就和 建構版本 一樣能被自動執行,寫一次就能永遠自動執行,馬上就知道有沒有問題而不是人腦判斷!

測試 會隨著 程式碼 同步演化的! 隨著程式碼加入的新功能,測試也會加上相對應的測試方式.