CSDN

訂閱

發行量:967 

「整潔代碼根本就是個騙局!」

——事實上,整潔的代碼就是一個彌天大謊,沒有人會寫整潔的代碼。作者| Chad Befus譯者 | 彎月,責編 | 郭芮以下為譯文:我對《Clean Code》這本書又愛又恨。

2020-01-17 02:59 / 2人閱讀過此篇文章  

怎樣的代碼才是整潔的代碼,而怎樣的代碼不是呢?——事實上,整潔的代碼就是一個彌天大謊,沒有人會寫整潔的代碼。

作者 | 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 翻譯,轉載請註明來源出處。





文章標籤: