文章同步於it邦
前言
昨天介紹了一些比較有關程式碼部分
都是跟Code比較有關的
今天會來介紹比較是設計面的問題
也就是Clean Code的羽化
羽化
開頭我們先引用書中的說法
根據Kent的說法,若遵循下列守則,一個設計就可以說是「簡單的」
- 執行完所有測試
- 沒有重複的部分
- 表達程式設計師的本意
- 最小化類別和方法的數量
這些守則,根據重要性來排序
-Clean Code P.190
簡單設計守則 1 : 執行完所有測試
當我們的系統設計得再好,如果沒有辦法驗證系統是否能夠如預期般運作,那一切都是紙上談兵。
所以必須全面的執行測試,並且能夠在所有的時間通過所有的測試
這段話看似簡單,但如果我們沒有辦法測試,那又如何證明這些能夠運作
緊密耦合的程式碼,只會造成測試撰寫的困難。
當我們在撰寫測試時,我們就會用越多依賴反轉的原則(DIP)也會用更多相依注入(Dependency injection)、介面(interface)、抽象概念之類的工具,來降低耦合度
舉個例子
1 | def create_user(user_name: str, user_password: str) -> bool: |
這個案例我們可以看到,這些已經都把所有建立使用者的邏輯放在create_user
這個function上
這會有幾個問題
- 無法獨立測試驗證、確認使用者是否存在的邏輯是否正確,這會導致debug時間太長
- 當我的驗證邏輯改變的時候,我就要在我的主流程變更程式碼,這會導致如果有複數個相通邏輯的地方都要一併變更
這個function的耦合度就太高了,所以我們可以把它拆解為各種不同的function以符合單一職責原則(SRP)
1 | def create_user(user_name: str, user_password: str) -> bool: |
簡單設計守則 2~4 : 程式重構
也就是對應最後三點
- 沒有重複的部分
- 表達程式設計師的本意
- 最小化類別和方法的數量
沒有重複的部分
延續上面寫的,如果我們今天不只有使用者(user)需要建立,我們也需要建立管理員(admin)
如果說他們都使用同一個驗證邏輯
那我們就更不該把驗證邏輯寫在create的function底下
更應該拆成一個獨立的function提供測試以及使用
表達程式設計師的本意
很多方法都可以達到這點,像是良好的命名習慣、讓function以及class簡短、寫單元測試等等
這些都可以達到
但是最重要最重要的事情就是嘗試
有可能下一個看code的就是我們自己,總不能看不懂我們自己寫的東西吧
所以就更不能只能讓程式停留在只要能跑就好的階段
而是大家都要看的懂
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
-The Zen Of Python
最小化類別和方法的數量
這應該是我覺得最困難達到的,這個很容易在過度設計跟保有彈性之間取得平衡
幸好這條守則比起其他的手則相對不重要,應該優先遵守其他的守則。
這條守則我認為和第一條有些相關,當我們沒有什麼重複的部分,自然類別和方法也會減少一些。
結語
我原本還想講平行化的,但我發現我已經寫太多了,再寫下去就太滿了
平行化就交給你們去看吧
我們明天見
參考資料
Clean Code(ch.12)