[http://www.infoq.com/cn/articles/single-responsibility-in-software-development](<http://www.infoq.com/cn/articles/single-responsibility-in-software-development>)
最近在實(shí)踐微服務(wù)化過(guò)程中，對(duì)其“單一職責(zé)”原則深有體會(huì)。 那么只有微服務(wù)化才可以單一職責(zé)，才可以解耦嗎？答案是否定的。
單一職責(zé)原則是這樣定義的：?jiǎn)我坏墓δ?，并且完全封裝起來(lái)。
我們做后端Java開發(fā)的，應(yīng)該最熟悉的就是標(biāo)準(zhǔn)的3層架構(gòu)了，尤其是使用Spring.io體系的：Controller，Service，Dao/Repository。為什么要分層？就是為了保證單一職責(zé)，數(shù)據(jù)模型的事情交給Controller，業(yè)務(wù)邏輯的事情交給Service，和數(shù)據(jù)打交道的事情就交給Dao/Repository。有時(shí)候或者有些人會(huì)分層分的更多，4層，5層，我自己也這樣干過(guò)，說(shuō)白了也是為了保證單一職責(zé)，3層不能滿足單一職責(zé)了，耦合度高了，就分。
我們都知道一個(gè)webapp在經(jīng)過(guò)一定時(shí)間的開發(fā)后，就慘不忍睹，即便是有標(biāo)準(zhǔn)的分層，頁(yè)面或模板文件一大堆，最初的很清晰的3層標(biāo)準(zhǔn)架構(gòu)也變味了，Controller，Service，Dao/Repository各層之間、Service之間、Dao/Repository之間互相調(diào)用，一團(tuán)亂麻。這個(gè)時(shí)候沒(méi)改一行代碼都有可能一個(gè)老鼠害了一鍋湯，bug就如同螞蟻洞。
這些問(wèn)題最后就造成：
可擴(kuò)展性靈活性差，出現(xiàn)性能問(wèn)題
業(yè)務(wù)變更和開發(fā)困難，維護(hù)成本很高，交付時(shí)間長(zhǎng)
回歸測(cè)試量很大
...
為了解決這些問(wèn)題，就需要時(shí)時(shí)刻刻清楚的記住“單一職責(zé)”，單一職責(zé)可以用到軟件開發(fā)的任何地方。
應(yīng)該說(shuō)職責(zé)分離來(lái)解耦是最常用最有效的架構(gòu)方法，這能夠很大限度的簡(jiǎn)化一切。
下面就從軟件開發(fā)、設(shè)計(jì)、架構(gòu)，以及重構(gòu)/演進(jìn)/進(jìn)化，從小到大幾個(gè)方面來(lái)說(shuō)說(shuō)單一職責(zé)：
類方法/函數(shù)
這應(yīng)該是最小的能體現(xiàn)單一職責(zé)的程序單元了。最熟悉的最典型的莫過(guò)于Helper/Utils類方法了，但這種類方法的特征很明顯，也很容易遵循單一職責(zé)，99%以上的開發(fā)人員都可以做到。但不僅僅這樣的類方法要遵循單一職責(zé)原則，每一個(gè)類方法都應(yīng)該遵循單一職責(zé)原則，尤其是一些處理業(yè)務(wù)邏輯的類方法更要遵循單一職責(zé)原則，處理業(yè)務(wù)的類方法通常要配合類的單一職責(zé)原則進(jìn)行，下節(jié)中討論。
因此，這也是為什么很多TL要求類方法代碼行數(shù)保持在20行左右，其實(shí)就是為了保證單一職責(zé)，20行左右是一個(gè)經(jīng)驗(yàn)粗略數(shù)字，當(dāng)然，10行或者30行來(lái)完成類方法也是可以的。大部分單一職責(zé)的類方法用20行左右的代碼就夠了，如果超過(guò)20行就要考慮是否保證了單一職責(zé)了。那我們?cè)?b>迭代重構(gòu)的過(guò)程中就要考慮拆分這樣的類方法來(lái)保證單一職責(zé)。
類方法的單一職責(zé)是最單純的，很具體的，不慘雜任何額外信息，只關(guān)心輸入、輸出、和職責(zé)；一定要明確地定義類方法的職責(zé)，保證在迭代中不被錯(cuò)誤的擴(kuò)張，調(diào)用方錯(cuò)誤的使用。
類/函數(shù)文件
要用面向?qū)ο蟮脑O(shè)計(jì)方法，單一職責(zé)原則來(lái)定義類。開發(fā)人員一定要很好地理解“單一職責(zé)原則”，具有面向?qū)ο蟮某橄笏季S能力。
當(dāng)在迭代中一個(gè)類過(guò)于龐大或者快速膨脹，說(shuō)明已經(jīng)有壞味道了，這時(shí)候就需要考慮用單一職責(zé)原則或者面向?qū)ο蟮姆治龇椒▉?lái)重構(gòu)和重新定義類了，通常就是要抽象和拆分類，否則將來(lái)會(huì)變成一個(gè)方法容器。
把類比作一個(gè)人，她的職責(zé)就是完成自己職責(zé)范圍內(nèi)的事情，如果她什么事情都管，就叫多管閑事，可以想象她多管閑事的后果了，會(huì)攪得雞犬不寧。同樣，類也是，類如果多管閑事，那會(huì)攪得真?zhèn)€應(yīng)用不穩(wěn)定，漏洞百出，還很難修復(fù)。所以說(shuō)定義一個(gè)類，要明確這個(gè)類的職責(zé)。使用面向?qū)ο蟮姆治龊驮O(shè)計(jì)方法，能很好地準(zhǔn)確定義一個(gè)類的職責(zé)范圍，通常就要用到封裝、繼承、多態(tài)和抽象等設(shè)計(jì)方法。
包結(jié)構(gòu)/文件夾
分層就是最常用的架構(gòu)方法之一，分層具體體現(xiàn)在分包和分類，就是分門別類的意思。俗話說(shuō)，物以類聚，人以群分。
包結(jié)構(gòu)在單一職責(zé)原則上是類的補(bǔ)充，職責(zé)范圍進(jìn)一步擴(kuò)大。如果把一個(gè)類叫做一個(gè)人，那么包就是一個(gè)最小單位的團(tuán)隊(duì)，職責(zé)就是負(fù)責(zé)一類特定事情。 如何分包呢？那就要用到分類學(xué)的知識(shí)了，要以什么特征來(lái)分，可能不僅僅只有一種特征，比如，先用公司域名來(lái)做基礎(chǔ)包名，這里叫一級(jí)包名；然后再用一個(gè)特定的有意義的標(biāo)識(shí)作為二級(jí)子包名；之后按分層（web,dao,service等等）方法做三級(jí)包名，也可以先按照業(yè)務(wù)再按分層。例如：
域名：tietang.wang
有個(gè)項(xiàng)目叫：social
那么我可以這樣分：
wang.tietang
? ? ? ?- social
- web
- service
- dao
- commons
也可以這樣：
wang.tietang
- commons
- user
- web
- service
- dao
- relation
- web
- service
- dao
多工程/module
通常以多maven module或者gradle 多module形式存在，來(lái)保證單一職責(zé)。 當(dāng)業(yè)務(wù)量還沒(méi)有達(dá)到服務(wù)拆分的火候，又需要規(guī)整項(xiàng)目結(jié)構(gòu)，通常在一個(gè)app發(fā)展的太龐大時(shí)或者在工程建設(shè)初期采取，從文件系統(tǒng)上隔離，通過(guò)module依賴來(lái)集成。需要注意的是這樣的架構(gòu)或拆分不是隨意的，要以單一職責(zé)原則來(lái)拆分，更具體一點(diǎn)就是要根據(jù)業(yè)務(wù)，技術(shù)框架功能等特性來(lái)拆分。
比如，按技術(shù)組件拆分，通常會(huì)有一些技術(shù)組件，可以把她放到commons module，如果有多種類型的技術(shù)組件，就拆分為commons module的子module；也可以直接將這些技術(shù)組件拆分為獨(dú)立的工程，存在于獨(dú)立的git/svn倉(cāng)庫(kù)，獨(dú)立管理，專人負(fù)責(zé)；其他哪些module需要就依賴她。那拆分的這些技術(shù)組件的每一個(gè)應(yīng)該遵循單一職責(zé)原則，例如數(shù)據(jù)分片的框架，NIO基礎(chǔ)網(wǎng)絡(luò)框架等等。
比如，按業(yè)務(wù)拆分，例如有用戶，訂單，商品，支付，那么就按照這些業(yè)務(wù)拆分為子module，每一個(gè)子module就只負(fù)責(zé)自己的業(yè)務(wù)邏輯，也遵循單一職責(zé)。
那每個(gè)module的職責(zé)范圍又比類和包更大，這個(gè)時(shí)候職責(zé)也更模糊，有時(shí)候很難把握，對(duì)于技術(shù)組件可能相對(duì)清晰，業(yè)務(wù)module就要熟悉業(yè)務(wù)，明確業(yè)務(wù)邊界。
多module拆分后也是為將來(lái)服務(wù)化埋下伏筆，同時(shí)在物理文件系統(tǒng)比較清晰了，那在依賴管理上也要掌握好保持清晰的依賴邏輯，把握好單一職責(zé)原則。
微服務(wù)/可部署單元
微服務(wù)，從運(yùn)行時(shí)隔離，但業(yè)務(wù)量發(fā)展到一定時(shí)候，從單體或者多module工程拆分或演化出來(lái)，可獨(dú)立打包可獨(dú)立部署并復(fù)合單一原則的application，當(dāng)然了微服務(wù)所體現(xiàn)的價(jià)值不僅僅是隔離和獨(dú)立部署，還有很多這里可以參考單體應(yīng)用與微服務(wù)優(yōu)缺點(diǎn)辨析。單一職責(zé)在微服務(wù)中的價(jià)值是最重要的，包含了app層面和開發(fā)app的團(tuán)隊(duì)層面，微服務(wù)的大部分優(yōu)點(diǎn)都可以圍繞單一職責(zé)來(lái)張開。
團(tuán)隊(duì)
先引用《韓非子·揚(yáng)權(quán)》中的一段文字：
夫物者有所宜，材者有所施，各處其宜，故上下無(wú)為。
使雞司夜，令貍執(zhí)鼠，皆用其能，上乃無(wú)事。
上有所長(zhǎng)，事乃不方。
矜而好能，下之所欺：辯惠好生，下因其材。
上下易用，國(guó)故不治。
參考：
原文：http://www.shici8.com/bookview_3501.html
譯文：http://www.shici8.com/article_8539.html
各得其所，各司其職。所以，團(tuán)隊(duì)也要遵循單一職責(zé)原則，這樣才能很好地管理團(tuán)隊(duì)成員的時(shí)間，提高效率。一個(gè)人專注做一件事情的效率遠(yuǎn)高于同時(shí)關(guān)注多件事情的。同樣一個(gè)人一直管理和維護(hù)同一份代碼要比多人同時(shí)維護(hù)多份代碼的效率高很多。每一個(gè)人都有自己的個(gè)性，他有自己的擅長(zhǎng)，讓每一個(gè)人專注自己擅長(zhǎng)的事情，那肯定事半功倍，整個(gè)團(tuán)隊(duì)績(jī)效肯定也很突出。
總之，引用古文名句說(shuō)明了所有：
物以類聚，人以群分。
天下之事，分合交替，分久必合，合久必分！
使雞司夜，令貍執(zhí)鼠，皆用其能，上乃無(wú)事。
參考：
http://www.lxweimin.com/p/f9d15827465d
https://zh.wikipedia.org/wiki/單一功能原則
個(gè)人博客地址：
