讀代碼整潔之道
現(xiàn)在的軟件系統(tǒng)開發(fā)難度主要在于其復(fù)雜度和規(guī)模，客戶需求也不再像Winston Royce瀑布模型期望那樣在系統(tǒng)編碼前完成所有的設(shè)計(jì)滿足用戶軟件需求。在這個(gè)信息爆炸技術(shù)日新月異的時(shí)代，需求總是在不停的變化，隨之在2001年業(yè)界17位大牛聚集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場，提出了“Agile”（敏捷）軟件開發(fā)價(jià)值觀，并在他們的努力推動(dòng)下，開始在業(yè)界流行起來。在《代碼整潔之道》（Clean Code），提出一種軟件質(zhì)量，可持續(xù)開發(fā)不僅在于項(xiàng)目架構(gòu)設(shè)計(jì)，還與代碼質(zhì)量密切相關(guān)，代碼的整潔度和質(zhì)量成正比，一份整潔的代碼在質(zhì)量上是可靠的，為團(tuán)隊(duì)開發(fā)，后期維護(hù)，重構(gòu)奠定了良好的基礎(chǔ)。在這本書中作者提出了注重實(shí)際開發(fā)實(shí)踐的細(xì)節(jié)，而不是站在空洞的理論來談?wù)撜麧嵵馈?/p>
什么是整潔代碼？不同的人會(huì)站在不同的角度闡述不同的說法。而我最喜歡的是Grady Booch（《面向?qū)ο蠓治雠c設(shè)計(jì)》作者）闡述：
“整潔的代碼簡單直接。整潔的代碼如同優(yōu)美的散文。整潔的代碼從不隱藏設(shè)計(jì)者的意圖，充滿了干凈利落的抽象和直截了當(dāng)?shù)目刂普Z句。”
整潔的代碼就是一種簡約（簡單而不過于太簡單）的設(shè)計(jì)，閱讀代碼的人能很清晰的明白這里在干什么，而不是隱澀難懂，整潔的代碼讀起來讓人感覺到就像閱讀散文-藝術(shù)的沉淀，作者是精心在意締造出來。
一：命名
命名包括變量、函數(shù)、參數(shù)，類等，一個(gè)好的命名能夠很好的表述其所承載的業(yè)務(wù)，從命名上就已經(jīng)很好的答復(fù)了為什么存在，做了什么事，應(yīng)該怎么用等的大部分的問題，閱讀者看到它的時(shí)候不必去深究其實(shí)現(xiàn)細(xì)節(jié)，一切都在命名上一目了然。一個(gè)好的命名必須是名副其實(shí)，不存在歧義（雙關(guān)語或常見屬于沖突），直接了當(dāng)（否定語句或者誤導(dǎo)性命名）。
二：函數(shù)：
從匯編/C時(shí)代開始的到現(xiàn)在函數(shù)一直都存在與我們開發(fā)中不可或缺的一部分，結(jié)構(gòu)化組織，重用.作為函數(shù)式語言的一等公民，所有程序的第一組代碼。
好的函數(shù)必須足夠的小，其次還是足夠的小。很容易想像閱讀上千行的代碼，是多么巨大的自我心理挑戰(zhàn)，在實(shí)習(xí)的時(shí)候工作于毫無分層邏輯的WinForm平臺(tái)下，完全依賴RAD模式帶來后置cs頁面上千行的代碼，每次修改都令我惱怒，恨不得重寫整個(gè)業(yè)務(wù)邏輯。
一個(gè)函數(shù)在于短小精悍，只作一件事情，并做好這件事，只做一件事才能得到更好的利用函數(shù)名表述自己。
好的函數(shù)還應(yīng)該是CQS（查詢命令分離）無副作用的（不存在隱藏歧義的背后邏輯），并對其他類型不存在“依戀情節(jié)(Feature Envy)“（類中的變量被所有的函數(shù)使用這是理想的高內(nèi)聚，萬物皆有其位，而后物盡歸其位）。
函數(shù)的參數(shù)應(yīng)該足夠的少，無最好，一次之，再次為二，盡量避免三個(gè)以及三個(gè)以上，對于太多的參數(shù)你可能該采用IntroduceParameterObject(引入?yún)?shù)對象)。
重復(fù)的代碼。重復(fù)在軟件系統(tǒng)是萬惡的,我們熟悉的分離關(guān)注點(diǎn)，面向?qū)ο螅O(shè)計(jì)原則…都是為了減少重復(fù)提高重用，Don’t repeat yourself！(DRY)。
三：注釋、格式：
并不是寫出完備的注釋就是好的開發(fā)人員，如果代碼清晰的表述自己意圖，那么注釋反而多余。在《重構(gòu)-改善現(xiàn)有代碼之道》中Martin Fowler指出多余的注釋是一種代碼壞味道。就是好的注釋隨著項(xiàng)目的維護(hù)不斷的重構(gòu)很多時(shí)候也會(huì)變得不那么適應(yīng)，而我們很少會(huì)去主動(dòng)維護(hù)。再則誤導(dǎo)性的注釋更為使用者所憎恨。當(dāng)然有時(shí)我們也得使用注釋，注釋并不是萬惡的，當(dāng)我們沒法用代碼來描述自己的時(shí)候，我們需要注釋去描述意圖；多余有副作用的代碼給使用者提供警告注釋。TODO開發(fā)時(shí)進(jìn)度控制，比如你在進(jìn)行較大規(guī)模領(lǐng)域重構(gòu)，目前有些邏輯不再適應(yīng)，不那么自然，而對它的重構(gòu)還在任務(wù)列表最后，你可以選擇標(biāo)注在TODO中，最后完成從ToDoList中去掉每一個(gè)TODO任務(wù)。
良好的代碼格式，會(huì)使得我們閱讀更容易，一套共同的格式會(huì)讓我們查找理解更快速。每個(gè)團(tuán)隊(duì)都應(yīng)該遵循一套固定的代碼格式規(guī)范，整個(gè)軟件系統(tǒng)的統(tǒng)風(fēng)格統(tǒng)一，而不是各自為政各成一體。
四：對象和數(shù)據(jù)結(jié)構(gòu)：
數(shù)據(jù)結(jié)構(gòu)指的就是數(shù)據(jù)的載體，暴露數(shù)據(jù)，而幾乎沒有有意義的行為的貧血類。最常見的應(yīng)用在分布式服務(wù)，以wcf，webservice，reset之類的分布式服務(wù)中不可或缺的數(shù)據(jù)傳輸對象（DTO）模式，DTO（Request/Response）就是一個(gè)很典型的數(shù)據(jù)載體，只存在簡單的get，set屬性，并且更傾向于作為值對象存在。而對象則剛好相反作為面向?qū)ο蟮漠a(chǎn)物，必須封裝隱藏?cái)?shù)據(jù)，而暴露出行為接口，DDD中領(lǐng)域模型傾向于對象不僅在數(shù)據(jù)更多暴露行為操作自己或者關(guān)聯(lián)狀態(tài)。
數(shù)據(jù)結(jié)構(gòu)和對象之間看是細(xì)微的差別卻導(dǎo)致了不同的本質(zhì)區(qū)別：使用數(shù)據(jù)結(jié)構(gòu)的代碼便于在不改動(dòng)現(xiàn)在數(shù)據(jù)結(jié)構(gòu)的前提下添加新的行為（函數(shù)），面向?qū)ο蟠a則便于不改動(dòng)現(xiàn) 有函數(shù)的前提下添加新的類。換句話說就是數(shù)據(jù)結(jié)構(gòu)難以添加新的的數(shù)據(jù)類型，因?yàn)樾枰膭?dòng)所有函數(shù)，面向?qū)ο蟮拇a則難以添加新的函數(shù)，因?yàn)樾枰薷乃械念悺Ｔ谌魏我粋€(gè)復(fù)雜的系統(tǒng)都會(huì)同時(shí)存在數(shù)據(jù)結(jié)構(gòu)和對象，我們需要判斷的是我們需要的是需要添加的新的數(shù)據(jù)類型還是新的行為函數(shù)。
隱藏作為面向?qū)ο笾饕匦灾械淖钪匾匦裕庋b隱藏是面向?qū)ο笾凶钪匾奶匦裕粋€(gè)好的面向?qū)ο蟠a肯定是對對象的內(nèi)部細(xì)節(jié)做到很好的隱藏封裝，封裝過后才有是多態(tài)，委派之類的。一個(gè)好的面向?qū)ο蟮拇a一定是具有很好的隱藏封裝，易于測試，不穩(wěn)定因素往往集中在一處很小或者固定的位置，不穩(wěn)定因素的變更不會(huì)導(dǎo)致更大面積的修改擴(kuò)散。
對象的隱藏要求：方法不應(yīng)和任何調(diào)用方法返回的對象操作，換句話之和朋友說話，不和陌生人說話（迪米特法則，或被譯為最小知識(shí)原則），比如：ctxt.getOptions().getSearchDir().getAbsolutePath()，就是迪米特法則的反例模式。
五：異常處理：
每個(gè)軟件系統(tǒng)都避不開異常處理，需要防止它搞亂我們的邏輯。
利用異常處理代替返回異常編碼，返回異常編碼會(huì)是的代碼中充滿了if/else，switch/case擾亂我的代碼流轉(zhuǎn)。
對于特定異常撲捉，可以面向異常編程，編寫特定的異常類，使得對異常封裝轉(zhuǎn)化，更容易捕善后獲處理。
避免返回null，在軟件系統(tǒng)中最常見頭疼的就是NullReferenceException。在非特定場景下，我們應(yīng)該極力的避免返回null。面對這種場景我們可以采用null object Pattern（空對象模式）返回特例對象，如c#類庫中的Guid.Empty，string.Empty；對于集合類型我們可以返回長度0的空集合而非null；
六：邊界：
在系統(tǒng)開發(fā)中不可能一切都得從零開始，自己寫所有的代碼，更好的方案是需要整合一些開源或者第三方的項(xiàng)目，為我所用。但是不能讓這些非自己的代碼滲侵中我們的代碼各處，有一些所以功能很強(qiáng)大的第三方產(chǎn)品，但不一定具有很好的抽象。很多時(shí)候我更寧愿花些時(shí)間抽象出我們自己所需要的接口在第三方類庫上外覆一層自己的抽象，這樣不僅便于TDD，因?yàn)槲覀兡軌蚝芎玫膭?chuàng)建偽對象，使的測試獨(dú)立不依賴外部資源，得到快速反饋；而且在設(shè)計(jì)上得到很好的擴(kuò)展，當(dāng)由于某些原因如第三方類庫不再能滿足業(yè)務(wù)需求，或者權(quán)益收費(fèi)等等，我們可以很好的切換底層而使得修改不會(huì)擴(kuò)散到系統(tǒng)各處。外覆類也是處理遺留代碼帶入測試容器的一種很好實(shí)踐。
七:單元測試：
TDD中測試代碼在往往和產(chǎn)品代碼差不多，在系統(tǒng)中占據(jù)一半的代碼量，不好的測試代碼也可能拖累項(xiàng)目的開發(fā)。整潔的測試代碼應(yīng)該是遵循first原則的：
快速（Fast）：測試應(yīng)該快速，因?yàn)樾枰粩嗟倪\(yùn)行測試得到反饋，我們需要的快速反饋，錯(cuò)誤的快速定位。所以你的測試就不能依賴太多的外部資源，數(shù)據(jù)庫，硬件環(huán)境等等，對于這些外部資源應(yīng)該采用偽對象模式來隔離。
獨(dú)立（Independent）：測試應(yīng)該是獨(dú)立的，獨(dú)立于測試用例之間，獨(dú)立于特定的環(huán)境，獨(dú)立于測試的運(yùn)行順利。數(shù)據(jù)的獨(dú)立通常采用兩種獨(dú)立方式，每個(gè)測試環(huán)境的獨(dú)立，很多時(shí)候我們希望每個(gè)測試運(yùn)行完成后環(huán)境（如數(shù)據(jù)庫）和運(yùn)行前保持一致，如數(shù)據(jù)庫高層次測試我們更希望在每次測試完成后不會(huì)帶來多余或者改變數(shù)據(jù)。再則就是數(shù)據(jù)的隔離，我們的行為測試（BDD，集成高角度的測試）都會(huì)依賴一些固定的信息，通常是登陸系統(tǒng)的人員，我們可以采用么個(gè)測試建立一個(gè)不同的登陸人員來使的每個(gè)測試之間的s數(shù)據(jù)隔離。
可重復(fù)（Repeatable）：測試應(yīng)該可以在任何環(huán)境下可重復(fù)，可運(yùn)行，因?yàn)闇y試獨(dú)立于環(huán)境外部資源。
自足驗(yàn)證（Self-Validation）：測試應(yīng)該有通過失敗的標(biāo)示，從每一個(gè)測試上能得到一處代碼邏輯的通過失敗。每個(gè)測試都有對同一件事物的一種行為的斷言，也之?dāng)嘌砸患拢瑥亩軌蚝芎玫腻e(cuò)誤定位，避免高技巧性的測試。
及時(shí)（Timely）：測試應(yīng)該是及時(shí)編寫的，TDD要求測試必須在實(shí)現(xiàn)代碼之前，提前以使用者的角度定義使用接口方式。如果你是在編碼后補(bǔ)測試，你的測試覆蓋很可能不夠，而且容易定式于實(shí)現(xiàn)的邏輯寫測試，很多時(shí)候?qū)τ谳^低層次的測試也不是那么容易寫的。一個(gè)設(shè)計(jì)良好的代碼必須也是可測試的。
八：類：
面向?qū)ο蟮南嗨菩袨榈某橄螅瘮?shù)代碼塊的組織形式，在面向?qū)ο笾形覀兊能浖到y(tǒng)是由眾多的類和類之間的交互協(xié)作完成了。面向?qū)ο筇卣鳎悍庋b，繼承，多態(tài)度，委派。一個(gè)設(shè)計(jì)良好的類該是具有良好的封裝，站在使用者的調(diào)度考慮那些是使用接口，那些是內(nèi)部細(xì)節(jié)；這是面向?qū)ο笞钪饕奶卣鳎怯袝r(shí)會(huì)與測試沖突，可以適當(dāng)?shù)姆砰_并僅限于于測試調(diào)用。繼承和多態(tài)在面向?qū)ο笾锌梢詫?shí)現(xiàn)重用，但我更傾向于繼承不是為了重用，而是隔離變化；大量的濫用繼承不干凈的繼承體系將會(huì)導(dǎo)致龐大的繼承體系，繼承體系中眾多職責(zé)重復(fù)在各個(gè)同級(jí)派生類，理想的繼承應(yīng)該是滿足里氏替換原則（LSP：每個(gè)父類出現(xiàn)的地方都應(yīng)該可以被派生類所替換，并且能正確的工作）；面oo第二原則組合優(yōu)先。而委派則是一個(gè)類把部分功能委派給其他類來完成，體現(xiàn)類之間的協(xié)作，類似組合。
類第一原則應(yīng)是是小并足夠的小。但與函數(shù)不同的是函數(shù)以代碼行數(shù)統(tǒng)計(jì)，而類以權(quán)責(zé)統(tǒng)計(jì)。
單一原則（SRP），體現(xiàn)了類只應(yīng)該做一件事，并且做好它，這樣變化修改的理由只有他所做的事。良好的軟件設(shè)計(jì)中系統(tǒng)是由一組大量的短小的類和他們之間功能協(xié)作完成的，而不是幾個(gè)上帝類。
內(nèi)聚：高內(nèi)聚低耦合：提出與結(jié)構(gòu)化編程，內(nèi)聚表述模塊內(nèi)部功能不同操作邏輯之間的距離，如果一個(gè)類的每個(gè)變量都被每個(gè)方法所使用為最大的內(nèi)聚；耦合描述模塊之間的依賴程度；高內(nèi)聚低耦合以簡單的方式表述就是功能完備（高內(nèi)聚）對象之間是通過穩(wěn)定的接口（低耦合）交互的。
依賴倒置（DIP）：描述組件之間高層組件不應(yīng)該依賴于底層組件。依賴倒置是指實(shí)現(xiàn)和接口倒置，采用自頂向下的方式關(guān)注所需的底層組件接口，而不是其實(shí)現(xiàn)。DI模式很好的就是應(yīng)用IOC（控制反轉(zhuǎn)）框架，構(gòu)造方式分為分構(gòu)造注入，函數(shù)注入，屬性注入；.net平臺(tái)流行的IOC框架有Unity，Castle windsor，Ninject，Autofac等框架支持，
九：并發(fā)編程：
并發(fā)是一種時(shí)間(When)和目的(What)的解耦,提供應(yīng)用程序的吞吐量，提高cpu利用率；但是并發(fā)編碼不是那么容易，再加上臨界資源競爭死鎖。在并發(fā)編程的時(shí)候我們必須盡量遵守一些原則：
并發(fā)已經(jīng)足夠復(fù)雜，我們更需要代碼分離，分離線程相關(guān)代碼和非線程相關(guān)代碼，單一權(quán)責(zé)，盡可能降低其復(fù)雜度。
限制臨街資源的作用域，為臨界資源加鎖是防止并發(fā)的策略，但是必須正確的加鎖，如果形成等待環(huán)，就導(dǎo)致死鎖。
利用數(shù)據(jù)副本（值對象或者克隆）在線程之間傳遞數(shù)據(jù)，避免線程之前操作的并發(fā)影響；線程獨(dú)立，使其在自己的環(huán)境中運(yùn)行，不能其他線程共享數(shù)據(jù)。
對于臨界資源加鎖應(yīng)盡量保持加鎖范圍盡可能的小。
更多關(guān)于簡單設(shè)計(jì)，迭進(jìn)，逐步編程代碼，壞味道，并發(fā)示例請參見代碼整潔之道。
原文鏈接：http://www.cnblogs.com/whitewolf/archive/2012/07/31/2617473.html
【編輯推薦】
