Clean Code 閱讀心得2. 大綱
• 閱讀章節
• CH 1.無瑕的程式碼
• CH 2.有意義的命名
• CH 3.函式
• CH 6.物件及資料結構
• CH 9.單元測試
• 目前學習狀況
• 結論
2
4. CH 1.無瑕的程式碼
• Bjarne Stroustrup
• 我喜歡我的程式優雅又有效率。
• 邏輯直截了當,使的錯誤無處可躲。
• 盡量降低程式的相依性,以減輕維護上的功夫。
• Grady Booch
• Clean Code是簡單又直接明瞭的,讀來就像一篇優美的散文。
• Ward Cunningham
• 當每個你看到的程式,執行的結果都與你想的差不多,你會察覺到
你正工作在Clean Code之上。
4
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
13. CH 9.單元測試
• Test Driven Development
• (1)紅燈 → (2)綠燈 → (3)重構程式
• 單元測試可確保往後程式的修改不會發生錯誤,就如同程
式穿上了一件保護網,讓程式設計師可以大膽的修改程式,
且確保修改後的程式依然可正確執行。
• 一個測試一個概念
• 不要在一個測試函式中,同時測試A和測試B,測試兩個不相干的東
西,只需測試相同概念的東西。
13
17. 如何解決技術負債
• 事情會是這樣,因為他們就是這樣演變的-Jerry Weinberg
• 程式碼裡頭出現垃圾,那是因為 軟體工程師把垃圾放了進
去。也就是說:垃圾程式都是工程師寫出來的。
• 壓力從何而來?
• 有時壓力的來源只是工程師自己。
• 發展一項新功能所需要的時間,往往比我們想像中來得久,我們又
想要當「好工程師」好讓持股人高興,所以,壓力並不是外來的,
而都是內部產生的。
• 參考網站:http://zonble.postach.io/ru-he-jie-jue-ji-shu-fu-zhai
17
Editor's Notes 歡迎指教 顧名思義 P.126 一開始初學者的時候只要想辦法把程式寫出來就好了。
但是變成老手之後,要把程式寫出來變得不是那麼困難,困難的地方反而是如何寫出乾淨且容易維護程式碼。