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