編程原則

本文羅列了軟件開發中的編程原則,這些原則是多年來軟件行業的最佳實踐和規律總結,每一個原則不是孤立的,你常常須要在相互衝突的原則之間進行權衡.

 

KISS(保持簡單傻瓜)

大部分系統若是能保持簡單而不是複雜時會工做得很好.由於:

• 更少的代碼只花費更少的時間編寫,有更少的錯誤,更容易修改.
• 簡單是終極的成熟.
• 一點都不能移除時纔是完美,而不是在沒有什麼可增長時.

 

YAGNI

YAGNI是"你不須要它"的意思,直到你須要時再實現.由於:

• 任何爲明天所須要的功能而實現編程工做,意味着失去了爲當前功能進行迭代的努力.
• 它會致使代碼膨脹;軟件變得更大更復雜.

如何作?

當你真正須要的時候再去實現,而不是你預想你會須要它們時就去實現.

 

作只要能運行的事情

若是咱們只是針對問題工做,針對問題的真正實施過程才能效率最大化.所以,常常問你本身:什麼是讓它工做的最簡單事情?

 

分離關注

分離的關注是一個設計原則,將計算機程序分離成不一樣的部分,使得每一個部分解決了一個單獨關注點.例如,應用程序的業務邏輯是一個關注點,用戶界面是另外一個關注點.改變用戶界面不該該要求更改業務邏輯,反之亦然.

• 簡化軟件應用程序的開發和維護.
• 當關注是分離的,單獨的部分能夠重複使用,以及獨立開發和更新.

將程序功能切分紅不一樣模塊,儘量讓相互重疊比較小.

 

讓事情DRY

每個知識都必須有一個單一的,明確的,在一個系統內的權威表示. 不要重複,須要乾脆.

在一個程序中的每個重要的功能都應該在源代碼中的一個地方實現.

• 重複(無心或有目的的重複)可能會致使維護噩夢,不可能的因式分解和邏輯矛盾.
• 任何一個系統的任何一個元素的修改不須要在其它邏輯上修改無關的元素.
• 邏輯上相關的全部元素的變化,必須能夠是可預見的和均勻的,這樣才能保持同步.

如何作?

• 將業務規則,長表達式, if語句,數學公式和元數據等各自放在一個地方.
• 肯定表示你係統中每一個知識片斷的惟一性,防止重複,明確來源和使用該源碼有關知識如代碼文檔測試和適用狀況.

 

爲維護者編碼

維護是迄今爲止任何項目中最昂貴的階段.

• 成爲一個維護者
• 編碼時,要想象這個代碼的最終維護者會像神經病同樣發瘋地找到你
• 代碼和註釋遵循後來者可以很高興地閱讀和學習
• 不要讓我思考Don't make me think.
• 使用最小驚訝原則Principle of least Astonishment.

 

避免過早性能優化

• 瓶頸在哪裏是未知的
• 優化後,可能更難以閱讀和維護

怎麼作?

• Make it work make it right make it fast.
• 直到你須要時再優化,也只有在性能測試後發現優化瓶頸所在.

 

最小化耦合

• 一個模塊的改變一般會引發其它模塊的連鎖反應.
• 模塊組件由於模塊之間的依賴會須要更多努力和時間編寫維護.
• 一個特定的模塊可能會更難重用或測試,由於所依賴的模塊也必須加入重用或測試.
• 開發人員可能懼怕修改代碼,由於他們不知道可能會發生什麼影響.

怎麼辦?

• 消除儘可能減小和下降沒必要要的複雜度.
• 經過隱藏實現細節,下降耦合.
• 應用Law of demeter德墨忒耳定律.

 

德墨忒耳定律(迪米特法則)

不要和陌生人講話

• 一個對象的方法調用其它方法實際就是發生了緊耦合.
• 太多實現細節暴露在外面.

怎麼辦?一個對象的方法調用其它方法時,必須遵循下面迪米特法則:

1. 能夠調用對象本身的方法
2. 本身方法的參數的方法
3. 在方法內部被建立的任何對象
4. 該對象任何直接屬性或字段

 

用組合而不是繼承

• 類之間的耦合少.
• 用繼承,子類容易做出假設,也就是父類的不少屬性狀態可能會被子類改變,雖然可能在一塊兒運行,可是閱讀不方便,並打破LSP.

怎麼辦?

• 根據LSP(可置換性)決定何時繼承.
• 當有"has a"關係時用組合,表達"is a"時使用繼承.

 

正交性

正交性的基本思想是,不相關的東西在概念上不該該在一個系統中.

它與簡單性相關聯;設計的正交性越正交,例外性越少.這使得它更容易在編程語言中學習,讀和寫程序代碼.正交特徵的意義是獨立於上下文的,關鍵參數是對稱性和一致性.

 

最大聚合

一個單一的模塊/組件的凝聚度是它造成一個有意義的職責單元的的程度,更高的凝聚度意味着更好.

• 增長理解模塊的難度.
• 增長在維護系統的困難,由於在領域邏輯變化會影響多個模塊,由於在一個模塊的變化,會增長相關模塊的變化,不如將它們放在一個模塊中.
• 增長重用一個模塊的困難,由於大多數應用程序不須要由模塊提供的隨機操做集.

怎麼辦?將共享同一職責的相關功能放在一個塊中.

 

Liskov替換原則

LSP是關於對象行爲的預期,程序中的對象在不改變該程序的正確性的狀況下,能夠用他們的子類型實例來替換.

 

開閉原原則

軟件類實體應該對拓展開放,對修改閉合.經過下降對現存代碼的修改,提升可維護性和穩定性.

怎麼辦?

• 編寫能夠被拓展的類.
• 只暴露可能須要拓展的地方,其它都隱藏起來.

 

單一職責

每一個類應該有單一職責,職責應該被類封裝.全部職責混合在一個模塊或類中會致使維護改變很難.

 

Curly法則

爲任何特定的代碼選擇一個單一的,明確的目標,作一件事.

 

童子軍規則

童子軍規則規定,咱們應該老是把代碼清除比咱們發現時更乾淨.

 

命令查詢分離

命令查詢分離Command Query Separation分離命令和查詢,命令是用於執行一個動做,而查詢時返回數據給調用者.