開發過程中的必然產物，劣質代碼產生的五個原因

點擊上方「CSDN」關注我們

作者丨Erik Dietrich

翻譯丨雁驚寒

摘要：作者通過形象的比喻介紹了劣質代碼產生的五個原因，並且說明了劣質代碼是開發過程中的必然產物，而消除劣質代碼則是一場持久戰，需要花時間花精力去解決。以下是譯文

人們可能會認為判斷代碼質量的標準是主觀的。當我使用Pascal變數命名法時，你卻使用駝峰變數命名法，有人會用這些術語來談論代碼的「質量」，但是我並不想這麼做。

所以，讓我們來根據可觀察到的結果來談談代碼質量吧。在閱讀代碼的時候，你可能會根據經驗來判斷某個陌生的代碼質量很差。這是誰寫的代碼？！你並沒有去詳細地了解一些情況就非常武斷地就做出了這個判斷。這段代碼在生產中出的問題是最少的嗎？應用程序的功能是否滿足需求？項目團隊是否能夠按時按預算持續地進行交付？最好的情況就是，在你閱讀代碼的過程中得到這些問題的答案。

我個人在學習代碼方面有一定的優勢。因為我是一個顧問，專門從事代碼評估、開發人員培訓和團隊戰略方面的工作。所以，當客戶的代碼存在很多問題、應用程序不能滿足要求、項目超期或者預算超支的時候，我就會接到來自客戶的求助電話。事實證明，沒有哪個客戶會打電話來說：「嘿，我這裡一切都很好，但你能來看看我們到底做得怎麼樣嗎？」

所以，對於已經有了壞味道的代碼，我不會再去閱讀。對此我進行了評估和分析，發現某些代碼總是與壞味道有關。下面是我總結出來的導致代碼質量變差的五個因素。

1. 可變的全局狀態

在你定義了一個作用域是整個應用程序範圍的變數時，就會產生全局狀態。整個應用程序的作用域範圍被稱為「全局」，而在其中存儲的信息就是「狀態」。當這些變數發生變化時，就產生了「可變的全局狀態」。

對於這個的優缺點，人們可以沒日沒夜討論個不停，你經常會聽到有人把全局狀態稱為「邪惡的化身」。在這裡我不會涉及神學或道德，而是從使用效果來談論可變全局狀態。全局狀態會使你的代碼難以理解。

我來打個比方：假設有人蒙上你的眼睛，然後要求你根據開關的狀態來推斷房子里的燈是否亮著。卧室是否亮著？它的開關是在「開」那個位置嗎？是的。那麼廚房裡的燈呢？噢，這有點棘手，因為有兩個開關可以控制那個燈。但我們仍然可以推斷出燈的狀態。

現在想像一下，假使城裡的每一個人都有一個控制燈的開關。如果你試圖根據開關的狀態來推斷燈是否亮著，那你會很快就會放棄，因為最好的辦法就是直接觀察燈的狀態。這個例子很形象地描述了什麼是全局狀態。任何人都可以隨時隨地改變它。所以如果你想推斷它的值，則你需要運行代碼，看看會發生什麼。

2. 代碼重複

受代碼折磨的第二個因素是代碼重複。你可能會把這個稱為「複製粘貼式編程」。它就是通過簡單地複製粘貼代碼塊來實現同一個功能，達到重用代碼的目的。

這種行為會給代碼庫帶來雜訊。如果你將相同的代碼複製10次，而不是將其抽象出來以供調用，那麼就會產生10倍的代碼量。代碼越多，意味著複雜性越高，出錯的幾率也越大。要讓代碼經受得住時間的考驗，就需要儘可能地降低代碼的複雜度。

除了雜訊問題之外，重複的代碼也會引入錯誤，並帶來更多的工作。它會引入錯誤，因為它會讓你忘記調整你需要調整的東西。它會帶來更多的工作，因為當這段代碼需要修改時，你必須記住在10個不同的地方同步做出修改。但是，維護者們經常會忘記一兩個地方，並且這些重複的代碼會隨著時間的推移而發生變化，對於相同的問題留下了10個並不完全相同的解決方案。

3. 無人關心的依賴關係

有一種說法，軟體架構的核心是對依賴的管理。我個人認為這是軟體設計的核心以及最困難的問題。依賴管理存在於你寫的每一個類、每一個函數，以及你所做的一切。如果你看一下OOP的SOLID原則，你會發現這所有的一切都與依賴管理相關，而且有兩個直接與之對應（分別是I和D）。

糟糕的代碼雜糅在一起。模塊之間互相依賴，僅僅是因為一些無聊的方法調用。你導入整個的JavaScript框架，只是為了執行最基本的計算。有人甚至會在代碼中引入與程序集的循環依賴。

請把代碼和架構看作是對抗某一種熵的永無休止的戰鬥。默認情況下，如果沒有特意地進行干預，代碼就會變成義大利麵條。所以，在無人關心依賴關係的代碼中，你會發現代碼質量很差。

4. 不透明

在討論代碼質量時，通常會聽到有人談論代碼的可讀性。對於質量差的代碼，那些不熟悉並試圖閱讀它的人簡直就是在煎熬。糟糕的命名、奇怪的格式和大量的代碼都會讓可讀性變差。

這裡，我要概括一下這一點，並談論一下代碼的不透明。顯然，難以閱讀的代碼是不透明的。但也存在其他形式的不透明。比如代碼的抽象很難理解，或者也許你有一個類，其方法之間調用複雜，從而使調用該類的邏輯不透明。

一般來說，人們希望能看到能夠清晰地表達其意圖和目的的代碼。而不透明性掩蓋了這一點，導致代碼質量變差。

5. 缺少自動化測試

是的，自動化測試可以幫助你發現錯誤。但在我看來，它對代碼質量的最大影響並不是這個。一個健壯、維護良好的自動化測試套件能讓你對修改代碼充滿信心。

修改代碼的信心並不會直接轉化為代碼質量。但是，它能讓你更加方便更有信心地重構代碼，以改善上面所提到的所有問題：遠離全局狀態、消除重複代碼、最小化依賴關係、並使你的代碼更清晰更乾淨。

如果沒有自動化測試套件，人們就不會有這種信心。他們會將代碼看成是一種古老的設備，「它目前工作的很正常，所以，無論如何都不要去碰它」，這實際上就是代碼質量差的標誌。

避免劣質代碼是一場戰爭

在談論代碼質量的時候，似乎代碼的質量很容易判斷。我花了很多時間與團隊一起降低代碼的總體擁有成本，因此客戶那裡的開發人員通常認為我是根據他們所做的工作來判斷代碼質量的。

但真的，我做得越多，我判斷的就越少。首先，我不知道他們遇到了什麼樣的困難，代碼是如何成為現在這樣子的。代碼庫會很自然地變得亂七八糟，除非你認真努力去防止這種情況的發生。劣質代碼是默認狀態。所以並不是說他們寫了劣質代碼，而是他們沒有時間和資源去阻止代碼變差。

認識到這種觀點對團隊和管理者都是有益的。除非你投資於你的團隊、你的教育和你的發展過程，否則代碼的維護成本會越來越高，而且質量也會越來越差。所以，請立即行動起來吧，防止出現我在這裡討論過的問題。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！