寫爛代碼很容易，但是就算寫成一坨屎，能用即可， 你同意這種觀點(diǎn)嗎？

程序員剛?cè)胄薪?jīng)常聽到一些觀點(diǎn)

你要把精力放在需求文檔/功能設(shè)計(jì)/架構(gòu)設(shè)計(jì)/理解原理 （ABCD ）上，寫代碼只是把想法翻譯成編程語言而已，是一個沒什么技術(shù)含量的事情。

當(dāng)時的我在聽到這種觀點(diǎn)時會有一種近似于高冷的不屑： 你們就是一群傻子，根本不懂代碼質(zhì)量的重要性，這么下去遲早有一天會踩坑。

可是幾個月之后，他們似乎也沒怎么踩坑。而隨著編程技術(shù)一直在不斷發(fā)展，帶來了更多的我以前認(rèn)為是傻子的人加入到程序員這個行業(yè)中來。

語言越來越高級、封裝越來越完善，各種技術(shù)都在幫助程序員提高生產(chǎn)代碼的效率，依靠層層封裝，程序員真的不需要了解一丁點(diǎn)技術(shù)細(xì)節(jié)，只要把需求里的內(nèi)容逐行翻譯出來就可以了。

很多程序員不知道要怎么組織代碼、怎么提升運(yùn)行效率、底層是基于什么原理，他們寫出來的是在我心目中爛成一坨屎一樣的代碼。 但是那一坨屎一樣代碼竟然能正常工作。

[[434507]]

即使我認(rèn)為他們寫的代碼是坨屎，但是從不接觸代碼的人的視角來看（比如說你的boss），代碼編譯過了，測試過了，上線運(yùn)行了一個月都沒出問題，你還想要奢求什么？

所以，即使不情愿，也必須承認(rèn)，別人寫的代碼能正常運(yùn)行，且不出錯，那就是牛x。

爛代碼終究是爛代碼

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

[[434508]]

想要修改功能時卻發(fā)現(xiàn)程序里充斥著各種無法理解的邏輯、改完之后莫名其妙的bug一個接一個，接手這個項(xiàng)目的人開始漫無目的的加班，并且原本一個挺樂觀開朗的人漸漸的開始喜歡問候別人祖宗了。

總結(jié)幾類經(jīng)常被罵娘的爛代碼：

ி 意義不明

能力差的程序員容易寫出意義不明的代碼，他們不知道自己究竟在做什么。

就像這樣：

void Save(void) 
{ 
  int x; 
  for(x=0; x<100; x++) 
  { 
    //防止保存失敗，保存100次 
    Flash_Write(); 
  } 
} 

對于這類程序員，我一般建議他們轉(zhuǎn)行。

ி 不說人話

不說人話是新手最經(jīng)常出現(xiàn)的問題，直接的表現(xiàn)就是寫了一段很簡單的代碼，其他人卻看不懂。

比如下面這段：

很多程序員喜歡簡單的東西： 簡單的函數(shù)名、簡單的變量名，代碼里翻來覆去只用那么幾個單詞命名；能縮寫就縮寫、能省略就省略、能合并就合并。

這類人寫出來的代碼里充斥著各種g/s/gos/of/mss之類的全世界沒人懂的縮寫，或者一長串不知道在做什么的連續(xù)調(diào)用。

還有很多程序員喜歡復(fù)雜，各種宏定義、位運(yùn)算之類寫的天花亂墜，生怕代碼讓別人一下子看懂了會顯得自己水平不夠。

簡單的說，他們的代碼是寫給機(jī)器的，不是給人看的。

ி 不恰當(dāng)?shù)慕M織

不恰當(dāng)?shù)慕M織是高級一些的爛代碼，程序員在寫過一些代碼之后，有了基本的代碼風(fēng)格，但是對于規(guī)模大一些的工程的掌控能力不夠，不知道代碼應(yīng)該如何解耦、分層和組織。

這種反模式的現(xiàn)象是經(jīng)常會看到一段代碼在工程里拷來拷去；某個文件里放了一大坨堆砌起來的代碼；一個函數(shù)堆了幾百上千行；或者一個簡單的功能七拐八繞的調(diào)了幾十個函數(shù)，在某個難以發(fā)現(xiàn)的猥瑣的小角落里默默的調(diào)用了某些關(guān)鍵邏輯。

這類代碼大多復(fù)雜度高，難以修改，經(jīng)常一改就崩；而另一方面，創(chuàng)造了這些代碼的人傾向于修改代碼，畏懼創(chuàng)造代碼，他們寧愿讓原本復(fù)雜的代碼一步步變得更復(fù)雜，也不愿意重新組織代碼。當(dāng)你面對一個幾千行的類，問為什么不把某某邏輯提取出來的時候，他們會說：

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

ி 假設(shè)和缺少抽象

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

文件路徑變更的時候，會把代碼改成這樣：

需要加載的內(nèi)容更豐富的時候，會再變成這樣：

之后可能會再變成這樣：

這類程序員往往是項(xiàng)目組里開發(fā)效率比較高的人，但是大量的業(yè)務(wù)開發(fā)工作導(dǎo)致他們不會做多余的思考，他們的口頭禪是：“我每天要做XX個需求”或者“先做完需求再考慮其他的吧”。

這種反模式表現(xiàn)出來的后果往往是代碼很難復(fù)用，面對deadline的時候，程序員迫切的想要把需求落實(shí)成代碼，而這往往也會是個循環(huán)：寫代碼的時候來不及考慮復(fù)用，代碼難復(fù)用導(dǎo)致之后的需求還要繼續(xù)寫大量的代碼。

一點(diǎn)點(diǎn)積累起來的大量的代碼又帶來了組織和風(fēng)格一致性等問題，最后形成了一個新功能基本靠拷的遺留系統(tǒng)。

ி 還有嗎？

爛代碼還有很多種類型，沿著功能-性能-可讀-可測試-可擴(kuò)展這條路線走下去，還能看到很多匪夷所思的例子。

那么什么是爛代碼？個人認(rèn)為，爛代碼包含了幾個層次：

▶ 如果只是一個人維護(hù)的代碼，滿足功能和性能要求倒也足夠了。

▶ 如果在一個團(tuán)隊(duì)里工作，那就必須易于理解和測試，讓其它人員有能力修改各自的代碼。

同時，越是處于系統(tǒng)底層的代碼，擴(kuò)展性也越重要。

所以，當(dāng)一個團(tuán)隊(duì)里的底層代碼難以閱讀、耦合了上層的邏輯導(dǎo)致難以測試、或者對使用場景做了過多的假設(shè)導(dǎo)致難以復(fù)用時，雖然完成了功能，它依然是坨屎一樣的代碼。

ி 夠用的代碼

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

很多工程剛開始可能只是一個人負(fù)責(zé)的小項(xiàng)目，大家關(guān)心的重點(diǎn)只是代碼能不能順利的實(shí)現(xiàn)功能、按時完工。

過上一段時間，其他人參與時才發(fā)現(xiàn)代碼寫的有問題，看不懂，不敢動。需求方又開始催著上線了，怎么辦？只好小心翼翼的只改邏輯而不動結(jié)構(gòu)，然后在注釋里寫上這么實(shí)現(xiàn)很ugly，以后明白內(nèi)部邏輯了再重構(gòu)。

再過上一段時間，有個相似的需求，想要復(fù)用里面的邏輯，這時才意識到代碼里做了各種特定場景的專用邏輯，復(fù)用非常麻煩。為了趕進(jìn)度只好拷代碼然后改一改。問題解決了，問題也加倍了。

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

重構(gòu)不是萬能藥

程序員最喜歡跟程序員說的謊話之一就是： 現(xiàn)在進(jìn)度比較緊，等X個月之后項(xiàng)目進(jìn)度寬松一些再去做重構(gòu)。

不能否認(rèn)在某些（極其有限的）場景下重構(gòu)是解決問題的手段之一，但是寫了不少代碼之后發(fā)現(xiàn)，重構(gòu)往往是程序開發(fā)過程中最復(fù)雜的工作。花一個月寫的爛代碼，要花更長的時間、更高的風(fēng)險去重構(gòu)。

曾經(jīng)經(jīng)歷過幾次忍無可忍的大規(guī)模重構(gòu)，每一次重構(gòu)之前都是找齊了組里的高手，開了無數(shù)次分析會，把組內(nèi)需求全部暫停之后才敢開工，而重構(gòu)過程中往往哀嚎遍野，幾乎每天都會出上很多意料之外的問題，上線時也幾乎必然會出幾個問題。

從技術(shù)上來說，重構(gòu)復(fù)雜代碼時，要做三件事： 理解舊代碼、分解舊代碼、構(gòu)建新代碼 。而待重構(gòu)的舊代碼往往難以理解；模塊之間過度耦合導(dǎo)致牽一發(fā)而動全身，不易控制影響范圍；舊代碼不易測試導(dǎo)致無法保證新代碼的正確性。

重構(gòu)之后能提升多少效率？能降低多少風(fēng)險？很難答上來，爛代碼本身就不是一個可以簡單的標(biāo)準(zhǔn)化的東西。

總結(jié)

不寫代碼的人認(rèn)為應(yīng)該重構(gòu)，重構(gòu)很簡單，無論新人還是老人都有責(zé)任做重構(gòu)。

寫代碼老手認(rèn)為應(yīng)該遲早應(yīng)該重構(gòu)，重構(gòu)很難，現(xiàn)在湊合用，這事別落在我頭上。

寫代碼的新手認(rèn)為不出bug就謝天謝地了，我也不知道怎么重構(gòu)。

✉ 寫好代碼很難

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

✔ 理解要開發(fā)的功能需求。

✔ 了解程序的運(yùn)行原理。

✔ 做出合理的抽象。

✔ 組織復(fù)雜的邏輯。

✔ 對自己開發(fā)效率的正確估算。

✔ 持續(xù)不斷的練習(xí)。

寫出好代碼的方法論很多，但我認(rèn)為寫出好代碼的核心反而是聽起來非常low的“持續(xù)不斷的練習(xí)”。

很多程序員在寫了幾年代碼之后并沒有什么長進(jìn)，代碼仍然爛的讓人不忍直視，原因有兩個主要方面：

1、環(huán)境是很重要的因素之一，在爛代碼的熏陶下很難理解什么是好代碼，知道的人大部分也會選擇隨波逐流。

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

而工作幾年之后的人很難再說服他們?nèi)ヌ岣叽a質(zhì)量，你只會反復(fù)不斷的聽到：“那又有什么用呢？”或者“以前就是這么做的啊？”之類的說法。

那么從源頭入手，提高招人時對代碼的質(zhì)量的要求怎么樣？

前一陣面試的時候發(fā)現(xiàn)了一個現(xiàn)象：

一個人工作了幾年、做過很多項(xiàng)目、帶過團(tuán)隊(duì)、發(fā)了一些文章，不一定能代表他代碼寫的好；反之，一個人代碼寫的好，其它方面的能力一般不會太差。

悲觀的結(jié)語

說了那么多，結(jié)論其實(shí)只有兩條，作為程序員：

⊱ 不要奢望其他人會寫出高質(zhì)量的代碼

⊱ 不要以為自己寫出來的是高質(zhì)量的代碼