狠狠撸

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

狠狠撸

Clean Code 閱讀心得

More Related Content

Clean Code 閱讀心得

Editor's Notes