在軟件行業(yè)里，有著一些明確存在，卻總被人刻意忽視著的問題。在英語里，這個現(xiàn)象被稱之為“Elephant In The Room”，房間里的大象。Niclas Hedhman，Apache 軟件基金會副總裁，33 年的工作經(jīng)歷，在他觀察下的軟件開發(fā)行業(yè)，都有哪些房間里的大象？

多年來，我做了許多觀察。最新的觀察是關(guān)于一件事，這件事是顯而易見，我們卻沒有注意過它?！胺块g里的大象”是英語中的一種表達(dá)，指的是那些沒有人敢談?wù)搮s又很明顯的事情。這個演講，我想談?wù)勡浖袠I(yè)里沒有人敢談?wù)摰脑掝}，但卻能把我們帶到另一個層次。

爛代碼是誰寫的？

前面提到了我已經(jīng)做了觀察。我們都會觀察。幾乎每個人都看到過漂亮的代碼。這些代碼簡潔明了，而且很強(qiáng)大。這種代碼易于理解，易于使用，易于擴(kuò)展。我們可以很快地完成工作，把事情做好。然而，如果我們問人們，他們是否在漂亮的代碼基礎(chǔ)上工作，大多數(shù)人說沒有。那么，這個代碼是從哪里來的呢？嗯，很少有開發(fā)人員能寫出這些漂亮的代碼。

另一方面，爛代碼隨處可見。我們都見過爛代碼。我們中有些人每天都要和爛代碼作斗爭，我們都為寫出更多的爛代碼而內(nèi)疚。

但是為什么？為什么你要寫爛代碼？你知道這代碼很爛，你還要寫。為什么？這是為什么？

我們會聽到這樣的話，這代碼已經(jīng)很爛了，我沒辦法改善，因?yàn)闆]法測試，因?yàn)榇a太復(fù)雜，因?yàn)樽鲂枰母淖兲ｋU(xiǎn)了。

我現(xiàn)在很忙。交付期限快到了，等有時間我們會解決這個問題的。現(xiàn)在，我們需要把握重點(diǎn)，把這個問題先擱一擱。

嘿，我覺得這代碼也沒有很爛。我的隊(duì)友們都很不高興，但我認(rèn)為他們不夠聰明，無法欣賞這代碼。

我要說，這都是狗屁。那些都是借口，因?yàn)椴蝗晃覀円彩懿涣俗约哼@樣。我們怎么能明知做不好工作，卻不感到羞恥，為什么不去換份工作呢？

我的推斷是，還有更加深層次的原因，是我們行業(yè)存在已久的危機(jī)。我覺得這非常令人不安。

首先，我們來看一些事實(shí)。我們的行業(yè)正在以一個驚人的速度在發(fā)展。幾乎每周都有新技術(shù)出現(xiàn)，這種情況在過去的三十年中一直如此，我見證了這一切。行業(yè)對人們所創(chuàng)造的東西幾乎沒有限制。需要學(xué)習(xí)的東西也多到令人震驚。

開源現(xiàn)在是一個公共領(lǐng)域，我們幾乎不需要從頭開始。我們在已有的平臺上工作，以新的方式將已經(jīng)存在的合起來，再加上自己的創(chuàng)新，就發(fā)布了這個產(chǎn)品，其他人可以再在這個基礎(chǔ)上創(chuàng)造。這造成了產(chǎn)量以史無前例的速度加速產(chǎn)出。

有沒有人能告訴我這是什么？

這是全世界程序員數(shù)的增長曲線。具體的數(shù)字不重要，重要的是，程序員人數(shù)在每 5 年左右就會翻一番。從 1950 以來，這種增加幾乎不間斷。每 5 年，世界上的程序員的數(shù)量增加了一倍。

關(guān)于這種指數(shù)增長，我們能看出些什么？有兩件事。好的是，這種增長不會永遠(yuǎn)繼續(xù)下去。因?yàn)榈厍蛏蠜]有這么多人。壞的是，這些程序員中，有一半都工作經(jīng)驗(yàn)都不足五年。實(shí)際情況可能更糟，因?yàn)檫€有很多程序員將在未來在 10-15 年離開這個行業(yè)。

所以，我們行業(yè)非常缺乏經(jīng)驗(yàn)，而且一直缺乏經(jīng)驗(yàn)。更糟糕的是，由于技術(shù)的大環(huán)境變化如此迅速，在一項(xiàng)技術(shù)過時之前，沒有足夠的時間來積累經(jīng)驗(yàn)，然后所有人又開始使用另一個技術(shù)了。這導(dǎo)致同樣的錯誤是一次又一次的循環(huán)發(fā)生。

大多數(shù)程序員不會發(fā)明新技術(shù)供別人使用。我們使用熱門的技術(shù)。我們相信，其他人已經(jīng)知道何種技術(shù)適合我們。我們也不會動腦去思考。我再說一遍，我們不會批判地思考，并且我們像信仰宗教信條一樣，相信別人告訴我該怎么做，我就應(yīng)該怎么做。

行業(yè)里有哪些神話？

讓我們來看看我們的行業(yè)的神話。這神話有很多。由于我們的行為像一個宗教教派，也產(chǎn)生了許多神話，有的是偶然，有的是刻意而為。

神話是由特定的一類人創(chuàng)造和傳播的。我們很容易受到我們所尊重的人所說的話的影響。供應(yīng)商試圖向我們出售產(chǎn)品和服務(wù)。同樣，會議上的發(fā)言人，我們閱讀書和博客的作者，他們是向我們賣他們的書，網(wǎng)站或服務(wù)。在工作中，我們聽比我們更資深的人的話，這些人通常是那些有一些成績的同事。但如果這是一個大公司，那么這些同事的話就會涉及辦公室政治，或有為了贏得聲望的因素，我們應(yīng)該對這些人的話產(chǎn)生質(zhì)疑。

讓我們看看業(yè)內(nèi)典型的神話，那些所謂的常識。

神話一：軟件很容易修改

我們生活在這樣一個概念里，軟件是.... 軟的，靈活的。打幾個字，我們就可以改變它，讓它做一些完全不同的事。重新設(shè)計(jì)的電子產(chǎn)品需要幾天的時間，而軟件只需要幾分鐘。但是，嘿…現(xiàn)實(shí)是很殘酷。它不是神話，而且會反擊。大多數(shù)軟件不僅是難以改變，而且一旦用了就往往不能結(jié)束。一旦寫好軟件，部署好，要想擺脫它，門都沒有，無論這軟件用起來多么瑣碎或一無是處。

神話二：人多力量大

這種情況在公司管理中普遍存在。如果我們需要多花一倍的精力做某件事，我們就多招一倍的程序員。這肯定行。

《人月神話》（The Mythical Man-Month）是 1975 年出版的一本書。40 年前，作者 Fred Brooks 指出，增加人手到一個落后于計(jì)劃進(jìn)度的項(xiàng)目里，實(shí)際上會使項(xiàng)目進(jìn)度變得更慢。最終，花費(fèi)在溝通所需的時間將比每個人有的時間加在一起還要多。

神話三：程序員可以互相替代

大公司的經(jīng)理們的另一個最喜歡的神話就是是，程序員是可互換的零件。如果一個程序員離開了，我們就從大街上找擇一個新的，代替他。 但是那根本行不通。軟件知識不在代碼里，而存在于寫代碼人的大腦里。如果你以前搶修過別人的代碼庫，而這寫代碼的這個程序員沒有給你任何工作交接，你就知道我在說什么了。

如果寫代碼庫的人離開了，則需要兩個新人來代替他，這兩人可能需要一年的時間來搞明白這個代碼庫的作者寫的到底是什么，也有可能永遠(yuǎn)都搞不清楚。

神話四：抽象概念很好

這是我的最愛的神話之一。如果不是這些抽象概念，我們不會有互聯(lián)網(wǎng)，也沒有網(wǎng)上那些很棒的網(wǎng)站。如果我們必須為處理器寫二進(jìn)制指令，就有麻煩了。編程語言，協(xié)議，數(shù)據(jù)格式，框架，還有更多的抽象的概念幫助我們完成工作。

但大多數(shù)抽象概念都是在我們寫的程序中產(chǎn)生的。我們創(chuàng)造出的抽象概念只是小聰明，概念不夠清晰。我們也沒有很多創(chuàng)造抽象概念的經(jīng)驗(yàn)，所以我們創(chuàng)造出的是混亂。我們創(chuàng)造的抽象概念往往很糟糕，一片混亂，不利于項(xiàng)目的完成。

神話五：方法解決問題

很多人兜售各種方法論。20 世紀(jì) 80 年代后期使用的是用例對象方法，然后是理性統(tǒng)一過程和許多其他所謂的計(jì)算機(jī)輔助軟件工程的方法，最后是統(tǒng)一建模語言 UML。Kent Beck 介紹了到極限編程方法，這是第一個敏捷方法，是一個反對瀑布式的方法。近 10 年間，Scrum，看板和其他方法備受吹捧。所有這些都方法都承諾解決軟件這一復(fù)雜工作。

我的觀察結(jié)果是，沒有一個方法像宣傳的那么好。幾乎所有的軟件項(xiàng)目都依賴于大神。能完成項(xiàng)目的人，無論用什么方法，都能完成。對于新的項(xiàng)目，大神們擅長的是開始著手做。在維護(hù)或改進(jìn)代碼庫的時候，大神是那些工作中不介意遇到糟糕代碼的人。

程序員分類

回到我們的行業(yè)。我們可以以以下方式對我們的行業(yè)的程序員進(jìn)行分類，天才，良好，一般，差和糟糕。讓我們看看每一個的特點(diǎn)。

天才程序員

天才程序員寫的代碼庫很簡單，可重復(fù)使用，且功能強(qiáng)大。他們堅(jiān)持不懈，持續(xù)發(fā)展，對代碼庫進(jìn)行小而有規(guī)律的改進(jìn)，添加新的功能。他們寫了足夠多的相關(guān)測試。他們往往很謙虛，知識淵博。他們也不完美，經(jīng)常要從頭開始重寫整個庫。但他們能寫出更好的代碼，而不破壞兼容性。

良好程序員

良好開發(fā)人員寫代碼庫比較復(fù)雜。通常他們留下了很多未完成的地方。因?yàn)樗麄儾粫谝粋€庫工作很長時間，很快他們就會開始做另一件新人興奮的事情了。他們寫的代碼庫很快變得陳舊，沒有人知道如何操作它，而測試它則需要寫太多的代碼。良好開發(fā)人員對自己和自己的工作感到自豪，但是他們的代碼不能重寫，因?yàn)檫@些代碼寫得沒那么好，缺乏測試機(jī)制。

一般程序員

一般的程序員通常不計(jì)一切代價(jià)解決錯誤，砍掉新功能。如果測試中斷，他們只需禁用測試，因?yàn)榻桓洞a的時間到了。他們也不喜歡與那些良好的開發(fā)人員工作，因?yàn)檫@些人會留下存在依賴關(guān)系的抽象概念和代碼庫。這些東西用起來很不方便，而且有很多錯誤，還沒有文件記錄。

較差程序員

較差的程序員不關(guān)心任何東西。他們只會工作，寫代碼，回家，然后重復(fù)這一過程。他們永遠(yuǎn)不會學(xué)習(xí)，他們不聽取別人意見。即使告訴他什么是好的代碼，什么事糟糕的代碼，他們也不能分辨出來。他們不應(yīng)該成為程序員，一般也不會一直做程序員。

糟糕程序員

糟糕的程序員沒有比較差的程序員那么糟糕，因?yàn)樗麄兒退麄冎車娜硕贾酪庾R到他們沒有經(jīng)驗(yàn)，代碼寫得不是很好。所以他們想學(xué)習(xí)，渴望成為更好的程序員。他們也往往會過渡成為良好的程序員，但有的也會變成比較差的程序員。糟糕是一個短暫的階段，沒有什么可以擔(dān)心的。

神話六：程序員比例

這給我們帶來了下一個神話。如果我們問程序員，他們屬于哪一類。如果他們沒看過這些類別的定義，那么我們將得到這樣一個結(jié)果，60% 的程序員認(rèn)為自己是屬于天才和良好類，只有 30% 左右的人認(rèn)為他們是一般的程序員。

但依我的經(jīng)驗(yàn)，統(tǒng)計(jì)數(shù)字應(yīng)該是這樣的。極少數(shù)的是天才程序員，有一小部分的良好的程序員，大量的程序員屬于一般、較差的程序員。好好思考一下吧。

神話七：我可以做到！

所以，當(dāng)天才程序員向我們展示其簡單而卓越的杰作，有著漂亮的設(shè)計(jì)，簡潔的抽象，簡單易用……我們就認(rèn)為“我可以做到”。在希臘語中，Primus Inter Paris 意思是第一名也是平凡人。這種觀點(diǎn)認(rèn)為真正優(yōu)秀的人仍然只是我們中的一員，沒有什么不同，我們都可以做到。

當(dāng)我們看到別人寫的漂亮代碼，覺得很稀松平常。但我們這些普通人太愚蠢了，看不到自身的局限性。我們知道最漂亮的代碼長什么樣，知道這是如何使用，但這并不意味著我們可以自己寫出這種代碼。虛幻的優(yōu)越感和達(dá)克效應(yīng)分支理論告訴我們，我們太愚蠢了，卻不知道我們是多么愚蠢。我們對自己的能力有信心，寫了那些在正常情況下幾乎不能運(yùn)行的復(fù)雜軟件，這些軟件即使在特殊情況下也無法運(yùn)行。

所以……

請跟我說，我太愚蠢了，我寫不出好代碼。所有人，現(xiàn)在，說出來……

這就是房間里的大象。

這有什么問題嗎？

當(dāng)然有問題。首先，是經(jīng)濟(jì)上的問題。

招更多的程序員，花費(fèi)是更昂貴的。招更多的人參與寫一個代碼庫，會使代碼庫變得混亂。銀行有大量的程序員，只是為了保持程序可以運(yùn)行。要改變代碼庫，這個過程是緩慢的。

如果我們看看所謂的互聯(lián)網(wǎng)公司…這些人在做什么？互聯(lián)網(wǎng)的效率是減少需要的人的數(shù)量。

其次，當(dāng)前形勢有社會影響。

不快樂的程序員傾向于改變工作。我想說明，大多數(shù)情況下，新來的人會使情況變得更糟。另一個惡性循環(huán)，是這種情況像滾雪球越滾越大。我們應(yīng)該對自己的工作感到滿意。當(dāng)我們?nèi)ド习鄷r，應(yīng)該感到高興。員工高流動率的另一個方面是，許多程序員為了逃避寫代碼，去了其他類型的工作崗位，如管理，業(yè)務(wù)分析師，甚至一些完全無關(guān)的專業(yè)崗位，因?yàn)樗麄冏龀绦騿T不快樂。這導(dǎo)致程序員崗位從業(yè)人員經(jīng)驗(yàn)不足，情況變得更糟。

這個演講內(nèi)容非常消極，甚至對許多人來說是個的人身攻擊。但是有什么解決辦法嗎？我想會有解決辦法，但是是在遙遠(yuǎn)的未來。一些天才會想出軟件開發(fā)的新模式。我希望它是從根本上不同于我們現(xiàn)在的模式，類似于十八世紀(jì)將蒸汽機(jī)的引進(jìn)礦業(yè)的發(fā)展。也許人工智能可以用一個完全不同的方法來寫軟件，從而讓我們停止寫糟糕代碼。誰知道呢？在那發(fā)生之前，我想我們都停留在了計(jì)算的青銅時代。用手寫代碼寫出每一個細(xì)節(jié)，但沒有創(chuàng)造出可以傳承知識，所以我們無法提高集體技能。

解決方法是什么？

我想給你這個建議。

接吻原理—— 保持簡單，直接（The KISS principle - Keep It Simple, Stupid.）。

當(dāng)你寫代碼時，記住這是一件事。不要做額外的抽象。避免概括。避免繼承（inheritance）。不要寫你認(rèn)為你將來可能需要的代碼。當(dāng)沒有更多的代碼可刪除，那么工作就完成了。

即使你正在工作的代碼真的很混亂，很糟糕，請不要讓這種情況變得更糟。

即使代碼很糟糕，如果你改善一點(diǎn)點(diǎn)，就會變好一點(diǎn)點(diǎn)。如果每個人都一點(diǎn)點(diǎn)，最終代碼會變好很多。還有，不要讓你的隊(duì)友讓把代碼搞得更糟糕！