“相對于任何宏偉景愿，對細(xì)節(jié)的關(guān)注甚至是更為關(guān)鍵的專業(yè)性基礎(chǔ)。首先，開發(fā)者通過小型實(shí)踐獲得可用于大型實(shí)踐的技能和信用度。其次，宏偉建筑中最細(xì)小的部分，比如關(guān)不緊的門，有點(diǎn)兒沒有鋪平的地板，甚至是凌亂的桌面，都會(huì)將整個(gè)大局的魅力毀滅殆盡。這就是整潔代碼之所系”----沒有比書中的這段話更能說明這本書的意義了。

《代碼整潔之道》是第1期書山有路活動(dòng)選出的讀本。相對于記住那些如何寫出整潔代碼的那些法則，養(yǎng)成保持代碼整潔、提高代碼質(zhì)量的習(xí)慣和思維更為重要。全書大致分為三個(gè)部分，第一部分1-10章都是介紹如函數(shù)、類、命名、單元測試等保持整潔的建議。第二部分11-13章從系統(tǒng)設(shè)計(jì)的層面提倡用AOP、IOC等方式保持整潔，或者合適的時(shí)候使用并發(fā)編程。第三部分14-17章以及后面的附錄，作者以JAVA源碼（全書都是以JAVA代碼示例）來實(shí)際講解如何保持整潔。

later equals never

我們都曾經(jīng)瞟一眼自己親手造成的混亂，決定棄之不顧，走向新的一天。我們都曾經(jīng)看到自己的爛程序居然能運(yùn)行，然后斷言能運(yùn)行的爛程序總比什么都沒有強(qiáng)，我們都曾經(jīng)說過有朝一日再回頭清理。當(dāng)然，在那些日子里。我們都沒有聽過布朗法則：later equals never?稍后等于永不.

ps:看到這句話確實(shí)有點(diǎn)慚愧。印象最深的感覺就是，我們?nèi)タ匆粌赡昵白约旱拇a。那是寫的什么玩意，真的是自己都看不下去。要讓我改，我情愿再實(shí)現(xiàn)一個(gè)。所以時(shí)刻保持好的習(xí)慣是多么重要。不要想著以后再解決。就像領(lǐng)導(dǎo)說，這個(gè)事情以后再考慮，然后就沒有然后了。

第一章 整潔代碼

怎樣是整潔的代碼？

Bjarne Stroustrup（C++發(fā)明者） 說：

“我喜歡優(yōu)雅和高效的代碼，代碼邏輯應(yīng)當(dāng)直接了當(dāng)，叫缺陷難以隱藏；盡量減少依賴關(guān)系，使之便于維護(hù)；依據(jù)某種分層戰(zhàn)略完善錯(cuò)誤處理代碼；性能調(diào)至最優(yōu)，省得引誘別人做沒有必要的優(yōu)化，搞出一堆混亂來，整潔的代碼之做好一件事?！?/p>

Ron Jeffries 對整潔代碼的理解：

1.能通過所有的測試。

2.沒有重復(fù)代碼。

3.體現(xiàn)系統(tǒng)中的全部設(shè)計(jì)理念。

4.包含盡量少的實(shí)體、比如類、方法、函數(shù)等。

“在以上諸項(xiàng)中，我最在意的是代碼重復(fù)。如果一段代碼重復(fù)出現(xiàn)，就表示某種想法未在代碼中得到良好的提現(xiàn)。我會(huì)盡力去找出到底那是什偶么，然后在盡力的更清晰的表達(dá)出來。”

PS：總結(jié)下就是整潔的代碼1.職責(zé)明確，沒有多余，2.減少依賴，便于維護(hù)。3.高效。

第二章 ?有意義的命名

1.名副其實(shí)。 說起來很簡單。選個(gè)好名字需要花時(shí)間，但省下的時(shí)間比花掉的多。注意命名，一旦有好的命名，就換掉舊的。

intd;//消失的時(shí)間，以日計(jì)。intelapsedTimeInDays;

PS:Ctrl+R+R蠻好用的。實(shí)際中的情況要比我貼出來的復(fù)雜。我們定義不同的變量，能夠看到名字就知道是什么意思，這是最基本的要求了。

2.避免誤導(dǎo)。比如不是List類型，就不要用個(gè)accountList來命名，這樣形成誤導(dǎo)。

3.做有意的區(qū)分。

Public static void copyChars(chara1[],chara2[]){for(inti=0;i

a2[i]=a1[i];

} }

如果參數(shù)名稱改為source和destination ，這個(gè)函數(shù)就會(huì)像樣很多。廢話都是冗余的，Variable一詞?永遠(yuǎn)不應(yīng)當(dāng)出現(xiàn)在變量名中。Table一詞永遠(yuǎn)不應(yīng)當(dāng)出現(xiàn)在表名中。NameString 會(huì)比 Name好嗎，難道Name 會(huì)是一個(gè)浮點(diǎn)數(shù)不成？如有一個(gè)Customer的類，有又一個(gè)CustomerObject的類。是不是就凌亂了。

4.使用便于搜索的的名稱

單個(gè)字母或者數(shù)字常量是很難在一大堆文章中找出來。比如字母e，它是英文中最常用的字母。長名勝于短名稱，搜得到的名稱勝于自編的名稱。 竊以為單字母的名稱僅用于短方法中的本地變量。名稱長短應(yīng)與其作用域大小相對應(yīng)。

5.類名應(yīng)該是名詞或短語，像Customer，Account，避免使用Manager,Processor,Data或者Info這樣的類名。類名不應(yīng)當(dāng)是動(dòng)詞。方法名應(yīng)該是動(dòng)詞或動(dòng)詞短語，如postPayment ,deletePage或Save，屬性訪問、修改和斷言應(yīng)該根據(jù)其值來命名，并加上get，set，is這些前綴。

6.別扮可愛，耍寶，比如誰知道HolyHandGrenada 函數(shù)是干什么的，沒錯(cuò)這個(gè)名字挺伶俐，但是不過DeleteItems或許是更好的名字。

7.每個(gè)概念對應(yīng)一個(gè)詞。并且一以貫之。

在一堆代碼中有Controller，又有manager，driver。就會(huì)令人困惑。比如DeviceManager和Protal-Controller之間又什么本質(zhì)區(qū)別？

第三章 函數(shù)

1.函數(shù)的第一規(guī)則是要短小，第二條規(guī)則是還要更短小。

2.函數(shù)應(yīng)該做一件事。做好這件事。只做這一件事。

3.盡量少的函數(shù)參數(shù)。有兩個(gè)參數(shù)的函數(shù)要比一元函數(shù)的難懂。如果需要三個(gè)或者三個(gè)以上的參數(shù)應(yīng)該封裝成類了。

4.不要重復(fù)自己。

PS:如果一段相同的代碼出現(xiàn)了兩次，你是不是覺得自己改做些什么了。

第四章 注釋

注釋的恰當(dāng)用法是彌補(bǔ)我們在用代碼表達(dá)意圖時(shí)遭遇的失敗。作者認(rèn)為注釋是一種失敗，我們總無法找到不用注釋就能表達(dá)自我的方法，所以總要有注釋，這并不值得慶賀。寫注釋的常見動(dòng)機(jī)之一是糟糕代碼的存在。帶有少量注釋的整潔而有表達(dá)力的代碼，要比帶有大量注釋的零碎而復(fù)雜的代碼像樣的多。與其花時(shí)間編寫解釋你搞出的糟糕的代碼注釋，不如花時(shí)間清潔那堆糟糕的代碼。

PS:這段話看起來可能有些過激。我們確實(shí)可以通過好的編碼習(xí)慣減少不必要的注釋。不過現(xiàn)在自動(dòng)生成文檔的技術(shù)都是從代碼的注釋中提取的。如果是這種情況，上司肯定是要求你寫完備的注釋的。

好注釋：

1. 法律信息。有時(shí)，公司代碼規(guī)范要求編寫與法律有關(guān)的注釋。例如版權(quán)和著作申明。

2.提供信息的注釋。

//returen an instance of the Responder being testedprotectedabstractResponder responderInstance();

不過作者認(rèn)為?將函數(shù)名 重新命名為 responderBeingTested 注釋就是多余的。

3.對意圖的解釋。?有時(shí)注釋不僅提供了有關(guān)實(shí)現(xiàn)的有用信息，而且還提供了某個(gè)決定后面的意圖。

4.闡釋。 有時(shí)注釋把某種晦澀難明的參數(shù)或返回值的意義翻譯為某種可讀形式。也會(huì)是有用的。特別是參數(shù)或者返回值是某個(gè)標(biāo)準(zhǔn)庫的一部分，或者你不能修改代碼，那幫助闡釋其含義的代碼就會(huì)有用，例如:

assertTrue(bb.compareTo(ba)==1);//bb>aaassertTrue(a.compareTo(b)==-1);//a

直接看方法可能不明確，但有注釋就明白多了。我看這2,3,4都是一個(gè)意思。就是說明是干嘛的。

5.警示，告訴別人要注意這個(gè)方法之類的。

6.放大。有的代碼可能看著有點(diǎn)多余，但編碼者當(dāng)時(shí)是有他自己的考慮，這個(gè)時(shí)候需要注釋下這個(gè)代碼的重要性。避免后面被優(yōu)化掉。

第五章 格式

縱向格式：

1. 函數(shù)與函數(shù)之間留空行。

2.變量聲明：變量聲明應(yīng)該盡可能靠近其使用位置。因?yàn)楹瘮?shù)很短，本地變量應(yīng)該在函數(shù)的頂部出現(xiàn)。

3.實(shí)體變量 應(yīng)該在內(nèi)的頂部，相當(dāng)于我們的field 字段，會(huì)被使用的多。

4.相關(guān)函數(shù)，如果某個(gè)函數(shù)調(diào)用另外一個(gè)，就應(yīng)該把他們放在一起，而且調(diào)用者應(yīng)該盡可能放在被調(diào)用者的上面。這樣這個(gè)程序就會(huì)自然有序。（之前我喜歡把private的方法 放到一起。當(dāng)然這確實(shí)沒有什么實(shí)際的意義）

5.“相關(guān)概念的代碼放在一起。相關(guān)性越強(qiáng)，比如一個(gè)大功能邏輯靠在一起?！?（更多的時(shí)候我喜歡用 region 來收起來。）

橫向格式：

1.一行的長度，作者建議是上限是120個(gè)字符

PS 平時(shí)我們都是按照自己的屏幕大小來決定，當(dāng)然太長了，自己也不便閱讀，又不是壓縮的js文件

2.賦值語句兩端留空。

a = b ;

3.不在函數(shù)名和左括號(hào)間加空格。因?yàn)楹瘮?shù)與其參數(shù)密切相關(guān)。

4.縮進(jìn)。源文件是一種繼承結(jié)構(gòu)，而不是一種大綱結(jié)構(gòu)，繼承結(jié)構(gòu)中的每一層級(jí)都圈出一個(gè)范圍， 也就是代碼塊，其中有聲明語句和執(zhí)行語句。要體現(xiàn)這種繼承結(jié)構(gòu)，就要對源代碼進(jìn)行縮進(jìn)處理。但有時(shí)候我們會(huì)把if語句，while循環(huán)，或小函數(shù)寫成一行，但這樣沒有層級(jí)的概念，不便閱讀，還是縮進(jìn)的好。

第六章 對象和數(shù)據(jù)結(jié)構(gòu)

1.過程式代碼（函數(shù)編程）便于在不改動(dòng)既有數(shù)據(jù)結(jié)構(gòu)的前提下添加新函數(shù)，面向?qū)ο蟠a便于在不改動(dòng)既有函數(shù)的前提下添加新類。反過來講也說的通,過程式代碼難以添加新的數(shù)據(jù)結(jié)構(gòu)，因?yàn)楸仨毿薷乃泻瘮?shù)，面向?qū)ο蟠a難以添加新函數(shù)，因?yàn)楸仨毿薷乃蓄?。所以在設(shè)計(jì)的時(shí)候要分析好是以后是要添加新函數(shù)還是要添加新的數(shù)據(jù)結(jié)構(gòu)。

2.德墨忒爾律：模塊不應(yīng)該了解它所操作對象內(nèi)部情形。比如C的方法f只能調(diào)用以下對象的方法。

C

由f創(chuàng)建的對象

作為參數(shù)傳遞給f的對象

C的實(shí)體變量持有的變量

varoutpath=cxt.getOptions().getScart().getAbsolutePath();

這個(gè)代碼就違反了上面的德墨忒爾律，調(diào)用了返回值的方法。這樣就是暴露了內(nèi)部結(jié)構(gòu)。

第七章 異常處理

1.try代碼就像是事務(wù)，catch代碼塊將程序維持在一種持續(xù)狀態(tài)。在編寫可能拋出異常的代碼時(shí)，最好先寫出try-catch-finally 語句。

2.根據(jù)需要定義異常類。對錯(cuò)誤分類的方式有多種，可以依據(jù)來源，是組件還是其他地方，或者依據(jù)類型，是設(shè)備錯(cuò)誤還是網(wǎng)絡(luò)錯(cuò)誤。不過在我們定義異常類的時(shí)候，最重要的考慮是如何捕獲它們。

3.別返回null值。程序中不斷的看到檢測null值的代碼，一處漏掉檢測就可能會(huì)失控。返回Null，作者認(rèn)為這種代碼很糟糕。建議拋出異常 或者返回特定對象（默認(rèn)值）。更早的發(fā)現(xiàn)問題。同理，也應(yīng)該避免傳遞Null值給其他的方法。

PS:在大多數(shù)的編程語言中，沒有良好的方法能對付由調(diào)用者意外傳入的null值。我們發(fā)布產(chǎn)品應(yīng)該有容錯(cuò)的機(jī)制，程序不能輕易的就崩掉，有異常應(yīng)該及時(shí)記錄下來或給出提示。

第八章 邊界

有時(shí)候我們在使用第三方程序包或者開源代碼的時(shí)候，或者依靠公司其他團(tuán)隊(duì)的代碼，我們都得干凈利落的的整合進(jìn)自己的代碼中。這一章就是介紹保持保持軟件邊界整潔的實(shí)踐手段和技巧。

1.對第三方進(jìn)行學(xué)習(xí)性測試，當(dāng)?shù)谌匠绦虬l(fā)布了新的版本，我們可以允許學(xué)習(xí)性測試，看看程序包的行為有沒有發(fā)生改變。

2.使用尚不存在的代碼，有時(shí)候我們的第三方，還沒有開發(fā)好API，但又不能影響到我們的開發(fā)進(jìn)度，所以我們先可以定義好自己想要的接口。如果第三方ok了，我們再對接起來。

3.通過接口管理第三方邊界，可以使用ADApter模式將我的接口轉(zhuǎn)換為第三方提供的接口。這個(gè)是要注意，第三方的代碼和自己的代碼混合太多，這樣不便管理。

第九章 ?單元測試

敏捷和TDD運(yùn)動(dòng)鼓舞了許多程序員編寫自動(dòng)化單元測試，單元測試是確保代碼中的每個(gè)犄角旮旯都如我們所愿的工作。

TDD三定律

除非這能讓失敗的單元測試通過，否則不允許去編寫任何的生產(chǎn)代碼。

只允許編寫剛好能夠?qū)е率〉膯卧獪y試。 （編譯失敗也屬于一種失敗）

只允許編寫剛好能夠?qū)е乱粋€(gè)失敗的單元測試通過的產(chǎn)品代碼。

PS:什么是生產(chǎn)代碼，這里有點(diǎn)迷惑。

測試代碼和生產(chǎn)代碼一樣重要，它可不是二等公民，它需要被思考、被設(shè)計(jì)和北照料。它該像生產(chǎn)代碼一樣保持整潔。單元測試讓你的代碼可擴(kuò)展，可維護(hù)，可復(fù)用。原因很簡單，有了測試，你就不擔(dān)心對代碼的修改，沒有單元測試，每次修改可能帶來缺陷，一個(gè)測試，一個(gè)斷言。一個(gè)測試，對應(yīng)一個(gè)概念。我們不想要超長的測試函數(shù)。

測試還應(yīng)遵守以下5條規(guī)則。

1.快速 測試應(yīng)該能快速運(yùn)行，太慢了你就不會(huì)頻繁的運(yùn)行，就不會(huì)盡早的發(fā)現(xiàn)問題。

2.獨(dú)立。測試應(yīng)該相互獨(dú)立，某個(gè)測試不應(yīng)該為下個(gè)測試設(shè)定條件。當(dāng)測試相互依賴，一個(gè)沒通過導(dǎo)致一連串的測試失敗，使問題診斷變的困難。

3.可重復(fù)。測試應(yīng)該可以在任何環(huán)境中重復(fù)通過。

4.自足驗(yàn)證 測試應(yīng)該有布爾值輸出，無論通過或失敗，不應(yīng)該是查看日志文件去確認(rèn)

5.及時(shí)。單元測試應(yīng)該恰好在使其通過的生產(chǎn)代碼之前編寫。

PS 不知道實(shí)際開發(fā)中，各個(gè)公司是怎么要求的。團(tuán)隊(duì)開發(fā)會(huì)有要求單元測試，個(gè)人開發(fā)我?guī)缀跏菦]有寫單元測試了。

第十章 ?類

1.類應(yīng)該短小

2.單一權(quán)責(zé)原則(SRP)：類或模塊應(yīng)有且只有一條加以修改的理由。系統(tǒng)應(yīng)該有許多短小的類而不是巨大的類組成。

PS：每個(gè)達(dá)到一定規(guī)模的系統(tǒng)都會(huì)包括大量邏輯和復(fù)雜性。管理這種復(fù)雜性的首要目標(biāo)就是加以組織，以便開發(fā)者在哪兒能找到東西，反之，擁有巨大、多目的的類的系統(tǒng)，總是讓我們在目前并不需要了解的一大堆東西中艱難的跋涉。

3.內(nèi)聚：如果一個(gè)類中的每個(gè)變量都被每個(gè)方法所使用，則該類具有最大的內(nèi)聚性。內(nèi)聚性高，意味著類中的方法和變量相互依賴，相互結(jié)合成一個(gè)邏輯整體。

4.為了修改而組織。開放閉合原則（OCP）：類應(yīng)當(dāng)對擴(kuò)展開放，對修改封閉。我們可以借助接口和抽象類來隔離這些細(xì)節(jié)帶來的影響。

第十一章：系統(tǒng)

將系統(tǒng)的構(gòu)造和使用分開：構(gòu)造和使用是不一樣的過程。

PS：修建一棟大樓的時(shí)候，起重機(jī)和升降機(jī)在外面，工人們穿著安全服在忙碌。當(dāng)大樓建設(shè)完成，建筑物變得整潔，覆蓋著玻璃幕墻和漂亮的漆色。在其中工作的人，看完完全不同的景象。軟件也是如此，將關(guān)注的方面分離。

1.工廠，有時(shí)候應(yīng)用程序需要確定何時(shí)創(chuàng)建對象，我們可以使用抽象工廠模式。將構(gòu)造的細(xì)節(jié)隔離于應(yīng)用程序之外。

2.依賴注入（DI/IOC）。在依賴管理情景中，對象不應(yīng)該負(fù)責(zé)實(shí)例化對自身的依賴，反之，它應(yīng)該將這份權(quán)責(zé)移交給其他有權(quán)利的機(jī)制，從而實(shí)現(xiàn)控制的反轉(zhuǎn)。

PS 現(xiàn)在的依賴注入組件比較多了，Autofac，Ninject等。

3.擴(kuò)容：“一開始就做對的系統(tǒng)”純屬神話，反之，我們應(yīng)該只實(shí)現(xiàn)今天的用戶的需求。然后重構(gòu)，明天再擴(kuò)容系統(tǒng)，實(shí)現(xiàn)新用戶的需求。這就是迭代和增量敏捷的精髓所在。?就像城市不斷的再拆掉，再建設(shè)。

4.面向切面編程。AOP中，被稱為方面（aspect）的模塊構(gòu)造指明了系統(tǒng)中哪些點(diǎn)的行為會(huì)以某種一致的方式被修改，從而支持某種特定的場景。這種說明是用某種簡潔的聲明(Attribute)或編程機(jī)制來實(shí)現(xiàn)的。

PS:MVC的Filter是個(gè)很好的AOP，可以從權(quán)限驗(yàn)證，方法進(jìn)入前，方法進(jìn)入后，返回結(jié)果前，返回結(jié)果后等這幾個(gè)橫切面進(jìn)行編程。更好的組織代碼。第十，十一章講的設(shè)計(jì)只是一少部分。更多的可能要去參考專門講設(shè)計(jì)模式之類的書。

第十二章 迭進(jìn)

1.簡單設(shè)計(jì)規(guī)則 1：運(yùn)行所有測試。

緊耦合的代碼難以編寫測試。同樣編寫測試越多，就會(huì)越遵循DIP之類的原則，使用依賴注入，接口和抽象等工具盡可能減少耦合。如此一來設(shè)計(jì)就會(huì)有長足進(jìn)步。遵循有關(guān)編寫測試并持續(xù)運(yùn)行測試的、明確的規(guī)則，系統(tǒng)就會(huì)更貼近OO低耦合度、高內(nèi)聚的目標(biāo)。

2.簡單設(shè)計(jì)規(guī)則2 重構(gòu)：

在重構(gòu)過程中，可以應(yīng)用有關(guān)優(yōu)秀軟件設(shè)計(jì)的一切知識(shí)，提升內(nèi)聚性，降低耦合度。換句話說：消除重復(fù)，保證表達(dá)力，盡可能的減少類和方法的數(shù)量。

3.不可重復(fù)。重復(fù)是良好設(shè)計(jì)系統(tǒng)的大敵。它代表著額外的工作、額外的風(fēng)險(xiǎn)和額外不必要的復(fù)雜度。重復(fù)有多種表現(xiàn)。雷同的代碼行是一種。另外的比如：

intsize();boolisEmpty();

這兩個(gè)方法可以分別實(shí)現(xiàn)，但可以在isEmpty中使用size消除重復(fù)。

boolisEmpty(){returnsize()==0;

}

不但是從代碼行的角度，也要從功能上消除重復(fù)。

第十三章： 并發(fā)編程

并發(fā)是一種解耦策略，它幫助我們把做什么(目的)和何時(shí)（時(shí)機(jī)）做分解開。在單線程應(yīng)用中，目的與時(shí)機(jī)緊密耦合，很多時(shí)候只要查看堆棧追蹤即可斷定應(yīng)用程序的狀態(tài)。而解耦目的與時(shí)機(jī)能明顯地改進(jìn)應(yīng)用程序的吞吐量和結(jié)構(gòu)。從結(jié)構(gòu)的角度看，應(yīng)用程序看起來更像是許多臺(tái)協(xié)同工作的計(jì)算機(jī),而不是一個(gè)大循環(huán)。單線程程序許多時(shí)間花在等待Web套接字I/O結(jié)束上面。

并發(fā)會(huì)在性能和編寫額外代碼上增加一些開銷。

正確的并發(fā)是復(fù)雜的，即使對于簡單的問題也是如此。

并發(fā)缺陷并非總能重現(xiàn)，所以常被看做偶發(fā)事件而忽略，而未被當(dāng)做真的缺陷看待。

并發(fā)常常需要對設(shè)計(jì)策略的根本性修改。

一些基礎(chǔ)定義：

在并發(fā)編程中用到的幾種執(zhí)行模型。

1）生產(chǎn)者-消費(fèi)者模型

一個(gè)或多個(gè)生產(chǎn)者線程創(chuàng)建某些工作，并置于緩存或者隊(duì)列中。一個(gè)或者多個(gè)消費(fèi)者線程從隊(duì)列中獲取并完成這些工作。生產(chǎn)者和消費(fèi)者之間的隊(duì)列是一種限定資源。

2）讀者-作者模型。

當(dāng)存在一個(gè)主要為讀者線程提供信息源，但只是偶爾被作者線程更新的共享資源，吞吐量就會(huì)是個(gè)問題。增加吞吐量，會(huì)導(dǎo)致線程饑餓和過時(shí)信息的積累。協(xié)調(diào)讀者線程不去讀取正在更新的信息，而作者線程傾向于長期鎖定讀者線程。

3）宴席哲學(xué)家。

許多企業(yè)級(jí)應(yīng)用中會(huì)存在進(jìn)程競爭資源的情形，如果沒有用心設(shè)計(jì)，這種競爭會(huì)遭遇死鎖，活鎖，吞吐量和效率低等問題。

PS：這里對并發(fā)的講解還不是那么的清晰，要掌握怎么正確使用并發(fā)，自己還是需要去專門看看這方面的書。

小結(jié)：書十三章之后的部分是一些java源碼的優(yōu)化過程的講解，我不太懂java，這里先略過。本書最有價(jià)值的地方在于讓我們程序員要有些整潔代碼的習(xí)慣。從細(xì)微的變量命令，到函數(shù)、類的設(shè)計(jì)、以及整個(gè)系統(tǒng)的構(gòu)造。不能忽略每一道工序。壞的代碼就像沼澤，會(huì)讓人越陷越深，很難改動(dòng)，所以我們從一開始就要寫整潔的代碼。而至于設(shè)計(jì)模式或并發(fā)編程，從其他的書籍學(xué)習(xí)更全面。這本書滿足不了我們的需求。

PS：書山有路活動(dòng)是讀書群的朋友共同選出來一起讀的一本書?！洞a整潔之道》是第一期。我是讀書人，這本書一共讀了七天。每天大概一個(gè)多小時(shí)。但是今天整理筆記，基本上全書又過了一遍。筆記內(nèi)容也是依據(jù)我自己的判斷。如果你想獲得全面的了解，還是要請看原書。我們第二期正在讀的書籍是《失控》，歡迎有興趣的朋友加入 qq群452450927。