程序員，多寫點「壞」代碼吧！

何為好代碼？又何為壞代碼？代碼好壞的界限真的有那麼明確嗎？

與其固守於所謂好代碼的「條條框框」，不若走出好壞的邊界，擁抱簡潔又直擊功能需求的「壞」代碼吧！

作者 |Jeremy William

譯者 | 彎月

責編 |仲培藝

出品 |CSDN（ID：CSDNNews）

以下為譯文：

這篇文章的目的是讓你開始懷疑你判斷哪些是「好」代碼哪些是「差」代碼的標準。首先，我會剖析當有人說「這些代碼很好」時的情況，然後從反向定義「差」代碼。

當聽到有人評價某段代碼「很好」時，通常意味著這段代碼與他們在職業生涯或教育中形成的原則性的經驗相符。每個程序員都有不同的評判標準，而且使用不同編程範式（例如面向對象編程與功能編程）的程序員之間的差異可能非常大。下面會列出一些你聽過且深以為然的規則示例：

不要使用全局變數

不要使用單件

重組合輕繼承

每個方法的參數不應該超過 5 個

函數應該只處理一件事情

得墨忒耳定律（最少知識原則，是一個設計指導原則，特別是面向對象的程序）

單一責任原則

不要自我重複

使用目前流行的架構

……

好的代碼常常會教條地遵循這些規則，而任何不遵守這些規則的代碼就會被打上「非正規手段」，或「以後需要重構」的標籤。與良好的代碼相反，差代碼是不遵循這些規則的代碼。

我覺得這是因為我們作為工程師，需要量化事物。我們想要一種可重複的方法來解決所有問題，一種真正的方法，因此我們提出了「好」代碼應該遵守的規則。

這有什麼問題？第一個問題是你無法使用最直接的方式解決問題。你構建了一個限制代碼的迷宮，最終只會導致你需要編寫更多的代碼。編寫這樣的代碼花費的時間更長，因為你不僅需要思考你需要解決的問題，還必須採用滿足你對自己施加的眾多約束的方式。這就好似把一隻手綁在背後寫代碼。

其次，正如我前面所述，最終只會導致你需要編寫更多的代碼。代碼量增大，卻無法解決你的問題。這樣的代碼只是在解決你為自己製造的假問題。這樣的代碼越多，你就越難以掌握項目的進展狀況。為了處理那些本沒有必要的代碼所產生的問題，你需要添加更多的代碼，隨著此類代碼的增多，代碼里的干擾因素會迅速惡化。我曾在嘗試遵循某些體系結構或在代碼中引入模式時，遇到過一些非常糟糕的類似情況。

在我看來，很明顯這些「好」代碼的規則在人們心目中根深蒂固，以至於人們都不會意識到這些規則的存在。前幾天，Hacker News 上有一篇這類典型的文章《通過一個玩具示例學習這個架構，它將解決你所有的問題》（//iolivia.me/posts/24-hours-of-rust-game-dev/），文章說的是實體組件系統（ECS）。Jon Blow 在評論中指出這個實體組件系統完全沒有必要，我們完全可以通過顯而易見的方式編寫代碼，來更好地解決這個問題。我想通過這個例子來說明「好」代碼給人們帶來的心理枷鎖：

很顯然，我猜你會只選擇單一類型的"實體"，並且將所有實體放在同一個數組中？雖然這種方式對你來說可能是顯而易見的，但對於很多（包括我自己）在面向對象以及對現實世界的抽象和建模行為中成長起來的程序員來說，這並沒有那麼明顯。

人們已經被灌輸了對「好」代碼的崇拜，他們甚至無法理解直截了當的代碼。拋開對象和現實世界建模，他們就無法思考編程。讓他們擺脫「好」代碼束縛的唯一方法是將他們當前的規則換成另一個。你不需要實體組件就可以訪問數據，你不需要遵循一開始就被隱藏了起來的規則。編寫解決方案的顯而易見的方式是什麼？這不存在什麼技巧，只需要編寫出你所需功能的代碼，編寫可以完成工作的代碼。實體與解決問題無關，我可以向你保證，《超級馬里奧兄弟》的代碼中沒有實體的概念。

下面是一些「差」代碼：

voidjump(){

mario.yvel =10;

}

我猜你腦子裡肯定響起了警鐘：「如果是馬里奧之外的其他東西需要跳呢？」或者「馬里奧是全局變數嗎？如果我需要多個馬里奧該怎麼辦？」這些事都無關緊要。這段代碼解決了我想解決的問題，馬里奧需要跳起來。不是那個我沒有的馬里奧，也沒有多個馬里奧，以及馬里奧之外的其他東西需要跳起來。不要想著解決你沒有的問題，解決你所面臨的問題，如果我確實需要多個馬里奧，那麼我可以以後再改代碼，這也沒什麼大不了。這些「差」代碼可能更短，更切中要害。

寫差代碼，不用擔心其餘的代碼。忘記所有規則，你只需要編寫代碼來完成任務，解決你的實際問題，而不是讓其他人告訴你將來可能出現的問題。有時你會寫一個很大的 Switch 語句，因為這是最明顯的解決問題的方法，那麼就用 Switch 好了，不要浪費時間思考一種「更好」或「優雅」的方法。當你面對真正的維護困難時，可以寫 abstraction，但是要寫一些不需要「架構」的小型 abstraction。

我們編寫軟體是為了解決問題。如果你編寫的代碼並沒有解決你需要解決的問題，而是為了解決你強加給自己的問題，那麼請考慮編寫一些差代碼。也許你會成為令人刮目相看的 10x developer（10 倍效率的開發者）。

作者：Jeremy William，軟體開發。

本文為 CSDN 翻譯，如需轉載，請註明來源出處。

熱 文推 薦

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