clean code，顧名思義就是整潔的代碼，或者說(shuō)清晰、漂亮的代碼，相信大多數(shù)工程師都希望自己能寫(xiě)出這樣的代碼。

也許這是個(gè)千人千面的話(huà)題，每個(gè)工程師都有自己的理解。比如我，從一個(gè)天天被罵代碼寫(xiě)得爛的人，逐漸學(xué)習(xí)成長(zhǎng)，到現(xiàn)在也能寫(xiě)的出“人模人樣”的代碼來(lái)了。這期間算是積累了一點(diǎn)經(jīng)驗(yàn)心得，想和大家分享，拋磚引玉。

本文主要針對(duì)面向?qū)ο缶幊痰腸lean code來(lái)闡述，面向過(guò)程代碼的思路會(huì)比較不同，不在本文的討論范疇。

代碼整潔的大前提

代碼大部分時(shí)候是用來(lái)維護(hù)的，而不是用來(lái)實(shí)現(xiàn)功能的

這個(gè)原則適用于大部分的工程。我們的代碼，一方面是編譯好讓機(jī)器執(zhí)行，完成功能需求；另一方面，是寫(xiě)給身邊的隊(duì)友和自己看的，需要長(zhǎng)期維護(hù)，而且大部分項(xiàng)目都不是朝生夕死的短命鬼。

大部分情況下，如果不能寫(xiě)出清晰好看的代碼，可能自己一時(shí)爽快，后續(xù)維護(hù)付出的代價(jià)和成本將遠(yuǎn)高于你的想象。

對(duì)清晰好看代碼的追求精神，比所有的技巧都要重要。

優(yōu)秀的代碼大部分是可以自描述的，好于文檔和注釋

當(dāng)你翻看很多開(kāi)源代碼時(shí)，會(huì)發(fā)現(xiàn)注釋甚至比我們自己寫(xiě)的項(xiàng)目都少，但是卻能看的很舒服。當(dāng)讀完源碼時(shí)，很多功能設(shè)計(jì)就都清晰明了了。通過(guò)仔細(xì)斟酌的方法命名、清晰的流程控制，代碼本身就可以拿出來(lái)當(dāng)作文檔使用，而且它永遠(yuǎn)不會(huì)過(guò)期。

相反，注釋不能讓寫(xiě)的爛的代碼變的更好。如果別人只能依靠注釋讀懂你的代碼的時(shí)候，你一定要反思代碼出現(xiàn)了什么問(wèn)題（當(dāng)然，這里不是說(shuō)大家不要寫(xiě)注釋了）。

說(shuō)下比較適合寫(xiě)注釋的兩種場(chǎng)景：

public interface，向別人明確發(fā)布你功能的語(yǔ)義，輸入輸出，且不需要關(guān)注實(shí)現(xiàn)。

功能容易有歧義的點(diǎn)，或者涉及比較深層專(zhuān)業(yè)知識(shí)的時(shí)候。比如，如果你寫(xiě)一個(gè)客戶(hù)端，各種config參數(shù)的含義等。

設(shè)計(jì)模式只是手段，代碼清晰才是目的

之前見(jiàn)過(guò)一些所謂“高手”的代碼都比較抽象，各種工廠(chǎng)、各種繼承。想找到一個(gè)實(shí)現(xiàn)總是要山路十八彎，一個(gè)工程里大部分的類(lèi)是抽象類(lèi)或者接口，找不到一兩句實(shí)現(xiàn)的代碼，整個(gè)讀起代碼來(lái)很不順暢。我跟他聊起來(lái)的時(shí)候，他的主要立場(chǎng)是：保留合適的擴(kuò)展點(diǎn)，克服掉所有的硬編碼。

其實(shí)在我看來(lái)，也許他的代碼被“過(guò)度設(shè)計(jì)”了。首先必須要承認(rèn)的是，在同一個(gè)公司工作的同事，水平是參差不齊的。無(wú)論你用了如何高大上的設(shè)計(jì)，如果大多數(shù)人都不能理解你的代碼或者讀起來(lái)很費(fèi)勁的話(huà)，其實(shí)這是一個(gè)失敗的設(shè)計(jì)。

當(dāng)你的系統(tǒng)內(nèi)大部分抽象只有一個(gè)實(shí)現(xiàn)的時(shí)候，要好好思考一下，是不是設(shè)計(jì)有點(diǎn)過(guò)度了，清晰永遠(yuǎn)是第一準(zhǔn)則。

代碼整潔的常見(jiàn)手段

記住原則后，我們開(kāi)始進(jìn)入實(shí)踐環(huán)節(jié)，先來(lái)看下有哪些促成clean code的常見(jiàn)手段。

code review

很多大公司會(huì)用git的pull request機(jī)制來(lái)做code review。我們重點(diǎn)應(yīng)該review什么？是代碼的格式、業(yè)務(wù)邏輯還是代碼風(fēng)格？我想說(shuō)的是，凡是能通過(guò)機(jī)器檢查出來(lái)的事情，無(wú)需通過(guò)人。比如換行、注釋、方法長(zhǎng)度、代碼重復(fù)等。除了基本功能需求的邏輯合理沒(méi)有bug外，我們更應(yīng)該關(guān)注代碼的設(shè)計(jì)與風(fēng)格。比如，一段功能是不是應(yīng)該屬于一個(gè)類(lèi)、是不是有很多相似的功能可以抽取出來(lái)復(fù)用、代碼太過(guò)冗長(zhǎng)難懂等等。

我個(gè)人非常推崇集體code review，因?yàn)楹芏鄷r(shí)候，組里相對(duì)高級(jí)的工程師能夠一眼發(fā)現(xiàn)代碼存在較大設(shè)計(jì)缺陷，提出改進(jìn)意見(jiàn)或者重構(gòu)方式。我們可以在整個(gè)小組內(nèi)形成一個(gè)好的文化傳承和風(fēng)格統(tǒng)一，并且很大程度上培養(yǎng)了大家對(duì)clean code的熱情。

勤于重構(gòu)

好的代碼，一般都不是一撮而就的。即使一開(kāi)始設(shè)計(jì)的代碼非常優(yōu)秀，隨著業(yè)務(wù)的快速迭代，也可能被改的面目全非。

為了避免重構(gòu)帶來(lái)的負(fù)面影響（delay需求或者帶來(lái)bug），我們需要做好以下的功課：
① 掌握一些常見(jiàn)的“無(wú)痛”重構(gòu)技巧，這在下文會(huì)有具體講解。
② 小步快跑，不要企圖一口吃成個(gè)胖子。改一點(diǎn)，測(cè)試一點(diǎn)，一方面減少代碼merge的痛苦，另一方面減少上線(xiàn)的風(fēng)險(xiǎn)。
③ 建立自動(dòng)化測(cè)試機(jī)制，要做到即使代碼改壞了，也能保證系統(tǒng)最小核心功能的可用，并且保證自己修改的部分被測(cè)試覆蓋到。
④ 熟練掌握IDE的自動(dòng)重構(gòu)功能。這些會(huì)很大程度上減少我們的體力勞動(dòng)，避免犯錯(cuò)。

靜態(tài)檢查

現(xiàn)在市面上有很多代碼靜態(tài)檢查的工具，也是發(fā)現(xiàn)bug和風(fēng)格不好的比較容易的方式。可以與發(fā)布系統(tǒng)做集成，強(qiáng)制把主要問(wèn)題修復(fù)掉才可以上線(xiàn)。目前美團(tuán)點(diǎn)評(píng)技術(shù)團(tuán)隊(duì)內(nèi)部的研發(fā)流程中已經(jīng)普遍接入了Sonar質(zhì)量管理平臺(tái)。

多讀開(kāi)源代碼和身邊優(yōu)秀同學(xué)的代碼

感謝開(kāi)源社區(qū)，為我們提供了這么好的學(xué)習(xí)機(jī)會(huì)。無(wú)論是JDK的源碼，還是經(jīng)典的Netty、Spring、Jetty，還是一些小工具如Guava等，都是clean code的典范。多多學(xué)習(xí)，多多反思和總結(jié)，必有收益。

代碼整潔的常見(jiàn)技巧

前面的內(nèi)容都屬于熱身，讓大家有個(gè)整體宏觀的認(rèn)識(shí)。下面終于進(jìn)入干貨環(huán)節(jié)了，我會(huì)分幾個(gè)角度講解編寫(xiě)整潔代碼的常見(jiàn)技巧和誤區(qū)。

通用技巧

單一職責(zé)

這是整潔代碼的最重要也是最基本的原則了。簡(jiǎn)單來(lái)講，大到一個(gè)module、一個(gè)package，小到一個(gè)class、一個(gè)method乃至一個(gè)屬性，都應(yīng)該承載一個(gè)明確的職責(zé)。要定義的東西，如果不能用一句話(huà)描述清楚職責(zé)，就把它拆掉。

我們平時(shí)寫(xiě)代碼時(shí)，最容易犯的錯(cuò)誤是：一個(gè)方法干了好幾件事或者一個(gè)類(lèi)承載了許多功能。

先來(lái)聊聊方法的問(wèn)題。個(gè)人非常主張把方法拆細(xì)，這是復(fù)用的基礎(chǔ)。如果方法干了兩件事情，很有可能其中一個(gè)功能的其他業(yè)務(wù)有差別就不好重用了。另外語(yǔ)義也是不明確的。經(jīng)常看到一個(gè)get()方法里面竟然修改了數(shù)據(jù)，這讓使用你方法的人情何以堪？如果不點(diǎn)進(jìn)去看看實(shí)現(xiàn)，可能就讓程序陷入bug，讓測(cè)試陷入麻煩。

再來(lái)聊聊類(lèi)的問(wèn)題。我們經(jīng)常會(huì)看到“又臭又長(zhǎng)”的service/biz層的代碼，里面有幾十個(gè)方法，干什么的都有：既有增刪改查，又有業(yè)務(wù)邏輯的聚合。每次找到一個(gè)方法都費(fèi)勁。不屬于一個(gè)領(lǐng)域或者一個(gè)層次的功能，就不要放到一起。

我們team在code review中，最常被批評(píng)的問(wèn)題，就是一個(gè)方法應(yīng)該歸屬于哪個(gè)類(lèi)。

優(yōu)先定義整體框架

我寫(xiě)代碼的時(shí)候，比較喜歡先去定義整體的框架，就是寫(xiě)很多空實(shí)現(xiàn)，來(lái)把整體的業(yè)務(wù)流程穿起來(lái)。良好的方法簽名，用入?yún)⒑统鰠?lái)控制流程。這樣能夠避免陷入業(yè)務(wù)細(xì)節(jié)無(wú)法自拔。在腦海中先定義清楚流程的幾個(gè)階段，并為每個(gè)階段找到合適的方法／類(lèi)歸屬。

這樣做的好處是，閱讀你代碼的人，無(wú)論讀到什么深度，都可以清晰地了解每一層的職能，如果不care下一層的實(shí)現(xiàn)，完全可以跳過(guò)不看，并且方法的粒度也會(huì)恰到好處。

簡(jiǎn)而言之，我比較推崇寫(xiě)代碼的時(shí)候“廣度優(yōu)先”而不是“深度優(yōu)先”，這和我讀代碼的方式是一致的。當(dāng)然，這件事情跟個(gè)人的思維習(xí)慣有一定的關(guān)系，可能對(duì)抽象思維能力要求會(huì)更高一些。如果開(kāi)始寫(xiě)代碼的時(shí)候這些不夠清晰，起碼要通過(guò)不斷地重構(gòu)，使代碼達(dá)到這樣的成色。

清晰的命名

老生常談的話(huà)題，這里不展開(kāi)講了，但是必須要mark一下。有的時(shí)候，我思考一個(gè)方法命名的時(shí)間，比寫(xiě)一段代碼的時(shí)間還長(zhǎng)。原因還是那個(gè)邏輯：每當(dāng)你寫(xiě)出一個(gè)類(lèi)似于"temp"、"a"、"b"這樣變量的時(shí)候，后面每一個(gè)維護(hù)代碼的人，都需要用幾倍的精力才能理順。

并且這也是代碼自描述最重要的基礎(chǔ)。

避免過(guò)長(zhǎng)參數(shù)

如果一個(gè)方法的參數(shù)長(zhǎng)度超過(guò)4個(gè)，就需要警惕了。一方面，沒(méi)有人能夠記得清楚這些函數(shù)的語(yǔ)義；另一方面，代碼的可讀性會(huì)很差；最后，如果參數(shù)非常多，意味著一定有很多參數(shù)，在很多場(chǎng)景下，是沒(méi)有用的，我們只能構(gòu)造默認(rèn)值的方式來(lái)傳遞。

解決這個(gè)問(wèn)題的方法很簡(jiǎn)單，一般情況下我們會(huì)構(gòu)造paramObject。用一個(gè)struct或者一個(gè)class來(lái)承載數(shù)據(jù)，一般這種對(duì)象是value object，不可變對(duì)象。這樣，能極大程度提高代碼的可復(fù)用性和可讀性。在必要的時(shí)候，提供合適的build方法，來(lái)簡(jiǎn)化上層代碼的開(kāi)發(fā)成本。

避免過(guò)長(zhǎng)方法和類(lèi)

一個(gè)類(lèi)或者方法過(guò)長(zhǎng)的時(shí)候，讀者總是很崩潰的。簡(jiǎn)單地把方法、類(lèi)和職責(zé)拆細(xì)，往往會(huì)有立竿見(jiàn)影的成效。以類(lèi)為例，拆分的維度有很多，常見(jiàn)的是橫向／縱向。例如，如果一個(gè)service，處理的是跟一個(gè)庫(kù)表對(duì)象相關(guān)的所有邏輯，橫向拆分就是根據(jù)業(yè)務(wù)，把建立／更新／修改／通知等邏輯拆到不同的類(lèi)里去；而縱向拆分，指的是
把數(shù)據(jù)庫(kù)操作/MQ操作/Cache操作/對(duì)象校驗(yàn)等，拆到不同的對(duì)象里去，讓主流程盡量簡(jiǎn)單可控，讓同一個(gè)類(lèi)，表達(dá)盡量同一個(gè)維度的東西。

讓相同長(zhǎng)度的代碼段表示相同粒度的邏輯

這里想表達(dá)的是，盡量多地去抽取private方法，讓代碼具有自描述的能力。舉個(gè)簡(jiǎn)單的例子

public void doSomeThing(Map params1,Map params2){Do1 do1 = getDo1(params1);Do2 do2 = new Do2();do2.setA(params2.get("a"));do2.setB(params2.get("b"));do2.setC(params2.get("c"));mergeDO(do1,do2);}private void getDo1(Map params1);private void mergeDo(do1,do2){...};

類(lèi)似這種代碼，在業(yè)務(wù)代碼中隨處可見(jiàn)。獲取do1是一個(gè)方法，merge是一個(gè)方法，但獲取do2的代碼卻在主流程里寫(xiě)了。這種代碼，流程越長(zhǎng)，讀起來(lái)越累。很多人讀代碼的邏輯，是“廣度優(yōu)先”的。先讀懂主流程，再去看細(xì)節(jié)。類(lèi)似這種代碼，如果能夠把構(gòu)造do2的代碼，提取一個(gè)private 方法，就會(huì)舒服很多。

面向?qū)ο笤O(shè)計(jì)技巧

貧血與領(lǐng)域驅(qū)動(dòng)

不得不承認(rèn)，Spring已經(jīng)成為企業(yè)級(jí)Java開(kāi)發(fā)的事實(shí)標(biāo)準(zhǔn)。而大部分公司采用的三層/四層貧血模型，已經(jīng)讓我們的編碼習(xí)慣，變成了面向DAO而不是面向?qū)ο蟆?/p>

缺少了必要的模型抽象和設(shè)計(jì)環(huán)節(jié)，使得代碼冗長(zhǎng)，復(fù)用程度比較差。每次擼代碼的時(shí)候，從mapper擼起，好像已經(jīng)成為不成文的規(guī)范。

好處是上手簡(jiǎn)單，學(xué)習(xí)成本低。但是每次都不能重用，然后面對(duì)兩三千行的類(lèi)看著眼花的時(shí)候，我的心是很痛的。關(guān)于領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)模式，本文不會(huì)展開(kāi)去講。回歸面向?qū)ο?#xff0c;還是跟大家share一些比較好的code技巧，能夠在一個(gè)通用的框架下，盡量好的寫(xiě)出漂亮可重用的code。

個(gè)人認(rèn)為，一個(gè)好的系統(tǒng)，一定離不開(kāi)一套好的模型定義。梳理清楚系統(tǒng)中的核心模型，清楚的定義每個(gè)方法的類(lèi)歸屬，無(wú)論對(duì)于代碼的可讀性、可交流性，還是和產(chǎn)品的溝通，都是有莫大好處的。

為每個(gè)方法找到合適的類(lèi)歸屬，數(shù)據(jù)和行為盡量要在一起

如果一個(gè)類(lèi)的所有方法，都是在操作另一個(gè)類(lèi)的對(duì)象。這時(shí)候就要仔細(xì)想一想類(lèi)的設(shè)計(jì)是否合理了。理論上講，面向?qū)ο蟮脑O(shè)計(jì)，主張數(shù)據(jù)和行為在一起。這樣，對(duì)象之間的結(jié)構(gòu)才是清晰的，也能減少很多不必要的參數(shù)傳遞。

不過(guò)這里面有一個(gè)要討論的方法：service對(duì)象。如果操作一個(gè)對(duì)象數(shù)據(jù)的所有方法都建立在對(duì)象內(nèi)部，可能使對(duì)象承載了很多并不屬于它本身職能的方法。

例如，我定義一個(gè)類(lèi)，叫做person，。這個(gè)類(lèi)有很多行為，比如：吃飯、睡覺(jué)、上廁所、生孩子；也有很多字段，比如：姓名、年齡、性格。

很明顯，字段從更大程度上來(lái)講，是定義和描述我這個(gè)人的，但很多行為和我的字段并不相關(guān)。上廁所的時(shí)候是不會(huì)關(guān)心我是幾歲的。如果把所有關(guān)于人的行為全部在person內(nèi)部承載，這個(gè)類(lèi)一定會(huì)膨脹的不行。

這時(shí)候就體現(xiàn)了service方法的價(jià)值，如果一個(gè)行為，無(wú)法明確屬于哪個(gè)領(lǐng)域?qū)ο?#xff0c;牽強(qiáng)地融入領(lǐng)域?qū)ο罄?#xff0c;會(huì)顯得很不自然。這時(shí)候，無(wú)狀態(tài)的service可以發(fā)揮出它的作用。但一定要把握好這個(gè)度，回歸本質(zhì)，我們要把屬于每個(gè)模型的行為合理的去劃定歸屬。

警惕static

static方法，本質(zhì)上來(lái)講是面向過(guò)程的，無(wú)法清晰地反饋對(duì)象之間的關(guān)系。雖然有一些代碼實(shí)例（自己實(shí)現(xiàn)單例或者Spring托管等）的無(wú)狀態(tài)方法可以用static來(lái)表示，但這種抽象是淺層次的。說(shuō)白了，如果我們所有調(diào)用static的地方，都寫(xiě)上import static，那么所有的功能就由類(lèi)自己在承載了。

讓我畫(huà)一個(gè)類(lèi)圖？尷尬了……畫(huà)不出來(lái)。

而單例的膨脹，很大程度上也是貧血模型帶來(lái)的副作用。如果對(duì)象本身有血有肉，就不需要這么多無(wú)狀態(tài)方法。

static真正適用的場(chǎng)景：工具方法，而不是業(yè)務(wù)方法。

巧用method object

method object是大型重構(gòu)的常用技巧。當(dāng)一段邏輯特別復(fù)雜的代碼，充斥著各種參數(shù)傳遞和是非因果判斷的時(shí)候，我首先想到的重構(gòu)手段是提取method object。所謂method object，是一個(gè)有數(shù)據(jù)有行為的對(duì)象。依賴(lài)的數(shù)據(jù)會(huì)成為這個(gè)對(duì)象的變量，所有的行為會(huì)成為這個(gè)對(duì)象的內(nèi)部方法。利用成員變量代替參數(shù)傳遞，會(huì)讓代碼簡(jiǎn)潔清爽很多。并且，把一段過(guò)程式的代碼轉(zhuǎn)換成對(duì)象代碼，為很多面向?qū)ο缶幊滩趴梢允褂玫睦^承／封裝／多態(tài)等提供了基礎(chǔ)。

舉個(gè)例子，上文引用的代碼如果用method object表示大概會(huì)變成這樣

class DoMerger{map params1;map params2;Do1 do1;Do2 do2;public DoMerger(Map params1,Map params2){this.params1 = params1;this.params2 = parmas2;}public void invoke(){do1 = getDo1();do2 = getDo2();mergeDO(do1,do2);}private Do1 getDo1();private Do2 getDo2();private void mergeDo(){print(do1+do2);}}

面向接口編程

面向接口編程是很多年來(lái)大家形成的共識(shí)和最佳實(shí)踐。最早的理論是便于實(shí)現(xiàn)的替換，但現(xiàn)在更顯而易見(jiàn)的好處是避免public方法的膨脹。一個(gè)對(duì)外publish的接口，一定有明確的職責(zé)。要判斷每一個(gè)public方法是否應(yīng)該屬于同一個(gè)interface，是很容易的。

整個(gè)代碼基于接口去組織，會(huì)很自然地變得非常清晰易讀。關(guān)注實(shí)現(xiàn)的人才去看實(shí)現(xiàn)，不是嘛？

正確使用繼承和組合

這也是個(gè)在業(yè)界被討論過(guò)很久的問(wèn)題，也有很多論調(diào)。最新的觀點(diǎn)是組合的使用一般情況下比繼承更為靈活，尤其是單繼承的體系里，所以?xún)A向于使用組合
，否則會(huì)讓子類(lèi)承載很多不屬于自己的職能。

個(gè)人對(duì)此觀點(diǎn)持保留意見(jiàn)，在我經(jīng)歷過(guò)的代碼中，有一個(gè)小規(guī)律，我分析一下。

protected abstract 這種是最值得使用繼承的，父類(lèi)保留擴(kuò)展點(diǎn)，子類(lèi)擴(kuò)展，沒(méi)什么好說(shuō)的。

protected final 這種方法，子類(lèi)是只能使用不能修改實(shí)現(xiàn)的。一般有兩種情況：
① 抽象出主流程不能被修改的，然而一般情況下，public final更適合這個(gè)職能。如果只是流程的一部分，需要思考這個(gè)流程的類(lèi)歸屬，大部分變成public組合到其他類(lèi)里是更合適的。
② 父類(lèi)是抽象類(lèi)無(wú)法直接對(duì)外提供服務(wù)，又不希望子類(lèi)修改它的行為，這種大多數(shù)情況下屬于工具方法，比較適合用另一個(gè)領(lǐng)域?qū)ο髞?lái)承載并用組合的方式來(lái)使用。

protected 這種是有爭(zhēng)議的，是父類(lèi)有默認(rèn)實(shí)現(xiàn)但子類(lèi)可以擴(kuò)展的。凡是有擴(kuò)展可能的，使用繼承更理想一些。否則，定義成final并考慮成組合。

綜上所述，個(gè)人認(rèn)為繼承更多的是為擴(kuò)展提供便利，為復(fù)用而存在的方法最好使用組合的方式。當(dāng)然，更為大的原則是明確每個(gè)方法的領(lǐng)域劃分。

代碼復(fù)用技巧

模板方法

這是我用得最多的設(shè)計(jì)模式了。每當(dāng)有兩個(gè)行為類(lèi)似但又不完全相同的代碼段時(shí)，我總是會(huì)想到模板方法。提取公共流程和可復(fù)用的方法到父類(lèi)，保留不同的地方作為abstract方法，由不同的子類(lèi)去實(shí)現(xiàn)。

并在合適的時(shí)機(jī)，pull method up（復(fù)用）或者 pull method down（特殊邏輯）。

最后，把不屬于流程的、但可復(fù)用的方法，判斷是不是屬于基類(lèi)的領(lǐng)域職責(zé)，再使用繼承或者組合的方法，為這些方法找到合適的安家之處。

extract method

很多復(fù)用的級(jí)別沒(méi)有這么大，也許只是幾行相同的邏輯被copy了好幾次，何不嘗試提取方法（private）。又能明確方法行為，又能做到代碼復(fù)用，何樂(lè)不為？

責(zé)任鏈

經(jīng)常看到這樣的代碼，一連串類(lèi)似的行為，只是數(shù)據(jù)或者行為不一樣。如一堆校驗(yàn)器，如果成功怎么樣、失敗怎么樣；或者一堆對(duì)象構(gòu)建器，各去構(gòu)造一部分?jǐn)?shù)據(jù)。碰到這種場(chǎng)景，我總是喜歡定義一個(gè)通用接口，入?yún)⑹峭暾囊ｒ?yàn)／構(gòu)造的參數(shù)，
出參是成功/失敗的標(biāo)示或者是void。然后有很多實(shí)現(xiàn)器分別實(shí)現(xiàn)這個(gè)接口，再用一個(gè)集合把這堆行為串起來(lái)。最后，遍歷這個(gè)集合，串行或者并行的執(zhí)行每一部分的邏輯。

這樣做的好處是：
① 很多通用的代碼可以在責(zé)任鏈原子對(duì)象的基類(lèi)里實(shí)現(xiàn)；
② 代碼清晰，開(kāi)閉原則，每當(dāng)有新的行為產(chǎn)生的時(shí)候，只需要定義行的實(shí)現(xiàn)類(lèi)并添加到集合里即可；
③ 為并行提供了基礎(chǔ)。

為集合顯式定義它的行為

集合是個(gè)有意思的東西，本質(zhì)上它是個(gè)容器，但由于泛型的存在，它變成了可以承載所有對(duì)象的容器。很多非集合的類(lèi)，我們可以定義清楚他們的邊界和行為劃分，但是裝進(jìn)集合里，它們卻都變成了一個(gè)樣子。不停地有代碼，各種循環(huán)集合，做一些相似的操作。

其實(shí)很多時(shí)候，可以把對(duì)集合的操作顯示地封裝起來(lái)，讓它變得更有血有肉。

例如一個(gè)Map，它可能表示一個(gè)配制、一個(gè)緩存等等。如果所有的操作都是直接操作Map，那么它的行為就沒(méi)有任何語(yǔ)義。第一，讀起來(lái)就必須要深入細(xì)節(jié)；第二，如果想從獲取配置讀取緩存的地方加個(gè)通用的邏輯，例如打個(gè)log什么的，你可以想象是多么的崩潰。

個(gè)人提倡的做法是，對(duì)于有明確語(yǔ)義的集合的一些操作，尤其是全局的集合或者被經(jīng)常使用的集合，做一些封裝和抽象，如把Map封裝成一個(gè)Cache類(lèi)或者一個(gè)config類(lèi)，再提供GetFromCache這樣的方法。

總結(jié)

本文從clean code的幾個(gè)大前提出發(fā)，然后提出了實(shí)踐clean code的一些手段，重點(diǎn)放在促成clean code的一些常用編碼和重構(gòu)技巧。
當(dāng)然，這些只代表筆者本人的一點(diǎn)點(diǎn)感悟。好的代碼，最最需要的，還是大家不斷追求卓越的精神。歡迎大家一起探索交流這個(gè)領(lǐng)域，為clean code提供更多好的思路與方法。

作者簡(jiǎn)介

王燁，現(xiàn)在是美團(tuán)點(diǎn)評(píng)旅游后臺(tái)研發(fā)組的工程師，之前曾經(jīng)在百度、去哪兒和優(yōu)酷工作過(guò)，專(zhuān)注Java后臺(tái)開(kāi)發(fā)。對(duì)于網(wǎng)絡(luò)編程和并發(fā)編程具有濃厚的興趣，曾經(jīng)做過(guò)一些基礎(chǔ)組件，也翻過(guò)一些源碼，屬于比較典型的宅男技術(shù)控。期待能夠與更多知己，在coding的路上并肩前行~
聯(lián)系郵箱：wangye03@meituan.com

from:?http://tech.meituan.com/clean-code.html

總結(jié)

以上是生活随笔為你收集整理的聊聊clean code的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。