2013/10/18 @ KKBOX

1. Clean Code 閱讀心得
Mark Chang, 2013/10/18

2. 大綱
• 閱讀章節
• CH 1.無瑕的程式碼
• CH 2.有意義的命名
• CH 3.函式
• CH 6.物件及資料結構
• CH 9.單元測試
• 目前學習狀況
• 結論
2

3. 雜亂程式的代價
• 開發初期速度快，但往後難以維護。
• 雜亂的程式碼，讓開發的產能隨著時間越來越低，導致產
品後期版本的更新越不易。
3
為了更好的未來!

4. CH 1.無瑕的程式碼
• Bjarne Stroustrup
• 我喜歡我的程式優雅又有效率。
• 邏輯直截了當，使的錯誤無處可躲。
• 盡量降低程式的相依性，以減輕維護上的功夫。
• Grady Booch
• Clean Code是簡單又直接明瞭的，讀來就像一篇優美的散文。
• Ward Cunningham
• 當每個你看到的程式，執行的結果都與你想的差不多，你會察覺到
你正工作在Clean Code之上。
4

5. CH 2.有意義的命名
• 程式裡不管是在變數、函式或類別名稱，都需要清楚的命
名，不要與程式欲執行的本意落差。
• 變數d沒有傳達出任何資訊，而容易產生誤導。
• int d; // elapsed time in days
• 變數中具體傳達出該變數要儲存什麼資料。
• int elasedTimeInDays;
• int daysSinceCreation;
• int daysSinceModification;
• int fileAgeInDays;
5

6. CH 2.有意義的命名(續)
• 產生有意義的區別
• 無意義的字詞是另一種無意義的區別。
• 如有一個類別為 Product，另一個叫 ProductInfo 或
ProductData 的類別。
• Info 和 Data 是不可區分的無意義字詞。
• 避免思維的轉換，命名的名稱，需要讓其他人看到自己所
寫的程式碼，可以很容易讓人知道程式的意圖。
• 「清楚明白才是王道」，寫出讓人可了解的程式碼。
6

7. CH 2.有意義的命名(續)
• 類別(Class)的命名
• 類別和物件因該使用名詞或名詞片語來命名。
• 例: Customer、WikiPage、Account 或 AddressParser。
• 因避免命名為Manager、Processor、Data 或 Info。
• 類別名稱不應該是動詞。
• 方法(Method)的命名
• 方法應該使用動詞或動詞片語來命名。
• 例: postPayment(登記存款)、deletePage 或 save。
7

8. CH 3.函式
• 函式越簡短越好，每個函式都一清二楚，透露本身的意圖。
• 一個函式，只做一件事情。
• 它們把某件事做好，而且它們只做這件事。
• 如果函式只做了函式名稱下「同一層抽象概念」，那這個函式就算
是只做一件事。
• 每個函式只有一層抽象概念。
• 例: 在製作動態歌詞程式中，我把載入歌詞檔案(load)與
解析歌詞(parser)的動作一起在同一個函式完成，很明顯
的該函式做了兩件事情。
8

9. CH 3.函式(續)
• 1
9
無副作用(side effects)，函式原
本只做一件事，卻在該函式中又偷
做了其他事情。

10. CH 3.函式(續)
• 不要重複自己，減少重複讓整個模組的可讀性增加。
• 重複的程式碼也許是軟體裡所有邪惡的根源。
• 重複讓程式變的很擁擠。
• 如要修改程式需要修改很多重複的地方，所需花費時間也會變多。
• 修改也容易遺漏而導致錯誤。
10

11. CH 6.結構化與物件導向
結構化的程式碼 物件導向的程式碼
說明
將資料暴露在外，而沒有提
供有意義的函式。
資料在抽象層後方隱藏起來，
只暴露操作資料的函式。
優點
容易添加新的函式，而不需
要變動已有的資料結構。
容易添加新的類別，而不用變
動已有的函式。
缺點
難以添加新的資料結構，因
為必須改變所有函式。
難以添加新的函式，因為必須
改變所有類別。
11
兩種方式各有優缺點，我們必須避免混合使用，如一起使用
會使得程式難以新增函式，同時也難以添加新的資料結構。

12. CH 6.結構化與物件導向(續)
• 物件將他們資料隱藏起來，達到資料的封裝性，且只暴露
其本身的操作行為，給外部使用。
• 一個物件不應該透過存取者暴露其內部的結構。
• 資料傳輸物件(Data Transfer Objects, DTO)
• 一個類別裡只有公用變數，而沒有任何函式。
• 例: 撰寫貪食蛇遊戲時，使用DTO來表示蛇的節點。
12

13. CH 9.單元測試
• Test Driven Development
• (1)紅燈 → (2)綠燈 → (3)重構程式
• 單元測試可確保往後程式的修改不會發生錯誤，就如同程
式穿上了一件保護網，讓程式設計師可以大膽的修改程式，
且確保修改後的程式依然可正確執行。
• 一個測試一個概念
• 不要在一個測試函式中，同時測試A和測試B，測試兩個不相干的東
西，只需測試相同概念的東西。
13

14. CH 9.單元測試(續)
• 軟體開發過程，邊撰寫程式碼，一邊撰寫測試程式。
• 單元測試讓我們的程式保持擴充彈性、可維護性及可再利
用性。
• 沒有測試，每一次的修改都可能存在潛藏的錯誤，也讓自
己不願意做改變，因為怕導致其他尚未察覺的錯誤，但有
了測試這樣的恐懼就會消失。
14

15. 目前學習狀況
• 一個簡單的修改卻讓我的程式無法正常的運作，為什麼修
改程式會發生這種問題?
• 1.設定了太多假設條件，條件修改了程式自然就錯誤。
• 例: 撰寫填字遊戲，我一開始就認定文字區塊範圍，就是跟手機畫
面大小一樣，而沒想到使用者可能會改變文字區塊的位置，導致文
字區塊一移動，鍵盤往上升起時要計算的偏移值就錯誤。
• 2.考慮因素太少。
• 常因為程式寫好可以正常的執行就覺得程式沒有問題，而少考慮到
程式失敗路徑的處理。
• 3.缺乏程式感(code-sense)。
15

16. Model-View-Controller
• 圖片來源:http://www.stanford.edu/class/cs193p/cgi-bin/drupal/downloads-2011-fall
16

17. 如何解決技術負債
• 事情會是這樣，因為他們就是這樣演變的-Jerry Weinberg
• 程式碼裡頭出現垃圾，那是因為 軟體工程師把垃圾放了進
去。也就是說：垃圾程式都是工程師寫出來的。
• 壓力從何而來？
• 有時壓力的來源只是工程師自己。
• 發展一項新功能所需要的時間，往往比我們想像中來得久，我們又
想要當「好工程師」好讓持股人高興，所以，壓力並不是外來的，
而都是內部產生的。
• 參考網站:http://zonble.postach.io/ru-he-jie-jue-ji-shu-fu-zhai
17

18. 停止寫爛程式
• 圖片來源:http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
18

19. 結論
• 1.強調程式命名的重要性。
• 2.函式盡可能的簡短，將大的東西拆解成數個小模組完成。
• 3.盡量用程式碼來解釋程式而不是註解。
• 4.程式重構，對軟體內部調整，不改變軟體原本行為，調
高程式可讀性，降低修改成本。
19