?前言

一個軟件輕量簡單的軟件架構是非常重要的，它可以讓我們花最小的代價就能滿足業務上的需求。那如何保證輕量簡單呢？那今天就和大家分享下這其中的秘密，也就是3個重要的指導原則，KISS原則，YAGNI原則和DRY原則，你們都知道并且理解嗎？

KISS原則

KISS原則, 英文全稱Keep it simple and stupid。核心思想就是盡量保持簡單。

KISS原則指導我們在軟件設計的時候要盡量保持簡單，使用一些成熟的、適合業務的技術方案。另外從一個使用者的角度來思考，你設計時要思考如何讓自己的架構設計變得簡單，足夠易用，比如你開發的框架是不是對于接入成本低甚至0成本? 你設計的框架是否不侵入業務代碼？

不僅軟件架構設計層面，在代碼層面也處處要體現KISS原則。代碼的可讀性和可維護性是衡量代碼質量非常重要的兩個標準。而 KISS 原則就是保持代碼可讀和可維護的重要手段。代碼足夠簡單，也就意味著很容易讀懂，bug 比較難隱藏。即便出現 bug，修復起來也比較簡單。

我們來看下面校驗IP是否合法的3種實現方式哪個最“KISS”，大家覺得是哪個呢？

方式一

方式二

方式三

• 方式一代碼量最少，正則表達式本身是比較復雜的，寫出完全沒有 bug 的正則表達本身就比較有挑戰；另一方面，并不是每個程序員都精通正則表達式。對于不怎么懂正則表達式的同事來說，看懂并且維護這段正則表達式是比較困難的。這種實現方式會導致代碼的可讀性和可維護性變差，所以，從 KISS 原則的設計初衷上來講，這種實現方式并不符合 KISS 原則。
• 方式二使用了 StringUtils 類、Integer 類提供的一些現成的工具函數，來處理 IP地址字符串，邏輯清晰，可讀性好。
• 方式三不使用任何工具函數，而是通過逐一處理 IP 地址中的字符，來判斷是否合法，容易出bug，不好理解。

小結： 綜合來看，第二種方式更符合KISS原則。并不是代碼越少越好，還要考慮代碼是否邏輯清晰、是否容易理解、是否夠穩定。

那如何寫出滿足 KISS 原則的代碼？

• 不要使用同事可能不懂的技術來實現代碼。比如前面例子中的正則表達式，還有一些編程語言中過于高級的語法等。
• 不要重復造輪子，要善于使用已經有的工具類庫。經驗證明，自己去實現這些類庫，出bug 的概率會更高，維護的成本也比較高。
• 不要過度優化。不要過度使用一些奇技淫巧（比如，位運算代替算術運算、復雜的條件語句代替if-else、使用一些過于底層的函數等）來優化代碼，犧牲代碼的可讀性。

YAGNI原則

YAGNI 原則的英文全稱是：You Ain’t Gonna Need It。中文大意是說你根本不需要這么做。核心思想就是不要過度設計。

那什么是過度設計呢？比如說你的應用，現在還是處在一個單體應用的階段，那么這時候我就考慮啊，分布式事務該怎么做，那或者說你的數據庫還是一個單庫的時候，我就在思考。如何去做數據異構，甚至是你的業務邏輯在并不復雜的階段的時候，你就再去思考如何去上一個工作流引擎，或者是規則引擎。那再比如現在圖形數據庫非常的火，那你就在想方設法的把圖形數據庫引入到你自己的項目當中。那這些是什么呢啊？說好聽點叫面向簡歷編程，說難聽點就是什么？脫褲子放屁，多此一舉。我們提倡面向未來的架構是什么意思啊？是去規劃你未來技術發展的路線，當這一天需要到來的時候，你有能力去實現它。而不是說你現在就把未來不需要的東西去搬到自己的項目當中。

所以千萬不要為了技術而技術，一定要讓技術服務于業務，謹遵YAGNI原則，過度設計是災難。

DRY原則

DRY原則，英文全稱Don’t Repeat Yourself，直譯過來就是不要重復你自己。那這里的重復是什么意思？就是指代碼一模一樣的才算重復嗎？實際不是的，我這里從實現邏輯重復、功能語義重復和代碼執行重復三個點來理解重復的意思。

實現邏輯重復

我們看下下面的例子:

• 校驗用戶名

• 校驗密碼

雖然上面兩個方法的代碼邏輯是重復的，但是他們語義不重復，一個是用來校驗用戶名，一個是用來校驗密碼的，所以是符合DRY原則。如果我們強行把他們封裝成isValidUsernameOrPassword()方法，反而不符合單一職責原則，萬一哪天密碼的校驗邏輯變了怎么辦呢？所以并不是說代碼一樣就一定違反了DRY原則。反而有時候代碼不一樣，恰好違反了DRY原則。

功能語義重復

直接上例子，項目中不同的同事由于不知道就寫了兩個校驗IP的方法。

• 代碼一

• 代碼二

盡管兩段代碼的實現邏輯不重復，但語義重復，也就是功能重復，我們認為它違反了 DRY 原則。我們應該在項目中，統一一種實現思路，所有用到判斷 IP 地址是否合法的地方，都統一調用同一個函數。不然哪天校驗規則變了，很容易只改了其中一個，另外一個漏改，就會出現莫名其妙的bug。

代碼執行重復

我們看下面一個登錄的代碼例子。

你有沒有發現email的校驗邏輯被執行了2次，這種重復執行的情況我們也可以認為違反了DRY原則。

說了這么多，那有什么好的辦法提高代碼復用性，保證DRY原則呢？

• 使用現成的輪子，不輕易造輪子

其實最關鍵的就是寫代碼帶腦子，用到一個方法先看看有沒有現成的，不要看看不看，就動手在那里造輪子。

• 減少代碼耦合

對于高度耦合的代碼，當我們希望復用其中的一個功能，想把這個功能的代碼抽取出來成為一個獨立的模塊、類或者函數的時候，往往會發現牽一發而動全身。移動一點代碼，就要牽連到很多其他相關的代碼。所以，高度耦合的代碼會影響到代碼的復用性，我們要盡量減少代碼耦合。

• 滿足單一職責原則

我們前面講過，如果職責不夠單一，模塊、類設計得大而全，那依賴它的代碼或者它依賴的代碼就會比較多，進而增加了代碼的耦合。根據上一點，也就會影響到代碼的復用性。相反，越細粒度的代碼，代碼的通用性會越好，越容易被復用。

• 模塊化

這里的“模塊”，不單單指一組類構成的模塊，還可以理解為單個類、函數。我們要善于將功能獨立的代碼，封裝成模塊。獨立的模塊就像一塊一塊的積木，更加容易復用，可以直接拿來搭建更加復雜的系統。

• 業務與非業務邏輯分離

越是跟業務無關的代碼越是容易復用，越是針對特定業務的代碼越難復用。所以，為了復用跟業務無關的代碼，我們將業務和非業務邏輯代碼分離，抽取成一些通用的框架、類庫、組件等。

• 通用代碼下沉

從分層的角度來看，越底層的代碼越通用、會被越多的模塊調用，越應該設計得足夠可復用。一般情況下，在代碼分層之后，為了避免交叉調用導致調用關系混亂，我們只允許上層代碼調用下層代碼及同層代碼之間的調用，杜絕下層代碼調用上層代碼。所以，通用的代碼我們盡量下沉到更下層。

• 繼承、多態、抽象、封裝

在講面向對象特性的時候，我們講到，利用繼承，可以將公共的代碼抽取到父類，子類復用父類的屬性和方法。利用多態，我們可以動態地替換一段代碼的部分邏輯，讓這段代碼可復用。除此之外，抽象和封裝，從更加廣義的層面、而非狹義的面向對象特性的層面來理解的話，越抽象、越不依賴具體的實現，越容易復用。代碼封裝成模塊，隱藏可變的細節、暴露不變的接口，就越容易復用。

• 應用模板等設計模式

一些設計模式，也能提高代碼的復用性。比如，模板模式利用了多態來實現，可以靈活地替換其中的部分代碼，整個流程模板代碼可復用。

總結

本文和大家介紹了軟件工程領域中保持簡單架構設計的三個原則，其實所有的這些原則就是為了達到一個很簡單的目的,try everything to keep it simple，軟件設計上的簡單輕量是非常重要的。