代碼整潔的意義

最近讀了《代碼整潔之道》這本書，結合自己工作之后的項目經驗，對代碼整潔的重要性有了一些新的理解與感悟。首先我想先談談什么是整潔的代碼，從字面意思上理解，整潔的代碼，對于程序員來說非常的一目了然，簡單、整潔，結構清晰，邏輯清楚。那么整潔的代碼到底對一個項目的影響有多大？對于這個問題沒有明確的數(shù)據(jù)支撐我給出答案，我只知道糟糕的代碼對于一個項目的影響是與這個項目的規(guī)模呈正比的，我覺得大概可以算作是呈指數(shù)級的增長。

糟糕的代碼是如何影響一個項目的？想象一下一份只有10行的充斥了i、j、k等變量的代碼，讀完并不是一件難事，或許邏輯并不那么清晰，但是好歹還是能夠理解作者的意圖，但是如果變成1000行呢？或許這個數(shù)量增長到100行的時候就已經讓人想要放棄，隨意的命名讓人一頭霧水，錯綜復雜的邏輯混在一起。如果還要在這樣的代碼上繼續(xù)疊加邏輯，這幾乎已經是不可完成的任務了。

從我自己的經驗來說，我?guī)缀跤洸蛔〈a的具體實現(xiàn)是怎樣的，盡管這是自己所寫出來的代碼，在每一次進行一個新的功能的開發(fā)時，我都需要去熟悉一下舊代碼的實現(xiàn)邏輯，然后才能在此之上進行新功能的疊加。一份整潔的代碼可以讓閱讀它的程序員快速的了解其實現(xiàn)邏輯，而不需要去了解具體的實現(xiàn)細節(jié)。如果一份代碼需要程序員了解了所有的實現(xiàn)細節(jié)才能知道這份代碼的作用，這勢必意味著程序員需要花費大量的時間在閱讀一份與工作關系并不大的代碼。這樣的代碼越多，程序員花費的時間也就越多，這就是為什么我在文章開頭說糟糕的代碼對于一個項目的影響是與這個項目的規(guī)模呈指數(shù)級的增長。

所以糟糕的代碼意味著難以維護，也意味著代碼會慢慢的腐爛。所以在完成代碼后花一些時間去保持代碼的整潔反而是一種提升效率的手段。

怎樣的代碼才叫整潔的代碼呢？對于這個問題我的理解是這樣的，代碼其實是一種語言，傳遞的是邏輯，如果這份代碼可以像我們說話一樣快速的將邏輯傳遞給讀者，那么這樣一份代碼就是一份整潔的代碼。

如何保持代碼整潔

在明白了代碼整潔的意義之后，如何保持代碼整潔就是當前最緊迫的問題。私以為可以從幾個點來進行考慮：

意識

首先便是要有保持代碼整潔的意識，我很喜歡《代碼整潔之道》中反復提到的一條童子軍軍規(guī)：讓營地比你來時更干凈。我認為有保持代碼整潔的意識并不是說從寫代碼的時候就一直是整潔的，如果能夠這樣當然很好，但是這很難做到。在一開始編寫代碼的時候我們可以按照自己的思維順序，個人習慣，甚至是只是為了追求想要可以工作的代碼來寫出一些較為混亂的代碼，但是在結束當前的工作之前，在讓自己的大腦脫離開之前，一定要整理代碼，一定！

明天的你與今天的你總會有所不同，在再次進入工作之后，你或許會忘記很多的細節(jié)，而混亂的代碼只會讓思維更加的混亂。所以趁著你的思維還沒有與你代碼中巧妙的實現(xiàn)斷線之前，整理你的代碼，使代碼盡可能的保持整潔。這便是我理解的童子軍軍規(guī)，你可以把營地搞得一團糟，但在你離開之前，一定要整理的更加干凈。

代碼規(guī)范

從代碼規(guī)范入手是最基礎也是最容易實現(xiàn)的保持代碼整潔的方式。從幾個方面來體現(xiàn)代碼形式的整潔：足夠好的命名，簡單專注的函數(shù)，有意義的注釋以及規(guī)范的代碼格式。

一個好的命名可以幫助讀者快速的理解變量以及函數(shù)的意義，所要實現(xiàn)的事情是什么。很多時候程序員寧愿花費更多的時間在變量名后加一些注釋，也不愿意取一個簡單易懂的名字，這實際是一件本末倒置的做法。一個函數(shù)、變量、類或者接口應該只通過命名就可以把它所做的事情傳達給讀者。所以不要害怕花費時間在思考命名上。

函數(shù)應該做一件事。做好這件事。只做這一件事。這句話摘選自函數(shù)這一章節(jié)。這句話很重要，我總會在函數(shù)中看到比函數(shù)名描述的更多的事情，有的時候我不得不花時間去閱讀一些我不想了解的實現(xiàn)細節(jié)才能明白這個函數(shù)到底做了一件什么事。所以一個函數(shù)只做一件事，這是我認為很容易達到卻又很容易被忽略的非常重要的事情。同時，函數(shù)還應該盡可能的短小，一個函數(shù)就算寫的再清晰，如果一下子展示出100多行，那種龐大的行數(shù)也會讓讀者瞬間放棄。當然我相信，如果一個函數(shù)只專注于一件事，是不會產生過于龐大的代碼量的。所以我認為，一個好的代碼，應該像洋蔥一樣，可以一層一層的剝開，由粗略到細致。而不是像一個煮雞蛋，完全一整個，讓人無法一點一點的理解。

關于有意義的注釋，我想我在前邊兩段的描述已經傳達了一個信息，注釋或許并不那么必要。如果編程語言足夠有表現(xiàn)力，能夠傳遞給讀者所要表達的信息，注釋其實就失去了意義。只在真正需要的地方寫代碼才是注釋應該存在的意義。

好的代碼格式，例如縮進的形式，可以有力的將層級結構傳遞給讀者。我很討厭沒有縮進的代碼，因為我根本記不住哪個｝是哪個｛的結束。有的時候，代碼格式也是一種有力的信息。

質量保證

所謂質量保證，便是指可運行的自動化測試以及代碼中的錯誤處理。測試與錯誤處理代碼的整潔常常被人們所忽略，或者不止是整潔，連測試和錯誤處理本身都常常是會被忽略的事情。事實是，測試很好的保證了我們的代碼質量，給了我們對代碼修改的信心，這是另一個話題了，這里不做贅述。

錯誤處理是指在代碼中程序員常常為了覆蓋更多的情況、給出更多的錯誤信息而在代碼的前后加try catch。設想一個極端的情況，每一行代碼都被一個try catch包圍，整個結構就已經一團糟了，再清晰的結構這個時候也已經被拆解的支離破碎。錯誤處理可以匯總到某一處集中處理，不要讓隨處添加異常處理破壞代碼的邏輯。

除了異常處理，測試的整潔同樣重要。測試與編程語言一樣，也是一種向讀者傳遞實現(xiàn)內容的一種方式，隨著代碼的衍進，測試也同樣在進行著改變。所以測試代碼的整潔和生產代碼的整潔同樣重要。一團糟糕的測試代碼或許可以保證代碼的質量，但當代碼產生變動時，對于測試代碼的改動或許比對生產代碼的改動所花時間還要長，我們需要花費更大的代價去維護測試代碼，這是一件得不償失的事情。為了不讓這類事情發(fā)生，需要對測試代碼的整潔與生產代碼的整潔給予同樣的重視。同方法的職責單一原則一致，斷言的內容也需要職責單一。每個斷言應該只判斷一件事。如此便可以更好的幫助我們快速精準的定位問題。

分層與結構

分層是指代碼從整體上，由上至下的一種層級結構應該是清晰的，并且一層一層應該很好的區(qū)分開。與分層平級的便是結構，結構是指從業(yè)務邏輯上，各個模塊應該很好的區(qū)別開。分層與結構的構建清晰與否極大的影響了整個項目的整潔程度。

從大的方面來說，系統(tǒng)的使用與構造需要明確的區(qū)分開，才不會將整個結構混雜在一起。與此同時，決定了系統(tǒng)的數(shù)據(jù)流走向便是決定了整個系統(tǒng)的層級劃分，不同的層級也需要明確的區(qū)分開來。從小一些的方面來看，當創(chuàng)建一個類時，類的職責也需要明確，一個類應該只有一個職責。以上這些無論大的或是小的方面，之所以都需要明確劃分職責，都是為了更好的實現(xiàn)內聚。

內聚代表著職責的專一，這是整潔的一個很重要準則。當我們實現(xiàn)內聚的時候，便會很自然的存在一個分類的界限。舉個可能并不是很恰當?shù)睦?，學校里有很多學院，每個學院有很多專業(yè)，每個專業(yè)有很多班，每個班里有很多學生，這樣層層遞進，每一層也分的很清楚，每一層的結構也很清晰。如果換一種說法呢，還是學校，學校里有很多學生1、2、3，有專業(yè)1、2、3， 有學院1、2、3。這樣的話，學校還是那個學校，分層完全沒有體現(xiàn)，有的更糟糕的，還會把不同層級、不同結構混合在一起。

所以好的結構和層級的劃分可以認為是一種邏輯上的整潔，是相對更加抽象的代碼整潔，要求程序員自上而下地來進行代碼的整潔。

如何整理代碼

說完如何保持整潔的代碼，如果遇到了一團混亂的代碼，我們要如何將它整理的井井有條呢？首先我們要能夠明確的找到混亂地方，當然我們不太可能一下子就找到所有，不用太著急，我們就要像剝洋蔥一樣一點一點的拆解代碼，小幅的進行改動。每次改動，都有前邊提到的測試來保證我們并沒有破壞現(xiàn)有的功能。

當我們要整理一大坨代碼的時候，我自己的經驗是，如果不知道如何改動的時候，可以先從最基本的入手，看懂一段代碼并且明確這是做了一件事之后，提取出來，取一個具有描述意義的名字。當將代碼這樣拆解成一個一個的方法之后，結構就清晰了很多。之后我們就會聞到很多的code smell，發(fā)現(xiàn)很多的重復。關于如何發(fā)現(xiàn)和解決code smell，可以參考《重構》這本書，這本書列舉了很多的code smell，并且給出了很好的解決方案。

小幅的、迭代式的進行代碼的改動可以幫助我們一點一點的梳理結構，朝著更清晰的方向行走。同時千萬不要忘記每一次的改動都需要運行測試來保證我們做的是對的事情。