Recommended
More Related Content
Featured
Featured (20)
Clean code c3
- 1. Clean Code - C3 函式 Copyright © 2017 Senao Inc. All rights reserved by Merchuli
- 2. 抽象 v.s 具體 • 基本概念 細節 • 抽象像是人 具體像是個體 • 性別：女，身高： ，體重： • 性別：女，身高： ，體重：
- 3. 簡短 • 年代，長度不能超過整個螢幕的高度 編輯器的功能表與狀態行等 • 現今螢幕可以容納超過 行 不要大於 行
- 4. 巢狀結構（三個 if） 巢狀結構（一個 if） 簡短(續)
- 5. 簡短（續） • 函式不應該大到包含巢狀結構。 • 函式的縮排程度不應該大過一或兩層。 • 更容易閱讀和理解。
- 9. 每個函式只有一個抽象概念(續) 降層準則 • 閱讀程式像是閱讀“TO”(為了)段落 • 為了要包含設定和拆解，我們先納入設定，再納入測試 頁的內容，最後納入拆解。 – 為了要納入這些設定值，如果是套件的話，我們會納入套件設 定步驟，然後再引入一般的設定步驟。 • 為了要納入套件設定，我們先搜尋「SuiteSetup」頁面的上層，然 後加入納入該頁面的敘述。 – 為了要搜尋上一層……
- 10. 每個函式只有一個抽象概念(續) 降層準則（The Stepdown Rule） • TO paragraphs • To include the setups and teardowns, we include setups, then we include the test page con- tent, and then we include the teardowns. – To include the setups, we include the suite setup if this is a suite, then we include the regular setup. • To include the suite setup, we search the parent hierarchy for the “SuiteSetUp” page and add an include statement with the path of that page. – To search the parent. . .
- 11. Switch 敘述 • 敘述總是在做 件事。 • 但我們能確保讓每個 敘述都被深 埋在較低抽象層次的類別裡，而且它永 遠不會被重複使用。
- 12. Switch 敘述（續）
- 13. Switch 敘述（續） 此函式有五個問題： • 太冗長 • 如果再加入新的職員型態時，這個函式會變得更長 • 這個函式做了超過一件事，違反 • 有超過一個理由改變此函式，違反 • 當新型態加入，函式就必須有所改變，違 反開放閉合原則 • ：對於擴展是開放的，對於修改是關閉的
- 15. Switch 敘述（續） - 解決方法
- 16. Switch 敘述（續） - 解決方法 • 將 敘述藏在抽象工廠（ ）底下 • 這個工廠會使用 敘述來產生適當 的 介面衍生實體（ ） • 藉由 介面，透過多型的方式來 指派（例如： ）
- 17. Switch 敘述（續） 作者對 敘述的普遍準則： • 如果它們只出現一次，而且是用來產生 多型物件，並被藏匿在某個繼承關係之 下，使其他的系統看不到它們，那我就 可以容忍它們的存在。
- 18. 使用具描述能力的名稱 • 準則：「當每個你看到的程式，執 行結果都與你想的差不多，你會察覺到 你正工作在 上。」 • 函式越簡短並且越集中在做該做的事情 上，就越容易替函式取個具有描述性質 的名稱。 • 別害怕取較長的名稱，一個較長但具描 述性質的名稱，比一個較短但難以理解 的名稱還要好。
- 19. 函數的參數 • 零參數 • 單參數 • 雙參數 • 自然的組合或順序， • 三參數（避免） • 容易被參數絆住，或需要反覆查看 • 多參數（ ） • 可用物件型態取代 • 測試困難度，排列組合
- 20. 函數的參數- 旗標（flag） • 將一個布林值傳遞給函式，恐怖的習慣！ • 那代表不只做了一件事（違反 ） • 例子： • • •
- 21. 要無副作用 • 保證只做一件事情（ ） • 暗地裡偷偷做了其他事 • 影響同類別其他變數 • 奇怪的時空耦合 順序相依性問題 • 例子（時空耦合）： • 將 和 進行配對。 配對成功回傳 配對失敗回傳
- 22. 要無副作用（續） ？
- 23. 要無副作用（續）
- 24. 要無副作用（續） • 函式名稱並沒有提及它會初始整個工作 階段 • 造成時空耦合 • 函式只能在在特定的時空（也就是，只有在初始工 作階段是安全時） • 如何改善？ • 刪掉初始 那一行 • 改名成 違反
- 25. 指令和查詢的分離 • 函式應該要能做某件事，或能回答某個 問題，但兩者不該同時發生 。 • 將指令和查詢分開 • • 錯誤示範 • • 是動詞還是形容詞
- 26. 使用例外處理取代回傳錯誤碼
- 29. 使用例外處理取代回傳錯誤碼(續) • 為啥還要多兩個 • 函式應該只做一件事 ，錯誤處理就 是一件事，所以，一個處理錯誤的函式， 應該不能再做其他事。
- 30. 使用例外處理取代回傳錯誤碼(續) • 的依附性磁鐵 • 當 （錯誤列舉）有所改變時， 其他相關的類別就必須重新編譯和部署 • 很麻煩 • 使用例外處理，新的例外可由例外類別衍生出 來
- 31. 不要重複自己 • • 當演算法某些地方需要改變時，這些修 改需要花費 倍工夫，因此也容易讓遺 漏而導致的錯誤，變成 倍。 • 重複的次數 • 例子： •
- 32. 結構化程式設計 • 只有一個進入點及一個離開點 • 現在推崇 • 可以多個離開點
- 33. 結論 • 寫軟體就像寫作一般，初稿總是粗糙而 雜亂無章 • 修改再修改 • 重構再重構 • 說故事 • 函式是這個語言裡的動詞，類別是 這個語言的名詞 • 遵循本章作法，函式將會簡短、命名良 好，且結構漂亮（看看漂亮的 ）