雲栖号： https://yqh.aliyun.com 第一手的上雲資訊，不同行業精選的上雲企業案例庫，基于衆多成功案例萃取而成的最佳實踐，助力您上雲決策！
多年以來，在我教授的一門專業軟體工程師課程中用到了這本書。這本書我反複讀了十幾遍，每次都有新的收獲。話雖這麼說，但我發現書中有一半的内容都是錯誤的。我希望涵蓋從這本書、其他人、我的導師以及我自身的經曆中學到的經驗教訓，但我想從怎樣的代碼才是“整潔的代碼”說起；更準确地說，從怎樣的代碼不是“整潔的代碼”說起。
怎樣的代碼不整潔？
判斷代碼是否整潔的問題在于，這個目标完全是主觀的。如果你讓七位經驗豐富、功成名就的軟體工程師來定義整潔的代碼，那麼最終他們會給你七個迥異的定義。《Clean Code》一書的第七章已經證明了這個觀點。
另一方面，髒亂的代碼是非常客觀的。我可以編寫一段代碼，每位看到的工程師都同意這段代碼一團糟。
這意味着從髒亂的代碼到整潔的代碼有一個範圍，一端是客觀的，而另一端不是客觀的。下圖簡要說明了這一點。
在上圖中，一組工程師對幾個代碼樣本進行了評級。然後，将每個樣本按平均分排序。我們用誤差範圍表示某個等級的一緻度。如你所見，随着平均分的提高，評分的偏差也随之增大。
如果整潔的代碼是主觀的，那麼我們對于編寫代碼還有其他更加現實的目标嗎？降低代碼的髒亂度算不算一個目标？
定義髒亂
在明确定義代碼的髒亂之前，我們首先應該在影響代碼實際用途的因素優先級上達成一緻。我認為下面是其中一些重要的方面，沒有特定的先後順序。
高效：使用最少的資源（時間、記憶體等）來完成工作。
健壯：即便輸入有錯，也可以合理地處理。
傳遞：最小化傳遞時間。
正确：接收到良好的輸入時，傳回正确的輸出。
可擴充：添加新功能的難度很小。
可運作：最小化為代碼達到可運作狀态付出的工作。
靈活：改變代碼工作方式的難度很小。
可靠：我們很自信修改代碼不會出錯。
可讀：将另一位工程師了解代碼所需的時間降到最低。
這些都是人們在定義整潔的代碼時常常讨論的方面。你可以考慮一下在你心目中這些因素的優先順序。
雖然我說了這些方面沒有特定的優先順序，但其實則不然，上述順序與我心目中的優先順序正好相反。如果代碼具備可讀性，那麼所有工程師都可以了解代碼，這意味着他們可以輕松地實作其他方面。實際上，“閱讀舊代碼所花費的時間比例超過了10:1。每次寫新代碼的時候，我們都需要閱讀舊代碼。”如果代碼易于了解，則易于測試、修改和運作。是以，也易于擴充、修複、部署和改進。最後，如果傳遞到實際客戶的手中，則可以提高某些地方的健壯性和效率。
是以，我們的優先級可分為四層：
可讀。
可靠，靈活，可運作。
可擴充，正确，傳遞。
健壯，高效。
每一層都服務于下一層的實作。鑒于此，我們可以将髒亂的代碼定義為難以閱讀的代碼。
代碼的可讀性因人而異，因為每位開發人員的經驗水準各不相同，熟悉的軟體範式、程式設計語言、代碼庫、編譯器、作業系統等也不盡相同。而且最重要的是，讀代碼的人與作者之間從來都沒有完全相同的文化和詞彙。我們力求做到為大多數人提供最友善閱讀的代碼。
Suess博士的著作《The Cat in The Hat》（戴帽子的貓）的讀者數量超過了James Joyce的著作《Ulysses》（尤利西斯），也是因為這個原因。因為前者的閱聽人範圍更廣，讀起來更簡單。當然，我們可以争論哪本傑作更偉大，但是我們不會争論哪本書的閱讀難度更高。
我認為，在審閱代碼這件事上，傻瓜比天才更出色（這也是為什麼我認為我很擅長代碼審閱）。當一個傻瓜遇到一段聰明、預料之外、有副作用、不容易懂的代碼時，他們會為之苦惱，是以他們會毫不猶豫地指出這些問題。而當一個天才閱讀這段代碼時，他們的大腦會飛快地運轉，并在短時間内消化所有的代碼。盡管傻瓜遇到問題時不一定知道該如何修複，但代碼審閱過程中，确定問題确實存在才是關鍵的第一步。
是以，傻瓜和天才都有各自的弊端。幸運的是，無論你認為自己更傾向哪一種，都可以堅持做好一件事情：不斷提高自身，以及編寫代碼的能力。
工匠精神
沒人能在學習建築的第一天就建造出泰姬陵。無論你身處何處，眼前都有一段很長的路需要走下去。嚴格來講，每個人距離完美都遙不可及。
作為一名作者，是撰寫騙取點選量的文章，還是撰寫有意義的文章，二者之間有本質的差別。大千世界裡這兩種類型的作者都不罕見，可能騙取點選量的文章确實可以獲得更多的點選。但是你想成為哪一種呢？
作為一名工匠，你不必擔心人們的贊美或衡量最終結果的标準，你應該為自己的全力以赴而感到自豪。此外，你還需要不斷提高自己的技術力。
工匠的作品會受到同行業中其他人的稱贊，而那些不懂行的人往往會忽視。工匠關心的是作品的品質，對于編寫代碼來說，就是代碼的可讀性。你的代碼不一定完美，但你應該努力将髒亂度降到最低。除此之外，你應該原諒自己過去的一無所知。最重要的是，你應該向所有人學習，甚至是那些不了解你的才能的傻瓜。
速度很重要
你的産品和項目經理會很關心你的速度。關心品質是你的本職工作。一位出色的經理明白，無論從時間還是金錢上來講，工程都是編寫代碼的過程中最昂貴的部分，是以優化這部分資源在金錢的角度來看也很有意義。高品質、可讀性強的代碼可以最大程度地減少繁瑣的代碼債務并提高速度。然而，更常見的是幼稚的經理隻看重目前沖刺或季度沖刺的收益。
想象一下，你找了一家公司處理稅務。公司就像你的經理一樣，希望從業人員盡快完成盡可能多的稅務評估，以確定他們可以獲得最大利潤。但是，如果稅務專業人員的工作品質不佳，那麼就讓會讓公司面臨訴訟、聲譽受損和長期失敗的風險。保證工作品質，并防止這種風險是稅務從業人員的責任。每個職業都是如此。律師與服務的公司，醫生與醫院，機械師與商店。如果你事先知道某個員工不願意堅守工作品質，那麼你還願意雇傭他們嗎？軟體工程師也不例外。
工匠應該在不犧牲工作品質的情況下盡快傳遞産品，他們對此持有堅定的立場。是以，我們的問題是，如何在編寫高品質（具有可讀性）的代碼和經理能夠忍受的傳遞速度之間取得平衡？對我而言，找到最佳平衡的方法是：首先編寫代碼來解決和了解問題，再經過可讀性的優化後，最後傳遞代碼。通常，我知道我的代碼仍有改進的空間，但是就我的技術水準而言，如果這些改進是顯而易見的，那麼我會在第二次修改代碼時改進。而且之後我還會在每次修改代碼或添加新功能時，反複改進。
編寫髒亂度較低的代碼
關于如何編寫更好的代碼，網上有大量的媒體讨論，例如書籍、部落格、視訊等等。通常他們都會列舉你需要遵守的一系列規則。然而問題在于，這些規則之間往往是互相沖突的。很多人都認為這些規則并沒有什麼用，或者是可以忽視的觀點。的确，在軟體開發中，每個規則都可能有例外，但是不能僅僅因為你無法時時刻刻都遵循這些規則，就否定你應該盡可能地遵循它們。
有關這方面的規則有很多，我們應該從哪裡開始呢？我的建議如下：
1、有簡單的規則，也有複雜的規則。首先學習簡單的規則。這些是你的基礎，是以請務必正确了解這些簡單的規則。
2、每個優先級都有各種規則，你首先應該學習可讀性的規則，然而再學習第二優先的規則。
3、有些規則可以頻繁使用，而有些規則僅适用于特定情況，請先學習前者。
4、有些規則是錯誤的。如果它與許多更簡單、更重要和更實用的規則相沖突，那麼可以暫時忽略。
最後，那些互相沖突的規則又當如何呢？作為技術人員，這個問題無可避免，你應該根據需要解決的問題，選擇更優先的規則。
今後該怎麼做？
逐漸建立屬于自己的一套規則，在編寫代碼時遵循這些規則。即便遵循這些規則不一定能夠保證你寫出整潔的代碼，但是最起碼可以降低代碼的髒亂度。
原文釋出時間：2020-01-17
本文作者：CSDN
本文來自阿裡雲雲栖号合作夥伴“
CSDN”，了解相關資訊可以關注“
”