寫爛程式碼很容易；

就算寫成一坨翔但能用就行。

剛入程式設計師這行的時候經常聽到一個觀點：

你要把精力放在ABCD（需求文件/功能設計/架構設計/理解原理）上，寫程式碼只是把想法翻譯成程式語言而已，是一個沒什麼技術含量的事情。

當時的我在聽到這種觀點時會有一種近似於高冷的不屑：你們就是一群傻子，根本不懂程式碼質量的重要性，這麼下去遲早有一天會踩坑。

可是幾個月之後，他們似乎也沒怎麼踩坑。而隨著程式設計技術一直在不斷髮展，帶來了更多的我以前認為是傻子的人加入到程式設計師這個行業中來。

語言越來越高階、封裝越來越完善，各種技術都在幫助程式設計師提高生產程式碼的效率，依靠層層封裝，程式設計師真的不需要了解一丁點技術細節，只要把需求裡的內容逐行翻譯出來就可以了。

很多程式設計師不知道要怎麼組織程式碼、怎麼提升執行效率、底層是基於什麼原理，他們寫出來的是在我心目中爛成一坨翔一樣的程式碼。

但是那一坨翔一樣程式碼竟然能正常工作。

即使我認為他們寫的程式碼是坨翔，但是從不接觸程式碼的人的視角來看（比如說你的boss），程式碼編譯過了，測試過了，上線運行了一個月都沒出問題，你還想要奢求什麼？

所以，即使不情願，也必須承認，時至今日，寫程式碼這件事本身沒有那麼難了。

—————————

爛程式碼終究是爛程式碼

但是偶爾有那麼幾次，寫爛程式碼的人離職了之後，事情似乎又變得不一樣了。

想要修改功能時卻發現程式裡充斥著各種無法理解的邏輯、改完之後莫名其妙的bug一個接一個，接手這個專案的人開始漫無目的的加班，並且原本一個挺樂觀開朗的人漸漸的開始喜歡問候別人祖宗了。

———————————————

我總結了幾類經常被罵孃的爛程式碼：

ி意義不明

能力差的程式設計師容易寫出意義不明的程式碼，他們不知道自己究竟在做什麼.

就像這樣：

對於這類程式設計師，我一般建議他們轉行。

ி不說人話

不說人話是新手最經常出現的問題，直接的表現就是寫了一段很簡單的程式碼，其他人卻看不懂。

比如下面這段：

很多程式設計師喜歡簡單的東西：簡單的函式名、簡單的變數名、程式碼裡翻來覆去只用那麼幾個單詞命名；能縮寫就縮寫、能省略就省略、能合併就合併。

這類人寫出來的程式碼裡充斥著各種g/s/gos/of/mss之類的全世界沒人懂的縮寫，或者一長串不知道在做什麼的連續呼叫。

還有很多程式設計師喜歡複雜，各種巨集定義、位運算之類寫的天花亂墜，生怕程式碼讓別人一下子看懂了會顯得自己水平不夠。

簡單的說，他們的程式碼是寫給機器的，不是給人看的。

ி不恰當的組織

不恰當的組織是高階一些的爛程式碼，程式設計師在寫過一些程式碼之後，有了基本的程式碼風格，但是對於規模大一些的工程的掌控能力不夠，不知道程式碼應該如何解耦、分層和組織。

這種反模式的現象是經常會看到一段程式碼在工程裡拷來拷去；某個檔案裡放了一大坨堆砌起來的程式碼；一個函式堆了幾百上千行；或者一個簡單的功能七拐八繞的調了幾十個函式，在某個難以發現的猥瑣的小角落裡默默的呼叫了某些關鍵邏輯。

這類程式碼大多複雜度高，難以修改，經常一改就崩；而另一方面，創造了這些程式碼的人傾向於修改程式碼，畏懼創造程式碼，他們寧願讓原本複雜的程式碼一步步變得更復雜，也不願意重新組織程式碼。當你面對一個幾千行的類，問為什麼不把某某邏輯提取出來的時候，他們會說：

“但是，那樣就多了一個類了呀。”

ி假設和缺少抽象

相對於前面的例子，假設這種反模式出現的場景更頻繁，花樣更多，始作俑者也更難以自己意識到問題。比如：

檔案路徑變更的時候，會把程式碼改成這樣：

需要載入的內容更豐富的時候，會再變成這樣：

之後可能會再變成這樣：

這類程式設計師往往是專案組裡開發效率比較高的人，但是大量的業務開發工作導致他們不會做多餘的思考，他們的口頭禪是：“我每天要做XX個需求”或者“先做完需求再考慮其他的吧”。

這種反模式表現出來的後果往往是程式碼很難複用，面對deadline的時候，程式設計師迫切的想要把需求落實成程式碼，而這往往也會是個迴圈：寫程式碼的時候來不及考慮複用，程式碼難複用導致之後的需求還要繼續寫大量的程式碼。

一點點積累起來的大量的程式碼又帶來了組織和風格一致性等問題，最後形成了一個新功能基本靠拷的遺留系統。

ி還有嗎？

爛程式碼還有很多種型別，沿著功能-效能-可讀-可測試-可擴充套件這條路線走下去，還能看到很多匪夷所思的例子。

那麼什麼是爛程式碼？個人認為，爛程式碼包含了幾個層次：

▶ 如果只是一個人維護的程式碼，滿足功能和效能要求倒也足夠了。

▶如果在一個團隊裡工作，那就必須易於理解和測試，讓其它人員有能力修改各自的程式碼。

同時，越是處於系統底層的程式碼，擴充套件性也越重要。

所以，當一個團隊裡的底層程式碼難以閱讀、耦合了上層的邏輯導致難以測試、或者對使用場景做了過多的假設導致難以複用時，雖然完成了功能，它依然是坨翔一樣的程式碼。

ி夠用的程式碼

而相對的，如果一個工程的程式碼難以閱讀，能不能說這個是爛程式碼？很難下定義，可能算不上好，但是能說它爛嗎？如果這個工程自始至終只有一個人維護，那個人也維護的很好，那它似乎就成了“夠用的程式碼”。

很多工程剛開始可能只是一個人負責的小專案，大家關心的重點只是程式碼能不能順利的實現功能、按時完工。

過上一段時間，其他人蔘與時才發現程式碼寫的有問題，看不懂，不敢動。需求方又開始催著上線了，怎麼辦？只好小心翼翼的只改邏輯而不動結構，然後在註釋裡寫上這麼實現很ugly，以後明白內部邏輯了再重構。

再過上一段時間，有個相似的需求，想要複用裡面的邏輯，這時才意識到程式碼裡做了各種特定場景的專用邏輯，複用非常麻煩。為了趕進度只好拷程式碼然後改一改。問題解決了，問題也加倍了。

幾乎所有的爛程式碼都是從“夠用的程式碼”演化來的，程式碼沒變，使用程式碼的場景發生變了，原本夠用的程式碼不符合新的場景，那麼它就成了爛程式碼。

———————————

重構不是萬能藥

它很難帶來直接收益

程式設計師最喜歡跟程式設計師說的謊話之一就是：現在進度比較緊，等X個月之後專案進度寬鬆一些再去做重構。

不能否認在某些（極其有限的）場景下重構是解決問題的手段之一，但是寫了不少程式碼之後發現，重構往往是程式開發過程中最複雜的工作。花一個月寫的爛程式碼，要花更長的時間、更高的風險去重構。

曾經經歷過幾次忍無可忍的大規模重構，每一次重構之前都是找齊了組裡的高手，開了無數次分析會，把組內需求全部暫停之後才敢開工，而重構過程中往往哀嚎遍野，幾乎每天都會出上很多意料之外的問題，上線時也幾乎必然會出幾個問題。

從技術上來說，重構複雜程式碼時，要做三件事：理解舊程式碼、分解舊程式碼、構建新程式碼。而待重構的舊程式碼往往難以理解；模組之間過度耦合導致牽一髮而動全身，不易控制影響範圍；舊程式碼不易測試導致無法保證新程式碼的正確性。

重構之後能提升多少效率？能降低多少風險？很難答上來，爛程式碼本身就不是一個可以簡單的標準化的東西。

————————————

於是往往就會形成這種局面：

不寫程式碼的人認為應該重構，重構很簡單，無論新人還是老人都有責任做重構。

寫程式碼老手認為應該遲早應該重構，重構很難，現在湊合用，這事別落在我頭上。

寫程式碼的新手認為不出bug就謝天謝地了，我也不知道怎麼重構。

✉ 寫好程式碼很難

與寫出爛程式碼不同的是，想寫出好程式碼有很多前提：

✔ 理解要開發的功能需求。

✔瞭解程式的執行原理。

✔做出合理的抽象。

✔組織複雜的邏輯。

✔對自己開發效率的正確估算。

✔持續不斷的練習。

—————————————————

寫出好程式碼的方法論很多，但我認為寫出好程式碼的核心反而是聽起來非常low的“持續不斷的練習”。

很多程式設計師在寫了幾年程式碼之後並沒有什麼長進，程式碼仍然爛的讓人不忍直視，原因有兩個主要方面：

1、環境是很重要的因素之一，在爛程式碼的薰陶下很難理解什麼是好程式碼，知道的人大部分也會選擇隨波逐流。

2、還有個人性格之類的說不清道不明的主觀因素，寫出爛程式碼的程式設計師反而都是一些很好相處的人，他們往往熱愛公司團結同事平易近人工作任勞任怨–只是程式碼很爛而已。

而工作幾年之後的人很難再說服他們去提高程式碼質量，你只會反覆不斷的聽到：“那又有什麼用呢？”或者“以前就是這麼做的啊？”之類的說法。

那麼從源頭入手，提高招人時對程式碼的質量的要求怎麼樣？

前一陣面試的時候發現了一個現象：

一個人工作了幾年、做過很多專案、帶過團隊、發了一些文章，不一定能代表他程式碼寫的好；反之，一個人程式碼寫的好，其它方面的能力一般不會太差。

☡悲觀的結語

說了那麼多，結論其實只有兩條，作為程式設計師：

⊱不要奢望其他人會寫出高質量的程式碼

⊱不要以為自己寫出來的是高質量的程式碼

-END-

不管你是轉行也好，初學也罷，進階也可，如果你想學程式設計，進階程式設計師~

【值得關注】我的 程式設計學習交流俱樂部 ！【點選進入】

C語言入門資料（網盤連結免費分享）：

C語言推薦書籍（PDF免費分享）：