有多少程序員，就有多少定義。所以我只詢(xún)問(wèn)了一些非常知名且經(jīng)驗(yàn)豐富的程序員。

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

Bjarne用了“優(yōu)雅”一詞。說(shuō)得好!我MacBook上的詞典提供了如下定義：外表或舉止上令人愉悅的優(yōu)美和雅觀;令人愉悅的精致和簡(jiǎn)單。注意對(duì)“愉悅”一詞的強(qiáng)調(diào)。Bjarne顯然認(rèn)為整潔的代碼讀起來(lái)令人愉悅。讀這種代碼，就像見(jiàn)到手工精美的音樂(lè)盒或者設(shè)計(jì)精良的汽車(chē)一般，讓你會(huì)心一笑。

Bjarne也提到效率——而且兩次提及。這話(huà)出自C++發(fā)明者之口，或許并不出奇;不過(guò)我認(rèn)為并非是在單純追求速度。被浪費(fèi)掉的運(yùn)算周期并不雅觀，并不令人愉悅。留意Bjarne怎么描述那種不雅觀的結(jié)果。他用了“引誘”這個(gè)詞。誠(chéng)哉斯言。糟糕的代碼引發(fā)混亂!別人修改糟糕的代碼時(shí)，往往會(huì)越改越爛。

務(wù)實(shí)的Dave Thomas和Andy Hunt從另一角度闡述了這種情況。他們提到破窗理論[5]。窗戶(hù)破損了的建筑讓人覺(jué)得似乎無(wú)人照管。于是別人也再不關(guān)心。他們放任窗戶(hù)繼續(xù)破損。最終自己也參加破壞活動(dòng)，在外墻上涂鴉，任垃圾堆積。一扇破損的窗戶(hù)開(kāi)辟了大廈走向傾頹的道路。

Bjarne也提到完善錯(cuò)誤處理代碼。往深處說(shuō)就是在細(xì)節(jié)上花心思。敷衍了事的錯(cuò)誤處理代碼只是程序員忽視細(xì)節(jié)的一種表現(xiàn)。此外還有內(nèi)存泄漏，還有競(jìng)態(tài)條件代碼。還有前后不一致的命名方式。結(jié)果就是凸現(xiàn)出整潔代碼對(duì)細(xì)節(jié)的重視。

Bjarne以“整潔的代碼只做好一件事”結(jié)束論斷。毋庸置疑，軟件設(shè)計(jì)的許多原則最終都會(huì)歸結(jié)為這句警語(yǔ)。有那么多人發(fā)表過(guò)類(lèi)似的言論。糟糕的代碼想做太多事，它意圖混亂、目的含混。整潔的代碼力求集中。每個(gè)函數(shù)、每個(gè)類(lèi)和每個(gè)模塊都全神貫注于一事，完全不受四周細(xì)節(jié)的干擾和污染。

整潔的代碼簡(jiǎn)單直接。整潔的代碼如同優(yōu)美的散文。整潔的代碼從不隱藏設(shè)計(jì)者的意圖，充滿(mǎn)了干凈利落的抽象和直截了當(dāng)?shù)目刂普Z(yǔ)句。

Grady的觀點(diǎn)與Bjarne的觀點(diǎn)有類(lèi)似之處，但他從可讀性的角度來(lái)定義。我特別喜歡“整潔的代碼如同優(yōu)美的散文”這種看法。想想你讀過(guò)的某本好書(shū)。回憶一下，那些文字是如何在腦中形成影像!就像是看了場(chǎng)電影，對(duì)吧?還不止!你還看到那些人物，聽(tīng)到那些聲音，體驗(yàn)到那些喜怒哀樂(lè)。

閱讀整潔的代碼和閱讀Lord of the Rings(中譯版《指環(huán)王》)自然不同。不過(guò)，仍有可類(lèi)比之處。如同一本好的小說(shuō)般，整潔的代碼應(yīng)當(dāng)明確地展現(xiàn)出要解決問(wèn)題的張力。它應(yīng)當(dāng)將這種張力推至高潮，以某種顯而易見(jiàn)的方案解決問(wèn)題和張力，使讀者發(fā)出“啊哈!本當(dāng)如此!”的感嘆。

竊以為Grady所謂“干凈利落的抽象”(crisp abstraction)，乃是絕妙的矛盾修辭法。畢竟crisp幾乎就是“具體”(concrete)的同義詞。我MacBook上的詞典這樣定義crisp一詞：果斷決絕，就事論事，沒(méi)有猶豫或不必要的細(xì)節(jié)。盡管有兩種不同的定義，該詞還是承載了有力的信息。代碼應(yīng)當(dāng)講述事實(shí)，不引人猜測(cè)。它只該包含必需之物。讀者應(yīng)當(dāng)感受到我們的果斷決絕。

整潔的代碼應(yīng)可由作者之外的開(kāi)發(fā)者閱讀和增補(bǔ)。它應(yīng)當(dāng)有單元測(cè)試和驗(yàn)收測(cè)試。它使用有意義的命名。它只提供一種而非多種做一件事的途徑。它只有盡量少的依賴(lài)關(guān)系，而且要明確地定義和提供清晰、盡量少的API。代碼應(yīng)通過(guò)其字面表達(dá)含義，因?yàn)椴煌恼Z(yǔ)言導(dǎo)致并非所有必需信息均可通過(guò)代碼自身清晰表達(dá)。

Dave老大在可讀性上和Grady持相同觀點(diǎn)，但有一個(gè)重要的不同之處。Dave斷言，整潔的代碼便于其他人加以增補(bǔ)。這看似顯而易見(jiàn)，但亦不可過(guò)分強(qiáng)調(diào)。畢竟易讀的代碼和易修改的代碼之間還是有區(qū)別的。

Dave將整潔系于測(cè)試之上!要在十年之前，這會(huì)讓人大跌眼鏡。但測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(Test Driven Development)已在行業(yè)中造成了深遠(yuǎn)影響，成為基礎(chǔ)規(guī)程之一。Dave說(shuō)得對(duì)。沒(méi)有測(cè)試的代碼不干凈。不管它有多優(yōu)雅，不管有多可讀、多易理解，微乎測(cè)試，其不潔亦可知也。

Dave兩次提及“盡量少”。顯然，他推崇小塊的代碼。實(shí)際上，從有軟件起人們就在反復(fù)強(qiáng)調(diào)這一點(diǎn)。越小越好。

Dave也提到，代碼應(yīng)在字面上表達(dá)其含義。這一觀點(diǎn)源自Knuth的“字面編程”(literate programming)[6]。結(jié)論就是應(yīng)當(dāng)用人類(lèi)可讀的方式來(lái)寫(xiě)代碼。

我可以列出我留意到的整潔代碼的所有特點(diǎn)，但其中有一條是根本性的。整潔的代碼總是看起來(lái)像是某位特別在意它的人寫(xiě)的。幾乎沒(méi)有改進(jìn)的余地。代碼作者什么都想到了，如果你企圖改進(jìn)它，總會(huì)回到原點(diǎn)，贊嘆某人留給你的代碼——全心投入的某人留下的代碼。

一言以蔽之：在意。這就是本書(shū)的題旨所在。或許該加個(gè)副標(biāo)題，如何在意代碼。

Michael一針見(jiàn)血。整潔代碼就是作者著力照料的代碼。有人曾花時(shí)間讓它保持簡(jiǎn)單有序。他們適當(dāng)?shù)仃P(guān)注到了細(xì)節(jié)。他們?cè)谝膺^(guò)。

Ron初入行就在戰(zhàn)略空軍司令部(Strategic Air Command)編寫(xiě)Fortran程序，此后幾乎在每種機(jī)器上編寫(xiě)過(guò)每種語(yǔ)言的代碼。他的言論值得咀嚼。

近年來(lái)，我開(kāi)始研究貝克的簡(jiǎn)單代碼規(guī)則，差不多也都琢磨透了。簡(jiǎn)單代碼，依其重要順序：

• 能通過(guò)所有測(cè)試;
• 沒(méi)有重復(fù)代碼;
• 體現(xiàn)系統(tǒng)中的全部設(shè)計(jì)理念;
• 包括盡量少的實(shí)體，比如類(lèi)、方法、函數(shù)等。

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

在我看來(lái)，有意義的命名是體現(xiàn)表達(dá)力的一種方式，我往往會(huì)修改好幾次才會(huì)定下名字來(lái)。借助Eclipse這樣的現(xiàn)代編碼工具，重命名代價(jià)極低，所以我無(wú)所顧忌。然而，表達(dá)力還不只體現(xiàn)在命名上。我也會(huì)檢查對(duì)象或方法是否想做的事太多。如果對(duì)象功能太多，最好是切分為兩個(gè)或多個(gè)對(duì)象。如果方法功能太多，我總是使用抽取手段(Extract Method)重構(gòu)之，從而得到一個(gè)能較為清晰地說(shuō)明自身功能的方法，以及另外數(shù)個(gè)說(shuō)明如何實(shí)現(xiàn)這些功能的方法。

消除重復(fù)和提高表達(dá)力讓我在整潔代碼方面獲益良多，只要銘記這兩點(diǎn)，改進(jìn)臟代碼時(shí)就會(huì)大有不同。不過(guò)，我時(shí)常關(guān)注的另一規(guī)則就不太好解釋了。

這么多年下來(lái)，我發(fā)現(xiàn)所有程序都由極為相似的元素構(gòu)成。例如“在集合中查找某物”。不管是雇員記錄數(shù)據(jù)庫(kù)還是名-值對(duì)哈希表，或者某類(lèi)條目的數(shù)組，我們都會(huì)發(fā)現(xiàn)自己想要從集合中找到某一特定條目。一旦出現(xiàn)這種情況，我通常會(huì)把實(shí)現(xiàn)手段封裝到更抽象的方法或類(lèi)中。這樣做好處多多。

可以先用某種簡(jiǎn)單的手段，比如哈希表來(lái)實(shí)現(xiàn)這一功能，由于對(duì)搜索功能的引用指向了我那個(gè)小小的抽象，就能隨需應(yīng)變，修改實(shí)現(xiàn)手段。這樣就既能快速前進(jìn)，又能為未來(lái)的修改預(yù)留余地。

另外，該集合抽象常常提醒我留意“真正”在發(fā)生的事，避免隨意實(shí)現(xiàn)集合行為，因?yàn)槲艺嬲枰牟贿^(guò)是某種簡(jiǎn)單的查找手段。

減少重復(fù)代碼，提高表達(dá)力，提早構(gòu)建簡(jiǎn)單抽象。這就是我寫(xiě)整潔代碼的方法。

Ron以寥寥數(shù)段文字概括了本書(shū)的全部?jī)?nèi)容。不要重復(fù)代碼，只做一件事，表達(dá)力，小規(guī)模抽象。該有的都有了。

如果每個(gè)例程都讓你感到深合己意，那就是整潔代碼。如果代碼讓編程語(yǔ)言看起來(lái)像是專(zhuān)為解決那個(gè)問(wèn)題而存在，就可以稱(chēng)之為漂亮的代碼。

這種說(shuō)法很Ward。它教你聽(tīng)了之后就點(diǎn)頭，然后繼續(xù)聽(tīng)下去。如此在理，如此淺顯，絕不故作高深。你大概以為此言深合己意吧。再走近點(diǎn)看看。

“……深合己意”。你最近一次看到深合己意的模塊是什么時(shí)候?模塊多半都繁復(fù)難解吧?難道沒(méi)有觸犯規(guī)則嗎?你不是也曾掙扎著想抓住些從整個(gè)系統(tǒng)中散落而出的線(xiàn)索，編織進(jìn)你在讀的那個(gè)模塊嗎?你最近一次讀到某段代碼、并且如同對(duì)Ward的說(shuō)法點(diǎn)頭一般對(duì)這段代碼點(diǎn)頭，是什么時(shí)候的事了?

Ward期望你不會(huì)為整潔代碼所震驚。你無(wú)需花太多力氣。那代碼就是深合你意。它明確、簡(jiǎn)單、有力。每個(gè)模塊都為下一個(gè)模塊做好準(zhǔn)備。每個(gè)模塊都告訴你下一個(gè)模塊會(huì)是怎樣的。整潔的程序好到你根本不會(huì)注意到它。設(shè)計(jì)者把它做得像一切其他設(shè)計(jì)般簡(jiǎn)單。

那Ward有關(guān)“美”的說(shuō)法又如何呢?我們都曾面臨語(yǔ)言不是為要解決的問(wèn)題所設(shè)計(jì)的困境。但Ward的說(shuō)法又把球踢回我們這邊。他說(shuō)，漂亮的代碼讓編程語(yǔ)言像是專(zhuān)為解決那個(gè)問(wèn)題而存在!所以，讓語(yǔ)言變得簡(jiǎn)單的責(zé)任就在我們身上了!當(dāng)心，語(yǔ)言是冥頑不化的!是程序員讓語(yǔ)言顯得簡(jiǎn)單。

想知道這篇文章摘自哪里嗎?來(lái)自《代碼整潔之道》，書(shū)中還有很多非常適合程序員的經(jīng)典佳句，小編在這里在羅列一些給你們，希望對(duì)程序員們有所幫助。我相信下面的摘錄一定會(huì)對(duì)你有所幫助。

1、如果程序員只是為滿(mǎn)足編譯器或解釋器的需要而寫(xiě)代碼，就會(huì)制造麻煩。例如，因?yàn)橥蛔饔梅秶鷥?nèi)兩樣不同的東西不能重名，你可能會(huì)隨手改掉其中一個(gè)的名稱(chēng)。有時(shí)干脆以錯(cuò)誤的拼寫(xiě)充數(shù)，結(jié)果就是出現(xiàn)在更正拼寫(xiě)錯(cuò)誤后導(dǎo)致編譯器出錯(cuò)的情況。

2、編碼已經(jīng)太多，無(wú)謂再自找麻煩。把類(lèi)型或作用域編進(jìn)名稱(chēng)里面，徒然增加了解碼的負(fù)擔(dān)。沒(méi)理由要求每位新人都在弄清要應(yīng)付的代碼之外(那算是正常的)，還要再搞懂另一種編碼“語(yǔ)言”。這對(duì)于解決問(wèn)題而言，純屬多余的負(fù)擔(dān)。帶編碼的名稱(chēng)通常也不便發(fā)音，容易打錯(cuò)。

3、Java程序員不需要類(lèi)型編碼。對(duì)象是強(qiáng)類(lèi)型的，代碼編輯環(huán)境已經(jīng)先進(jìn)到在編譯開(kāi)始前就偵測(cè)到類(lèi)型錯(cuò)誤的程度!所以，如今HN和其他類(lèi)型編碼形式都純屬多余。它們?cè)黾恿诵薷淖兞俊⒑瘮?shù)或類(lèi)的名稱(chēng)或類(lèi)型的難度。它們?cè)黾恿碎喿x代碼的難度。它們制造了讓編碼系統(tǒng)誤導(dǎo)讀者的可能性。

4、程序員通常都是聰明人。聰明人有時(shí)會(huì)借腦筋急轉(zhuǎn)彎炫耀其聰明。總而言之，假使你記得r代表不包含主機(jī)名和圖式(scheme)的小寫(xiě)字母版url的話(huà)，那你真是太聰明了。

聰明程序員和專(zhuān)業(yè)程序員之間的區(qū)別在于，專(zhuān)業(yè)程序員了解，明確是王道。專(zhuān)業(yè)程序員善用其能，編寫(xiě)其他人能理解的代碼。

5、記住，只有程序員才會(huì)讀你的代碼。所以，盡管用那些計(jì)算機(jī)科學(xué)(Computer Science，CS)術(shù)語(yǔ)、算法名、模式名、數(shù)學(xué)術(shù)語(yǔ)吧。依據(jù)問(wèn)題所涉領(lǐng)域來(lái)命名可不算是聰明的做法，因?yàn)椴辉撟寘f(xié)作者老是跑去問(wèn)客戶(hù)每個(gè)名稱(chēng)的含義，其實(shí)他們?cè)缭撏ㄟ^(guò)另一名稱(chēng)了解這個(gè)概念了。

對(duì)于熟悉訪問(wèn)者(VISITOR)模式的程序來(lái)說(shuō)，名稱(chēng)AccountVisitor富有意義。哪個(gè)程序員會(huì)不知道JobQueue的意思呢?程序員要做太多技術(shù)性工作。給這些事取個(gè)技術(shù)性的名稱(chēng)，通常是最靠譜的做法。

5、寫(xiě)注釋的常見(jiàn)動(dòng)機(jī)之一是糟糕的代碼的存在。我們編寫(xiě)一個(gè)模塊，發(fā)現(xiàn)它令人困擾、亂七八糟。我們知道，它爛透了。我們告訴自己：“喔，最好寫(xiě)點(diǎn)注釋!”不!最好是把代碼弄干凈!

帶有少量注釋的整潔而有表達(dá)力的代碼，要比帶有大量注釋的零碎而復(fù)雜的代碼像樣得多。與其花時(shí)間編寫(xiě)解釋你搞出的糟糕的代碼的注釋?zhuān)蝗缁〞r(shí)間清潔那堆糟糕的代碼。

6、測(cè)試代碼和生產(chǎn)代碼一樣重要。它可不是二等公民。它需要被思考、被設(shè)計(jì)和被照料。它該像生產(chǎn)代碼一般保持整潔。如果測(cè)試不能保持整潔，你就會(huì)失去它們。沒(méi)有了測(cè)試，你就會(huì)失去保證生產(chǎn)代碼可擴(kuò)展的一切要素。你沒(méi)看錯(cuò)。正是單元測(cè)試讓你的代碼可擴(kuò)展、可維護(hù)、可復(fù)用。原因很簡(jiǎn)單。有了測(cè)試，你就不擔(dān)心對(duì)代碼的修改!沒(méi)有測(cè)試，每次修改都可能帶來(lái)缺陷。無(wú)論架構(gòu)多有擴(kuò)展性，無(wú)論設(shè)計(jì)劃分得有多好，沒(méi)有了測(cè)試，你就很難做改動(dòng)，因?yàn)槟銚?dān)憂(yōu)改動(dòng)會(huì)引入不可預(yù)知的缺陷。

7、讓軟件能工作和讓軟件保持整潔，是兩種截然不同的工作。我們中的大多數(shù)人腦力有限，只能更多地把精力放在讓代碼能工作上，而不是放在保持代碼有組織和整潔上。這全然正確。分而治之，其在編程行為中的重要程度等同于在程序中的重要程度。

問(wèn)題是太多人在程序能工作時(shí)就以為萬(wàn)事大吉了。我們沒(méi)能把思維轉(zhuǎn)向有關(guān)代碼組織和整潔的部分。我們直接轉(zhuǎn)向下一個(gè)問(wèn)題，而不是回頭將臃腫的類(lèi)切分為只有單一權(quán)責(zé)的去耦式單元。

與此同時(shí)，許多開(kāi)發(fā)者害怕數(shù)量巨大的短小單一目的類(lèi)會(huì)導(dǎo)致難以一目了然抓住全局。他們認(rèn)為，要搞清楚一件較大工作如何完成，就得在類(lèi)與類(lèi)之間找來(lái)找去。

然而，有大量短小類(lèi)的系統(tǒng)并不比有少量龐大類(lèi)的系統(tǒng)擁有更多移動(dòng)部件，其數(shù)量大致相等。問(wèn)題是：你是想把工具歸置到有許多抽屜、每個(gè)抽屜中裝有定義和標(biāo)記良好的組件的工具箱中呢，還是想要少數(shù)幾個(gè)能隨便把所有東西扔進(jìn)去的抽屜?

每個(gè)達(dá)到一定規(guī)模的系統(tǒng)都會(huì)包括大量邏輯和復(fù)雜性。管理這種復(fù)雜性的首要目標(biāo)就是加以組織，以便開(kāi)發(fā)者知道到哪兒能找到東西，并且在某個(gè)特定時(shí)間只需要理解直接有關(guān)的復(fù)雜性。反之，擁有巨大、多目的類(lèi)的系統(tǒng)，總是讓我們?cè)谀壳安⒉恍枰私獾囊淮蠖褨|西中艱難跋涉。

再?gòu)?qiáng)調(diào)一下：系統(tǒng)應(yīng)該由許多短小的類(lèi)而不是少量巨大的類(lèi)組成。每個(gè)小類(lèi)封裝一個(gè)權(quán)責(zé)，只有一個(gè)修改的原因，并與少數(shù)其他類(lèi)一起協(xié)同達(dá)成期望的系統(tǒng)行為。

8、我們中的大多數(shù)人都經(jīng)歷過(guò)費(fèi)解代碼的糾纏。我們中的許多人自己就編寫(xiě)過(guò)費(fèi)解的代碼。寫(xiě)出自己能理解的代碼很容易，因?yàn)樵趯?xiě)這些代碼時(shí)，我們正深入于要解決的問(wèn)題中。代碼的其他維護(hù)者不會(huì)那么深入，也就不易理解代碼。

軟件項(xiàng)目的主要成本在于長(zhǎng)期維護(hù)。為了在修改時(shí)盡量降低出現(xiàn)缺陷的可能性，很有必要理解系統(tǒng)是做什么的。當(dāng)系統(tǒng)變得越來(lái)越復(fù)雜，開(kāi)發(fā)者就需要越來(lái)越多的時(shí)間來(lái)理解它，而且也極有可能誤解。所以，代碼應(yīng)當(dāng)清晰地表達(dá)其作者的意圖。作者把代碼寫(xiě)得越清晰，其他人花在理解代碼上的時(shí)間也就越少，從而減少缺陷，縮減維護(hù)成本。

可以通過(guò)選用好名稱(chēng)來(lái)表達(dá)。我們想要聽(tīng)到好類(lèi)名和好函數(shù)名，而且在查看其權(quán)責(zé)時(shí)不會(huì)大吃一驚。

也可以通過(guò)保持函數(shù)和類(lèi)尺寸短小來(lái)表達(dá)。短小的類(lèi)和函數(shù)通常易于命名，易于編寫(xiě)，易于理解。

還可以通過(guò)采用標(biāo)準(zhǔn)命名法來(lái)表達(dá)。例如，設(shè)計(jì)模式很大程度上就關(guān)乎溝通和表達(dá)。通過(guò)在實(shí)現(xiàn)這些模式的類(lèi)的名稱(chēng)中采用標(biāo)準(zhǔn)模式名，例如COMMAND或VISITOR，就能充分地向其他開(kāi)發(fā)者描述你的設(shè)計(jì)。

9、編寫(xiě)永遠(yuǎn)運(yùn)行的系統(tǒng)，與編寫(xiě)運(yùn)行一段時(shí)間后平靜地關(guān)閉的系統(tǒng)是兩碼事。

平靜關(guān)閉很難做到。常見(jiàn)問(wèn)題與死鎖有關(guān)，線(xiàn)程一直等待永遠(yuǎn)不會(huì)到來(lái)的信號(hào)。

例如，想象一個(gè)系統(tǒng)中有個(gè)父線(xiàn)程分裂出數(shù)個(gè)子線(xiàn)程，父線(xiàn)程等待所有子線(xiàn)程結(jié)束，然后釋放資源并關(guān)閉。如果其中一個(gè)子線(xiàn)程發(fā)生死鎖會(huì)怎樣?父線(xiàn)程將一直等待下去，而系統(tǒng)就永遠(yuǎn)不能關(guān)閉。

或者，考慮一個(gè)被指示關(guān)閉的類(lèi)似系統(tǒng)。父線(xiàn)程告知全體子線(xiàn)程放棄任務(wù)并結(jié)束。如果其中兩個(gè)子線(xiàn)程正以生產(chǎn)者/消費(fèi)者模型操作會(huì)怎樣呢?假設(shè)生產(chǎn)者線(xiàn)程從父線(xiàn)程處接收到信號(hào)，并迅速關(guān)閉。消費(fèi)者線(xiàn)程可能還在等待生產(chǎn)者線(xiàn)程發(fā)來(lái)消息，于是就被鎖定在無(wú)法接收到關(guān)閉信號(hào)的狀態(tài)中。它會(huì)死等生產(chǎn)者線(xiàn)程，永不結(jié)束，從而導(dǎo)致父線(xiàn)程也無(wú)法結(jié)束。

這類(lèi)情形并非那么不常見(jiàn)。如果你要編寫(xiě)涉及平靜關(guān)閉的并發(fā)代碼，請(qǐng)多預(yù)留一些時(shí)間搞對(duì)關(guān)閉過(guò)程。

建議：盡早考慮關(guān)閉問(wèn)題，盡早令其工作正常。這會(huì)花費(fèi)比你預(yù)期更多的時(shí)間。檢視既有算法，因?yàn)檫@可能會(huì)比想象中難得多。

10、線(xiàn)程代碼導(dǎo)致“不可能失敗的”失敗。多數(shù)開(kāi)發(fā)者缺乏有關(guān)線(xiàn)程如何與其他代碼(可能由其他作者編寫(xiě))互動(dòng)的直覺(jué)。線(xiàn)程代碼中的缺陷可能在一千或一百萬(wàn)次執(zhí)行中才會(huì)顯現(xiàn)一次。重復(fù)執(zhí)行想要復(fù)現(xiàn)問(wèn)題令人沮喪。所以開(kāi)發(fā)者常常會(huì)將失敗歸咎于宇宙射線(xiàn)、硬件錯(cuò)誤或其他“偶發(fā)事件”。最好假設(shè)這種偶發(fā)事件根本不存在。“偶發(fā)事件”被忽略得越久，代碼就越有可能搭建于不完善的基礎(chǔ)之上。

建議：不要將系統(tǒng)錯(cuò)誤歸咎于偶發(fā)事件。

如果你很喜歡小編摘選的這些內(nèi)容，還有些意猶未盡，你真的要準(zhǔn)備一本《代碼整潔之道》放在你的床頭，每天讀一讀，真的很受用。