建站
咨詢
售后
建站咨詢
新聞中心
?前言
一個軟件輕量簡單的軟件架構(gòu)是非常重要的，它可以讓我們花最小的代價就能滿足業(yè)務(wù)上的需求。那如何保證輕量簡單呢？那今天就和大家分享下這其中的秘密，也就是3個重要的指導原則，KISS原則，YAGNI原則和DRY原則，你們都知道并且理解嗎？
KISS原則
KISS原則, 英文全稱Keep it simple and stupid。核心思想就是盡量保持簡單。
KISS原則指導我們在軟件設(shè)計的時候要盡量保持簡單，使用一些成熟的、適合業(yè)務(wù)的技術(shù)方案。另外從一個使用者的角度來思考，你設(shè)計時要思考如何讓自己的架構(gòu)設(shè)計變得簡單，足夠易用，比如你開發(fā)的框架是不是對于接入成本低甚至0成本? 你設(shè)計的框架是否不侵入業(yè)務(wù)代碼？
不僅軟件架構(gòu)設(shè)計層面，在代碼層面也處處要體現(xiàn)KISS原則。代碼的可讀性和可維護性是衡量代碼質(zhì)量非常重要的兩個標準。而 KISS 原則就是保持代碼可讀和可維護的重要手段。代碼足夠簡單，也就意味著很容易讀懂，bug 比較難隱藏。即便出現(xiàn) bug，修復起來也比較簡單。
我們來看下面校驗IP是否合法的3種實現(xiàn)方式哪個最“KISS”，大家覺得是哪個呢？
方式一
方式二
方式三
- 方式一代碼量最少，正則表達式本身是比較復雜的，寫出完全沒有 bug 的正則表達本身就比較有挑戰(zhàn)；另一方面，并不是每個程序員都精通正則表達式。對于不怎么懂正則表達式的同事來說，看懂并且維護這段正則表達式是比較困難的。這種實現(xiàn)方式會導致代碼的可讀性和可維護性變差，所以，從 KISS 原則的設(shè)計初衷上來講，這種實現(xiàn)方式并不符合 KISS 原則。
- 方式二使用了 StringUtils 類、Integer 類提供的一些現(xiàn)成的工具函數(shù)，來處理 IP地址字符串，邏輯清晰，可讀性好。
- 方式三不使用任何工具函數(shù)，而是通過逐一處理 IP 地址中的字符，來判斷是否合法，容易出bug，不好理解。
小結(jié)： 綜合來看，第二種方式更符合KISS原則。并不是代碼越少越好，還要考慮代碼是否邏輯清晰、是否容易理解、是否夠穩(wěn)定。
那如何寫出滿足 KISS 原則的代碼？
- 不要使用同事可能不懂的技術(shù)來實現(xiàn)代碼。比如前面例子中的正則表達式，還有一些編程語言中過于高級的語法等。
- 不要重復造輪子，要善于使用已經(jīng)有的工具類庫。經(jīng)驗證明，自己去實現(xiàn)這些類庫，出bug 的概率會更高，維護的成本也比較高。
- 不要過度優(yōu)化。不要過度使用一些奇技淫巧（比如，位運算代替算術(shù)運算、復雜的條件語句代替if-else、使用一些過于底層的函數(shù)等）來優(yōu)化代碼，犧牲代碼的可讀性。
YAGNI原則
YAGNI 原則的英文全稱是：You Ain’t Gonna Need It。中文大意是說你根本不需要這么做。核心思想就是不要過度設(shè)計。
那什么是過度設(shè)計呢？比如說你的應(yīng)用，現(xiàn)在還是處在一個單體應(yīng)用的階段，那么這時候我就考慮啊，分布式事務(wù)該怎么做，那或者說你的數(shù)據(jù)庫還是一個單庫的時候，我就在思考。如何去做數(shù)據(jù)異構(gòu)，甚至是你的業(yè)務(wù)邏輯在并不復雜的階段的時候，你就再去思考如何去上一個工作流引擎，或者是規(guī)則引擎。那再比如現(xiàn)在圖形數(shù)據(jù)庫非常的火，那你就在想方設(shè)法的把圖形數(shù)據(jù)庫引入到你自己的項目當中。那這些是什么呢??？說好聽點叫面向簡歷編程，說難聽點就是什么？脫褲子放屁，多此一舉。我們提倡面向未來的架構(gòu)是什么意思啊？是去規(guī)劃你未來技術(shù)發(fā)展的路線，當這一天需要到來的時候，你有能力去實現(xiàn)它。而不是說你現(xiàn)在就把未來不需要的東西去搬到自己的項目當中。
所以千萬不要為了技術(shù)而技術(shù)，一定要讓技術(shù)服務(wù)于業(yè)務(wù)，謹遵YAGNI原則，過度設(shè)計是災(zāi)難。
DRY原則
DRY原則，英文全稱Don’t Repeat Yourself，直譯過來就是不要重復你自己。那這里的重復是什么意思？就是指代碼一模一樣的才算重復嗎？實際不是的，我這里從實現(xiàn)邏輯重復、功能語義重復和代碼執(zhí)行重復三個點來理解重復的意思。
實現(xiàn)邏輯重復
我們看下下面的例子:
- 校驗用戶名
- 校驗密碼
雖然上面兩個方法的代碼邏輯是重復的，但是他們語義不重復，一個是用來校驗用戶名，一個是用來校驗密碼的，所以是符合DRY原則。如果我們強行把他們封裝成isValidUsernameOrPassword()方法，反而不符合單一職責原則，萬一哪天密碼的校驗邏輯變了怎么辦呢？所以并不是說代碼一樣就一定違反了DRY原則。反而有時候代碼不一樣，恰好違反了DRY原則。
功能語義重復
直接上例子，項目中不同的同事由于不知道就寫了兩個校驗IP的方法。
- 代碼一
- 代碼二
盡管兩段代碼的實現(xiàn)邏輯不重復，但語義重復，也就是功能重復，我們認為它違反了 DRY 原則。我們應(yīng)該在項目中，統(tǒng)一一種實現(xiàn)思路，所有用到判斷 IP 地址是否合法的地方，都統(tǒng)一調(diào)用同一個函數(shù)。不然哪天校驗規(guī)則變了，很容易只改了其中一個，另外一個漏改，就會出現(xiàn)莫名其妙的bug。
代碼執(zhí)行重復
我們看下面一個登錄的代碼例子。
你有沒有發(fā)現(xiàn)email的校驗邏輯被執(zhí)行了2次，這種重復執(zhí)行的情況我們也可以認為違反了DRY原則。
說了這么多，那有什么好的辦法提高代碼復用性，保證DRY原則呢？
- 使用現(xiàn)成的輪子，不輕易造輪子
其實最關(guān)鍵的就是寫代碼帶腦子，用到一個方法先看看有沒有現(xiàn)成的，不要看看不看，就動手在那里造輪子。
- 減少代碼耦合
對于高度耦合的代碼，當我們希望復用其中的一個功能，想把這個功能的代碼抽取出來成為一個獨立的模塊、類或者函數(shù)的時候，往往會發(fā)現(xiàn)牽一發(fā)而動全身。移動一點代碼，就要牽連到很多其他相關(guān)的代碼。所以，高度耦合的代碼會影響到代碼的復用性，我們要盡量減少代碼耦合。
- 滿足單一職責原則
我們前面講過，如果職責不夠單一，模塊、類設(shè)計得大而全，那依賴它的代碼或者它依賴的代碼就會比較多，進而增加了代碼的耦合。根據(jù)上一點，也就會影響到代碼的復用性。相反，越細粒度的代碼，代碼的通用性會越好，越容易被復用。
- 模塊化
這里的“模塊”，不單單指一組類構(gòu)成的模塊，還可以理解為單個類、函數(shù)。我們要善于將功能獨立的代碼，封裝成模塊。獨立的模塊就像一塊一塊的積木，更加容易復用，可以直接拿來搭建更加復雜的系統(tǒng)。
- 業(yè)務(wù)與非業(yè)務(wù)邏輯分離
越是跟業(yè)務(wù)無關(guān)的代碼越是容易復用，越是針對特定業(yè)務(wù)的代碼越難復用。所以，為了復用跟業(yè)務(wù)無關(guān)的代碼，我們將業(yè)務(wù)和非業(yè)務(wù)邏輯代碼分離，抽取成一些通用的框架、類庫、組件等。
- 通用代碼下沉
從分層的角度來看，越底層的代碼越通用、會被越多的模塊調(diào)用，越應(yīng)該設(shè)計得足夠可復用。一般情況下，在代碼分層之后，為了避免交叉調(diào)用導致調(diào)用關(guān)系混亂，我們只允許上層代碼調(diào)用下層代碼及同層代碼之間的調(diào)用，杜絕下層代碼調(diào)用上層代碼。所以，通用的代碼我們盡量下沉到更下層。
- 繼承、多態(tài)、抽象、封裝
在講面向?qū)ο筇匦缘臅r候，我們講到，利用繼承，可以將公共的代碼抽取到父類，子類復用父類的屬性和方法。利用多態(tài)，我們可以動態(tài)地替換一段代碼的部分邏輯，讓這段代碼可復用。除此之外，抽象和封裝，從更加廣義的層面、而非狹義的面向?qū)ο筇匦缘膶用鎭砝斫獾脑?，越抽象、越不依賴具體的實現(xiàn)，越容易復用。代碼封裝成模塊，隱藏可變的細節(jié)、暴露不變的接口，就越容易復用。
- 應(yīng)用模板等設(shè)計模式
一些設(shè)計模式，也能提高代碼的復用性。比如，模板模式利用了多態(tài)來實現(xiàn)，可以靈活地替換其中的部分代碼，整個流程模板代碼可復用。
總結(jié)
本文和大家介紹了軟件工程領(lǐng)域中保持簡單架構(gòu)設(shè)計的三個原則，其實所有的這些原則就是為了達到一個很簡單的目的,try everything to keep it simple，軟件設(shè)計上的簡單輕量是非常重要的。
網(wǎng)站欄目：【架構(gòu)設(shè)計】保持簡單輕量設(shè)計的三個原則——DRY，KISS,YAGNI
URL網(wǎng)址：http://www.5511xx.com/article/cosojgp.html
