Clean Code 閱讀心得

Mark Chang, 2013/10/18

2

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

• 目前學習狀況• 結論

3

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

為了更好的未來 !

4

CH 1.無瑕的程式碼• Bjarne Stroustrup• 我喜歡我的程式優雅又有效率。• 邏輯直截了當，使的錯誤無處可躲。• 盡量降低程式的相依性，以減輕維護上的功夫。

• Grady Booch• Clean Code 是簡單又直接明瞭的，讀來就像一篇優美的散文。

• Ward Cunningham• 當每個你看到的程式，執行的結果都與你想的差不多，你會察覺到你正工作在 Clean Code 之上。

5

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

• 變數中具體傳達出該變數要儲存什麼資料。• int elasedTimeInDays;• int daysSinceCreation;• int daysSinceModification;• int fileAgeInDays;

6

CH 2.有意義的命名 (續 )• 產生有意義的區別• 無意義的字詞是另一種無意義的區別。• 如有一個類別為 Product ，另一個叫 ProductInfo 或 ProductData 的類別。

• Info 和 Data 是不可區分的無意義字詞。• 避免思維的轉換，命名的名稱，需要讓其他人看到自己所寫的程式碼，可以很容易讓人知道程式的意圖。• 「清楚明白才是王道」，寫出讓人可了解的程式碼。

7

CH 2.有意義的命名 (續 )• 類別 (Class) 的命名• 類別和物件因該使用名詞或名詞片語來命名。• 例 : Customer 、 WikiPage 、 Account 或 AddressParser 。

• 因避免命名為 Manager 、 Processor 、 Data 或 Info 。• 類別名稱不應該是動詞。

• 方法 (Method) 的命名• 方法應該使用動詞或動詞片語來命名。• 例 : postPayment( 登記存款 ) 、 deletePage 或 save 。

8

CH 3.函式• 函式越簡短越好，每個函式都一清二楚，透露本身的意圖。• 一個函式，只做一件事情。• 它們把某件事做好，而且它們只做這件事。• 如果函式只做了函式名稱下「同一層抽象概念」，那這個函式就算是只做一件事。• 每個函式只有一層抽象概念。

• 例 : 在製作動態歌詞程式中，我把載入歌詞檔案 (load)與解析歌詞 (parser) 的動作一起在同一個函式完成，很明顯的該函式做了兩件事情。

9

CH 3.函式 (續 )• 1

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

10

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

11

CH 6.結構化與物件導向結構化的程式碼 物件導向的程式碼

說明 將資料暴露在外，而沒有提供有意義的函式。

資料在抽象層後方隱藏起來，只暴露操作資料的函式。

優點 容易添加新的函式，而不需要變動已有的資料結構。

容易添加新的類別，而不用變動已有的函式。

缺點 難以添加新的資料結構，因為必須改變所有函式。

難以添加新的函式，因為必須改變所有類別。

兩種方式各有優缺點，我們必須避免混合使用，如一起使用會使得程式難以新增函式，同時也難以添加新的資料結構。

12

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

13

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

14

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

15

目前學習狀況• 一個簡單的修改卻讓我的程式無法正常的運作，為什麼修改程式會發生這種問題 ?

• 1.設定了太多假設條件，條件修改了程式自然就錯誤。• 例 : 撰寫填字遊戲，我一開始就認定文字區塊範圍，就是跟手機畫面大小一樣，而沒想到使用者可能會改變文字區塊的位置，導致文字區塊一移動，鍵盤往上升起時要計算的偏移值就錯誤。

• 2.考慮因素太少。• 常因為程式寫好可以正常的執行就覺得程式沒有問題，而少考慮到程式失敗路徑的處理。

• 3.缺乏程式感 (code-sense)。

16

Model-View-Controller

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

17

如何解決技術負債• 事情會是這樣，因為他們就是這樣演變的 -Jerry Weinberg

• 程式碼裡頭出現垃圾，那是因為 軟體工程師把垃圾放了進去。也就是說：垃圾程式都是工程師寫出來的。• 壓力從何而來？• 有時壓力的來源只是工程師自己。• 發展一項新功能所需要的時間，往往比我們想像中來得久，我們又想要當「好工程師」好讓持股人高興，所以，壓力並不是外來的，而都是內部產生的。

• 參考網站 :http://zonble.postach.io/ru-he-jie-jue-ji-shu-fu-zhai

18

停止寫爛程式

• 圖片來源 :http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt

19

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