優雅代碼,建議掌握這 11個編程原則!
糟糕的代碼形式可以千千萬,優雅且高質量的代碼卻是極其的相通,如何寫出讓人信服的高質量代碼?這篇文章,我們總結了很多高手的經驗,一共歸納了 11條編碼基本原則。
1. DRY
DRY,全稱 Don't Repeat Yourself(不要重復你自己),它是軟件開發中的一個重要設計原則,旨在減少代碼的重復性,提高代碼的可維護性和可讀性。遵循 DRY 原則可以使代碼更加簡潔、易于理解和修改。
(1) DRY 核心思想
DRY 的核心思想是:任何知識在系統中都應該有一個單一、明確、權威的表示,簡單來說,就是避免在代碼中出現重復的邏輯或數據。
(2) 如何實現 DRY?
①抽象和封裝
- 將重復的代碼抽象為函數、方法或者類。
- 使用模塊化編程,將常用的邏輯封裝在獨立的模塊中,便于復用。
②使用常量
- 如果某個值在代碼中多次使用,可以將其定義為常量,避免硬編碼。
- 這樣不僅減少了重復代碼,還提高了代碼的可讀性和可維護性。
③利用繼承和多態
- 在面向對象編程中,使用繼承和多態來減少代碼重復。
- 將通用的功能放在父類中,子類繼承并擴展這些功能。
④模板和泛型
- 使用模板和泛型來創建可重復使用的代碼結構,適用于多種類型和場景。
⑤配置文件和數據庫
- 將可變的數據和配置項存儲在配置文件或數據庫中,而不是硬編碼在程序中。
(3) DRY 的優勢
①提高代碼質量
- 避免代碼重復,使代碼更加簡潔和易于理解。
- 減少了出錯的可能性,因為同一個邏輯只需要維護一處。
②便于維護
- 代碼修改時只需更改一個地方,減少了維護成本。
- 提高了代碼的一致性和可靠性。
③增強代碼復用性
- 通過抽象和封裝,提高了代碼的復用性,減少了重復工作。
2. KISS
KISS,全稱 Keep It Simple And Stupid(保持簡簡單),旨在提醒開發人員盡量保持代碼的簡潔性和易讀性。
(1) KISS 核心思想
KISS原則的核心思想是盡量避免不必要的復雜性。這意味著在設計和編寫代碼時,應盡量選擇簡單、直接的解決方案,而不是過度設計或引入不必要的復雜性。
(2) 如何實現 KISS?
①避免過度設計
- 不要為了顯示自己的編程技巧而編寫復雜的代碼。
- 簡單的代碼更容易理解、調試和維護。
②使用明確的命名
- 變量、函數和類的命名應盡量清晰、明確,能夠反映其用途。
- 避免使用晦澀難懂的縮寫或不相關的命名。
③分解問題
- 將復雜的問題分解為多個簡單的小問題,每個小問題用一個簡單的函數或方法來解決。
- 避免在一個函數或方法中處理過多的邏輯。
④遵循單一職責原則
- 每個函數或類應只負責一個職責或任務。
- 這樣可以避免代碼過于復雜,并提高代碼的可維護性。
⑤重用現有工具和庫
- 不要重復發明輪子,盡量使用現有的工具和庫來解決問題。
- 這不僅可以減少代碼量,還可以提高代碼的可靠性和可維護性。
3. Refactor
Refactor(重構)是指在不改變代碼外部行為的前提下,對代碼內部結構進行調整,以提高代碼的可讀性、可維護性和性能。
(1) 重構核心思想
重構的核心思想是通過逐步改進代碼結構,使其更易于理解和維護,重構不是一次性的大改動,而是通過一系列的小步驟逐步優化代碼。
(2) 重構的好處
- 提高代碼可讀性:重構后的代碼更加簡潔、清晰,便于理解。
- 提高代碼可維護性:減少代碼中的重復和冗余,使得修改和擴展代碼更加容易。
- 減少錯誤:通過清晰的代碼結構和邏輯,減少潛在的錯誤和Bug。
- 提高開發效率:重構后的代碼更易于測試和調試,從而提高開發效率。
(3) 重構常見技巧
①提取方法
- 將一段復雜的代碼提取到一個獨立的方法中,使原方法更加簡潔。
- 有助于提高代碼的可讀性和復用性。
②重命名
- 使用有意義的命名來替代晦澀難懂的命名。
- 提高代碼的可讀性和理解性。
③內聯方法
- 如果一個方法的實現非常簡單,可以將其直接替換到調用處。
- 減少不必要的方法調用,提高代碼的簡潔性。
④替換魔法數字
- 將代碼中的硬編碼數值替換為有意義的常量。
- 提高代碼的可讀性和可維護性。
⑤提取類
- 將一個類中職責過多的部分提取到一個新的類中。
- 遵循單一職責原則,使類的職責更加明確。
⑥合并重復代碼
- 將重復的代碼提取到一個獨立的方法或類中。
- 遵循DRY(Don't Repeat Yourself)原則,提高代碼的復用性。
4. SOLID
SOLID是 Robert C. Martin(也稱為Uncle Bob)提出或者總結出來的經典之作。它可以適用于各種編程語言,通常會用來衡量一個模塊,系統設計的是否合理。
(1) SOLID是什么?
在 架構整潔之道 這本經典的書籍中有一套關于軟件設計的 SOLID 原則,SOLID 實際上是五個設計原則首字母的縮寫,它們分別是:
- 單一職責原則(Single responsibility principle, SRP)
- 開放封閉原則(Open–closed principle, OCP)
- Liskov 替換原則(Liskov substitution principle, LSP)
- 接口隔離原則(Interface segregation principle, ISP)
- 依賴倒置原則(Dependency inversion principle, DIP)
5. Document Your Code
Document Your Code(記錄你的代碼,簡稱 DYC),旨在提高代碼的可讀性、可維護性和可擴展性。通過在代碼中添加注釋和文檔,可以幫助自己和他人更好地理解代碼的意圖、邏輯和功能。
(1) DYC 核心思想
DYC 的核心思想是通過詳細的注釋和文檔,使代碼更加易于理解和維護。這不僅對當前的開發工作有幫助,對于未來的維護、調試和擴展也至關重要。
(2) 如何實現 DYC?
①添加注釋
- 在代碼的關鍵部分添加注釋,解釋代碼的意圖和邏輯。
- 注釋應簡潔明了,避免冗長和重復。
②編寫文檔
- 為復雜的模塊、類和方法編寫詳細的文檔,解釋它們的功能、用途和使用方法。
- 文檔可以包括設計文檔、API文檔、用戶手冊等。
③使用自解釋代碼
- 通過使用有意義的變量名、函數名和類名,使代碼自解釋。
- 盡量減少對注釋的依賴,但在必要時仍應添加注釋。
④保持文檔更新
- 在修改代碼時,及時更新相關的注釋和文檔。
- 確保文檔與代碼保持一致,避免文檔過時。
⑤使用工具
- 使用文檔生成工具(如 Java 的 Javadoc)自動生成API文檔。
- 使用版本控制系統(如 Git)來跟蹤文檔的變化。
⑥Creation Over Legacy
- Creation Over Legacy(創建優于繼承,簡稱 COL)原則主要應用于面向對象編程(OOP)中,強調通過對象的組合和創建來實現復雜行為,而不是通過繼承。
(3) COL 的核心思想
COL的核心思想是通過對象的組合和創建來實現復雜行為,而不是依賴繼承。這有助于保持系統的靈活性、可維護性和可擴展性。
(4) 為什么選擇 COL?
①減少復雜性
- 繼承層次結構過深會導致系統復雜性增加,難以理解和維護。
- 通過組合,可以將復雜行為分解為多個獨立的、易于理解的小對象。
②提高靈活性
- 組合比繼承更靈活,可以在運行時動態地改變對象的行為。
- 通過依賴注入,可以輕松替換和擴展對象的功能。
③增強可測試性
- 組合和依賴注入使得單元測試更加容易,因為可以輕松地模擬和替換依賴對象。
- 避免了繼承層次結構中常見的耦合問題。
如果你用面向對象編程(OOP)來編寫代碼,你會發現這個規則非常有用,創建優于繼承的規則主要是關于具有復雜行為的對象由具有不同行為的對象實例組成,它們不應添加新行為并繼承一個類。
依賴繼承會導致兩個主要問題:
- 首先,如果你嘗試快速實現,繼承層次結構會變得復雜。
- 其次,你在定義不同或特殊行為時靈活性較差。假設你需要實現共享行為:
7. Clean Code At All Costs
Clean Code At All Costs(始終保持代碼清潔)原則強調代碼的清晰、簡潔和可維護性。無論在何種情況下,都應盡量保持代碼的清潔。這不僅使得代碼更易于理解和維護,還能提高軟件的質量和開發效率。
(1) Clean Code 的核心思想
Clean Code 的核心思想是:編寫易于閱讀、理解和維護的代碼。這意味著代碼應該盡量避免復雜性、重復和不必要的冗長,同時保持邏輯的清晰和一致性。
(2) 如何實現 Clean Code?
①使用有意義的命名
- 變量、函數和類的命名應盡量清晰、明確,能夠反映其用途。
- 避免使用晦澀難懂的縮寫或不相關的命名。
②函數應簡潔
- 每個函數應只做一件事,并且盡量短小。
- 如果函數過長或過于復雜,應考慮將其拆分為多個更小的函數。
③避免重復代碼
- 遵循DRY(Don't Repeat Yourself)原則,將重復的代碼提取為獨立的函數或模塊。
- 這樣不僅減少了代碼量,還提高了代碼的可維護性。
④保持代碼一致性
- 代碼風格應保持一致,無論是命名、縮進還是注釋風格等。
- 可以使用代碼風格檢查工具來確保一致性。
⑤注重代碼結構
- 代碼應有清晰的結構,邏輯應盡量直觀和易于跟蹤。
- 使用適當的注釋和文檔來解釋復雜的邏輯和設計決策。
⑥避免深層嵌套
- 避免過深的嵌套結構,如過多的if-else或循環嵌套。
- 可以通過提前返回、使用衛語句等方式來簡化嵌套結構。
⑦注重錯誤處理
- 錯誤處理應盡量明確和簡單,不應隱藏錯誤或忽略異常。
- 使用適當的異常處理機制,并提供有意義的錯誤信息。
⑧YAGNI
YAGNI,全稱 You Aren't Gonna Need It(你不需要它),它是極限編程(Extreme Programming,XP)中的一項重要原則,旨在提醒開發人員不要編寫那些當前不需要的功能或代碼。YAGNI原則的核心思想是:只實現當前需求所必須的功能,不要為未來可能需要的功能編寫代碼。
(3) YAGNI 原則的核心思想
YAGNI原則的核心思想是:避免過度設計和過早優化,只實現當前需求所必須的功能。這樣可以減少代碼的復雜性、提高開發效率和代碼質量。
(4) 為什么選擇 YAGNI 原則?
①減少復雜性
- 過多的功能和代碼會增加系統的復雜性,難以理解和維護。
- 只實現當前需求,可以使代碼更加簡潔和易于管理。
②提高開發效率
- 實現不必要的功能會浪費時間和資源,降低開發效率。
- 專注于當前需求,可以更快地交付功能和產品。
③減少錯誤
- 不必要的功能和代碼會引入更多的錯誤和 Bug,增加測試和調試的難度。
- 只實現當前需求,可以減少潛在的錯誤和 Bug。
④增強靈活性
- 未來的需求可能會變化,過早實現的功能可能會變得不再適用。
- 只實現當前需求,可以保持系統的靈活性,便于將來根據實際需求進行調整。
9. Delegation Principles
委托原則(Delegation Principles)強調將任務或職責委托給適當的對象或方法來完成,而不是由當前對象直接實現。這種方式可以提高代碼的靈活性、可維護性和可復用性。
(1) 委托原則的核心思想
委托原則的核心思想是:將任務或職責委托給最適合處理它的對象或方法。通過這種方式,可以減少代碼的耦合度,增強代碼的靈活性和可復用性。
(2) 為什么選擇委托原則?
①提高靈活性
- 委托可以讓對象在運行時動態地決定由誰來處理任務。
- 這使得系統更具適應性和擴展性。
②減少耦合
- 通過委托,類之間的依賴關系減少,降低了耦合度。
- 這使得代碼更容易理解和維護。
③增強可復用性
- 委托可以讓不同的對象共享相同的行為,從而提高代碼的復用性。
- 這減少了代碼的重復,提高了開發效率。
④提高測試性
- 通過委托,可以輕松地替換或模擬被委托的對象,增強了代碼的可測試性。
- 這使得單元測試更加容易。
10. Encapsulate the Changes
在軟件領域,唯一不變的就是變化。所以,總是將你認為將來可能需要編輯的代碼封裝起來。
Encapsulate the Changes(封裝變化),旨在將可能變化的部分隔離和封裝起來,使得系統的其他部分不受這些變化的影響。通過封裝變化,可以提高代碼的可維護性、可擴展性和穩定性。
(1) 封裝變化核心思想
封裝變化的核心思想是:將變化的部分封裝在一個獨立的模塊、類或方法中,使得系統的其他部分不依賴于這些變化。這樣可以減少代碼的耦合度,提高系統的靈活性和可維護性。
(2) 為什么選擇封裝變化?
①提高可維護性
- 通過封裝變化,代碼的修改只需在一個地方進行,減少了維護的復雜性。
- 這使得代碼更容易理解和管理。
②提高可擴展性
- 封裝變化使得添加新功能或修改現有功能變得更容易,而不會影響系統的其他部分。
- 這有助于系統的擴展和演進。
③減少耦合
- 通過封裝變化,可以減少代碼之間的依賴關系,使得系統更加模塊化。
- 這有助于提高代碼的復用性和靈活性。
④提高穩定性
- 封裝變化可以減少因修改代碼而引入的錯誤,提高系統的穩定性。
- 這有助于確保系統的可靠性和可預測性。
Java中的許多設計模式使用封裝。封裝的一個例子是工廠設計模式。該設計模式封裝了對象創建的代碼,使你在以后引入新應用程序或網站時更靈活,而不會影響當前代碼。
11. Favor Composition Instead of Inheritance
Favor Composition Instead of Inheritance(優先使用組合而不是繼承)原則是軟件設計中的一個重要原則,特別是在面向對象編程(OOP)中,該原則強調優先使用對象組合來實現功能,而不是通過繼承來擴展類的功能。
(1) 優先使用組合核心思想
Favor Composition Instead of Inheritance 的核心思想是通過組合多個對象來實現復雜功能,而不是通過繼承來擴展類的功能。這種方式可以提高代碼的靈活性、可維護性和可復用性。
(2) 為什么選擇優先使用組合?
①減少耦合
- 繼承會導致子類與父類之間的強耦合,子類高度依賴父類的實現。
- 組合可以減少這種耦合,使得對象之間的依賴關系更加松散。
②提高靈活性
- 通過組合,可以動態地改變對象的行為,而繼承則是在編譯時決定的。
- 組合使得系統更具適應性和擴展性。
③增強可復用性
- 組合可以將多個小對象組合成更復雜的行為,從而提高代碼的復用性。
- 這減少了代碼的重復,提高了開發效率。
總結
編程是一個看似簡單,但是還是有很大學問,特別是編寫出高質量的優雅代碼,最后我們再總結下本文總結的 11種原則:
- DRY,Don't Repeat Yourself
- KISS,Keep It Simple And Stupid
- Refactor
- SOLID
- Document Your Code
- Creation Over Legacy
- YAGNI,You Aren't Gonna Need It
- Delegation Principles
- Clean Code At All Costs
- Encapsulate the Changes
- Favor Composition Instead of Inheritance