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

就像這樣：

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

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

比如下面這段：

很多程序員喜歡簡(jiǎn)單的東西：簡(jiǎn)單的函數(shù)名、簡(jiǎn)單的變量名、代碼里翻來(lái)覆去只用那么幾個(gè)單詞命名；能縮寫就縮寫、能省略就省略、能合并就合并。這類人寫出來(lái)的代碼里充斥著各種g/s/gos/of/mss之類的全世界沒(méi)人懂的縮寫，或者一長(zhǎng)串不知道在做什么的連續(xù)調(diào)用。

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

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

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

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

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

“但是，那樣就多了一個(gè)類了呀。”

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

文件路徑變更的時(shí)候，會(huì)把代碼改成這樣：

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

之后可能會(huì)再變成這樣：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這里還有一個(gè)核心問(wèn)題，重構(gòu)的復(fù)雜度跟代碼的復(fù)雜度不是線性相關(guān)的。比如有1000行爛代碼，重構(gòu)要花1個(gè)小時(shí)，那么5000行爛代碼的重構(gòu)可能要花2、3天。要對(duì)一個(gè)失去控制的工程做重構(gòu)，往往還不如重寫更有效率。

而拋開具體的重構(gòu)方式，從受益上來(lái)說(shuō)，重構(gòu)也是一件很麻煩的事情：它很難帶來(lái)直接受益，也很難量化。這里有個(gè)很有意思的現(xiàn)象，基本關(guān)于重構(gòu)的書籍無(wú)一例外的都會(huì)有獨(dú)立的章節(jié)介紹“如何向boss說(shuō)明重構(gòu)的必要性”。

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

舉個(gè)例子，一個(gè)工程的代碼可讀性很差，那么它會(huì)影響多少開發(fā)效率？

你可以說(shuō)：之前改一個(gè)模塊要3天，重構(gòu)之后1天就可以了。但是怎么應(yīng)對(duì)“不就是做個(gè)數(shù)據(jù)庫(kù)操作嗎為什么要3天”這類問(wèn)題？爛代碼“爛”的因素有不確定性、開發(fā)效率也因人而異，想要證明這個(gè)東西“確實(shí)”會(huì)增加兩天開發(fā)時(shí)間，往往反而會(huì)變成“我看了3天才看懂這個(gè)函數(shù)是做什么的”或者“我做這么簡(jiǎn)單的修改要花3天”這種神經(jīng)病才會(huì)去證明的命題。

而另一面，許多技術(shù)負(fù)責(zé)人也意識(shí)到了代碼質(zhì)量和重構(gòu)的必要性，“那就重構(gòu)嘛”，或者“如果看到問(wèn)題了，那就重構(gòu)”。上一個(gè)問(wèn)題解決了，但實(shí)際上關(guān)于重構(gòu)的代價(jià)和收益仍然是一筆糊涂賬，在沒(méi)有分配給你更多資源、沒(méi)有明確的目標(biāo)、沒(méi)有具體方法的情況下，很難想象除了有代碼潔癖的人還有誰(shuí)會(huì)去執(zhí)行這種莫名其妙的任務(wù)。

于是往往就會(huì)形成這種局面：

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

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

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

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

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

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

• 做出合理的抽象。

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

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

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

寫出好代碼的方法論很多，但我認(rèn)為寫出好代碼的核心反而是聽起來(lái)非常low的“持續(xù)不斷的練習(xí)”。這里就不展開了，留到下篇再說(shuō)。

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

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

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

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

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

前一陣面試的時(shí)候增加了白板編程、最近又增加了上機(jī)編程的題目。發(fā)現(xiàn)了一個(gè)現(xiàn)象：一個(gè)人工作了幾年、做過(guò)很多項(xiàng)目、帶過(guò)團(tuán)隊(duì)、發(fā)了一些文章，不一定能代表他代碼寫的好；反之，一個(gè)人代碼寫的好，其它方面的能力一般不會(huì)太差。

舉個(gè)例子，最近喜歡用“寫一個(gè)代碼行數(shù)統(tǒng)計(jì)工具”作為面試的上機(jī)編程題目。很多人看到題目之后第一反映是，這道題太簡(jiǎn)單了，這不就是寫寫代碼嘛。

從實(shí)際效果來(lái)看，這道題識(shí)別度卻還不錯(cuò)。

首先，題目足夠簡(jiǎn)單，即使沒(méi)有看過(guò)《面試寶典》之類書的人也不會(huì)吃虧。而題目的擴(kuò)展性很好，即使提前知道題目，配合不同的條件，可以變成不同的題目。比如要求按文件類型統(tǒng)計(jì)行數(shù)、或者要求提高統(tǒng)計(jì)效率、或者統(tǒng)計(jì)的同時(shí)輸出某些單詞出現(xiàn)的次數(shù)，等等。

從考察點(diǎn)來(lái)看，首先是基本的樹的遍歷算法；其次有一定代碼量，可以看出程序員對(duì)代碼的組織能力、對(duì)問(wèn)題的抽象能力；上機(jī)編碼可以很簡(jiǎn)單的看出應(yīng)聘者是不是很久沒(méi)寫程序了；還包括對(duì)于程序易用性和性能的理解。

最重要的是，最后的結(jié)果是一個(gè)完整的程序，我可以按照日常工作的標(biāo)準(zhǔn)去評(píng)價(jià)程序員的能力，而不是從十幾行的函數(shù)里意淫這個(gè)人在日常工作中大概會(huì)有什么表現(xiàn)。

但即使這樣，也很難拍著胸脯說(shuō)，這個(gè)人寫的代碼質(zhì)量沒(méi)問(wèn)題。畢竟面試只是代表他有寫出好代碼的能力，而不是他將來(lái)會(huì)寫出好代碼。

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

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

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

如果你看到了這里還沒(méi)有喪失希望，那么可以期待一下這篇文章的第二部分，關(guān)于如何提高代碼質(zhì)量的一些建議和方法。