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

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

爛代碼是誰寫的？

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

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

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

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

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

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

我要說，這都是狗屁。那些都是借口，因?yàn)椴蝗晃覀円彩懿涣俗约哼@樣。我們?cè)趺茨苊髦霾缓霉ぷ鳎瑓s不感到羞恥，為什么不去換份工作呢？

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

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

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

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

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

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

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

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

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

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

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

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

神話一：軟件很容易修改

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

神話二：人多力量大

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

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

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

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

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

神話四：抽象概念很好

這是我的最愛的神話之一。如果不是這些抽象概念，我們不會(huì)有互聯(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 年代后期使用的是用例對(duì)象方法，然后是理性統(tǒng)一過程和許多其他所謂的計(jì)算機(jī)輔助軟件工程的方法，最后是統(tǒng)一建模語言 UML。Kent Beck 介紹了到極限編程方法，這是第一個(gè)敏捷方法，是一個(gè)反對(duì)瀑布式的方法。近 10 年間，Scrum，看板和其他方法備受吹捧。所有這些都方法都承諾解決軟件這一復(fù)雜工作。

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

程序員分類

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

天才程序員

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

良好程序員

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

一般程序員

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

較差程序員

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

糟糕程序員

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

神話六：程序員比例

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

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

神話七：我可以做到！

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

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

所以……

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

這就是房間里的大象。

這有什么問題嗎？

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

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

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

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

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

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

解決方法是什么？

我想給你這個(gè)建議。

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

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

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

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