《房间里的大象》来自Apache软件基金会副总裁Niclas Hedhman的分享
致謝：
《房间里的大象》是Apache软件基金会副总裁Niclas Hedhman在2016中国开源年会上做的演讲。
易軟天創的小夥伴參加了此次年會，聽了這個演講後，産生很多共鳴。
在征得了Niclas Hedhman先生的同意后，将此演讲使用的PPT翻译成中文，分享给大家。
在这里，再次向Niclas Hedhman先生表示感谢！
《房間裏的大象》PPT內容如下：
作者：Niclas Hedhman，翻译：滕菲。
大家好，我的名字是Niclas Hedhman。我是Apache Software Foundation长期贡献者。
作爲一個軟件開發人員，我已經工作了32年。多年來，我做了許多觀察。
最新的觀察是關于一件事，這件事是顯而易見，我們卻沒有注意過它。
“房間裏的大象”是英語中的一種表達，指的是那些沒有人敢談論卻又很明顯的事情。
這個演講，我想談談軟件行業裏沒有人敢談論的話題，但卻能把我們帶到另一個層次。
前面提到了我已經做了觀察。我們都會觀察。
幾乎每個人都看到過漂亮的代碼。這些代碼簡潔明了，而且很強大的。這種代碼易于理解，易于使用，易于擴展。我們可以很快地完成工作，把事情做好。
然而，如果我們問人們，他們是否在漂亮的代碼基礎上工作，大多數人說沒有。
那麽，這個代碼是從哪裏來的呢？
嗯，很少有開發人員能寫出這些漂亮的代碼。
另一方面，爛代碼隨處可見。
我們都見過爛代碼。
我們中有些人每天都要和爛代碼作鬥爭，我們都爲寫出更多的爛代碼而內疚。
但是爲什麽？爲什麽你要寫爛代碼？你知道這代碼很爛，你還要寫。爲什麽？這是爲什麽？
我們會聽到這樣的話，這代碼已經很爛了，我沒辦法改善，因爲沒法測試，因爲代碼太複雜，因爲做需要的改變太危險了。
我現在很忙。交付期限快到了，等有時間我們會解決這個問題的。現在，我們需要把握重點，把這個問題先擱一擱。
嘿，我覺得這代碼也沒有很爛。我的隊友們都很不高興，但我認爲他們不夠聰明，無法欣賞這代碼。
我要說，這都是狗屁。那些都是借口，因爲不然我們也受不了自己這樣。
我們怎麽能明知做不好工作，卻不感到羞恥，爲什麽不去換份工作呢？
我的推斷是，還有更加深層次的原因，是我們行業存在已久的危機。
我覺得這非常令人不安。
开源现在是一个公共领域，我们几乎不需要从头开始。我们在已有的平台上工作，以新的方式将已经存在的合起来，再加上自己的创新，就发布了这个産品，其他人可以再在这个基础上创造。这造成了产量以史无前例的速度加速产出。
有沒有人能告訴我這是什麽？
這是全世界程序員數的增長曲線。具體的數字不重要，盡管據估計人數在50-100萬之間。
重要的是，程序員人數在每5年左右就會翻一番。從1950以來，這種增加幾乎不間斷的。每5年，世界上的程序員的數量增加了一倍。
關于這種指數增長，我們能看出些什麽？有兩件事。好的是，這種增長不會永遠繼續下去。因爲地球上沒有這麽多人。壞的是，這些程序員中，有一半都工作經驗都不足五年。
實際情況可能更糟，因爲還有很多程序員將在未來在10-15年離開這個行業。
所以，我們行業非常缺乏經驗，而且一直缺乏經驗。
更糟糕的是，由于技術的大環境變化如此迅速，在一項技術過時之前，沒有足夠的時間來積累經驗，然後所有人又開始使用另一個技術了。
這導致同樣的錯誤是一次又一次的循環發生。
大多數程序員不會發明新技術供別人使用。我們使用熱門的技術。
我們相信，其他人已經知道何種技術適合我們。我們也不會動腦去思考。
我再說一遍，我們不會批判地思考，並且我們想信仰宗教信條一樣，相信別人告訴我該怎麽做，我就應該怎麽做。
讓我們來看看我們的行業的神話。這神話有很多。
由于我們的行爲像一個宗教教派，也産生了許多神話，有的是偶然，有的是刻意而爲。
神话是由特定的一类人创造和传播的。我们很容易受到我们所尊重的人所说的话的影响。供应商试图向我们出售産品和服务。同样，会议上的发言人，我们阅读书和博客的作者，他们是向我们卖他们的书，网站或服务。在工作中，我们听比我们更资深的人的话，这些人通常是那些有一些成绩的同事。但如果这是一个大公司，那么这些同事的话就会涉及办公室政治，或有为了赢得声望的因素，我们应该对这些人的话产生质疑。
讓我們看看業內典型的神話，那些所謂的常識。
神话一 软件很容易修改 我们生活在这样一个概念里，软件是....软的，灵活的。
打幾個字，我們就可以改變它，讓它做一些完全不同的事。
重新设计的电子産品需要几天的时间，而软件只需要几分钟。
但是，嘿…現實是很殘酷。它不是神話，而且會反擊。
大多數軟件不僅是難以改變，而且一旦用了就往往不能結束。
一旦寫好軟件，部署好，要想擺脫它，門都沒有，無論這軟件用起來多麽瑣碎或一無是處。
這種情況在公司管理中普遍存在。
如果我們需要多花一倍的精力做某件事，我們就多招一倍的程序員。
這肯定行。
《人月神话》（The Mythical Man-Month）是1975年出版的一本书。
40年前，作者Fred Brooks指出，增加人手到一个落后于计划进度的项目里，实际上会使项目进度变得更慢。
最終，花費在溝通所需的時間將比每個人有的時間加在一起還要多。
大公司的經理們的另一個最喜歡的神話就是是，程序員是可互換的零件。
如果一個程序員離開了，我們就從大街上找擇一個新的，代替他。
但是那根本行不通。軟件知識不在代碼裏，而存在于寫代碼人的大腦裏。
如果你以前搶修過別人的代碼庫，而這寫代碼的這個程序員沒有給你任何工作交接，你就知道我在說什麽了。
如果寫代碼庫的人離開了，則需要兩個新人來代替他，這兩人可能需要一年的時間來搞明白這個代碼庫的作者寫的到底是什麽，也有可能永遠都搞不清楚。
這是我的最愛的神話之一。
如果不是這些抽象概念，我們不會有互聯網，也沒有網上那些很棒的網站。
如果我們必須爲處理器寫二進制指令，就有麻煩了。
編程語言，協議，數據格式，框架，還有更多的抽象的概念幫助我們完成工作。
但大多數抽象概念都是在我們寫的程序中産生的。
我們創造出的抽象概念只是小聰明，概念不夠清晰。
我們也沒有很多創造抽象概念的經驗，所以我們創造出的是混亂。我們創造的抽象概念往往很糟糕，一片混亂，不利于項目的完成。
很多人兜售各種方法論。
20世紀80年代後期使用的是用例對象方法，然後是理性統一過程和許多其他所謂的計算機輔助軟件工程的方法，最後是統一建模語言UML。
Kent Beck介绍了到极限编程方法，这是第一个敏捷方法，是一个反对瀑布式的方法。
近10年間，Scrum，看板和其他方法備受吹捧。所有這些都方法都承諾解決軟件這一複雜工作。
我的觀察結果是，沒有一個方法像宣傳的那麽好。幾乎所有的軟件項目都依賴于大神。
能完成項目的人，無論用什麽方法，都能完成。對于新的項目，大神們擅長的是開始著手做。
在維護或改進代碼庫的時候，大神是那些工作中不介意遇到糟糕代碼的人。
回到我們的行業。
我們可以以以下方式對我們的行業的程序員進行分類，天才，良好，一般，差和糟糕。
讓我們看看每一個的特點。
天才程序員寫的代碼庫很簡單，可重複使用，且功能強大。
他們堅持不懈，持續發展，對代碼庫進行小而有規律的改進，添加新的功能。
他們寫了足夠多的相關測試。他們往往很謙虛，知識淵博。
他們也不完美，經常要從頭開始重寫整個庫。但他們能寫出更好的代碼，而不破壞兼容性。
良好開發人員寫代碼庫比較複雜。
通常他們留下了很多未完成的地方。因爲他們不會在一個庫工作很長時間，很快他們就會開始做另一件新人興奮的事情了。
他們寫的代碼庫很快變得陳舊，沒有人知道如何操作它，而測試它則需要寫太多的代碼。
良好開發人員對自己和自己的工作感到自豪，但是他們的代碼不能重寫，因爲這些代碼寫得沒那麽好，缺乏測試機制。
一般的程序員通常是大公司的維護軟件的大神。
他們不計一切代價解決錯誤，砍掉新功能。如果測試中斷，他們只需禁用測試，因爲交付代碼的時間到了。
他們也不喜歡與那些良好的開發人員工作，因爲這些人會留下存在依賴關系的抽象概念和代碼庫。
這些東西用起來很不方便，而且有很多錯誤，還沒有文件記錄。
較差的程序員不關心任何東西。他們只會工作，寫代碼，回家，然後重複這一過程。
他們永遠不會學習，他們不聽取別人意見。即使告訴他什麽是好的代碼，什麽事糟糕的代碼，他們也不能分辨出來。
他們不應該成爲程序員，一般也不會一直做程序員。
糟糕的程序員沒有比較差的程序員那麽糟糕，因爲他們和他們周圍的人都知道意識到他們沒有經驗的，代碼寫的不是很好。所以他們想學習，渴望成爲更好的程序員。他們也往往會過渡成爲良好的程序員，但有的也會變成比較差的程序員。糟糕是一個短暫的階段，沒有什麽可以擔心的。
這給我們帶來了下一個神話。
如果我們問程序員，他們屬于哪一類。
如果他們沒看過這些類別的定義，那麽我們將得到這樣一個結果，60%的程序員認爲自己是屬于天才和良好類，只有30%左右的人認爲他們是一般的程序員。
但依我的經驗，統計數字應該是這樣的。
極少數的是天才程序員，有一小部分的良好的程序員，大量的程序員屬于一般、較差的程序員。好好思考一下吧。
所以，當天才程序員向我們展示其簡單而卓越的傑作，有著漂亮的設計，簡潔的抽象，簡單易用……
我們就認爲“我可以做到”。
在希腊语中，Primus Inter Paris意思是第一名也是平凡人。
這種觀點認爲真正優秀的人仍然只是我們中的一員，沒有什麽不同，我們都可以做到。
當我們看到別人寫的漂亮代碼，覺得很稀松平常。
但我們這些普通人太愚蠢了，看不到自身的局限性。我們知道最漂亮的代碼長什麽樣，知道這是如何使用，但這並不意味著我們可以自己寫出這種代碼。
虛幻的優越感和達克效應分支理論告訴我們，我們太愚蠢了，卻不知道我們是多麽愚蠢。
我們對自己的能力有信心，寫了那些在正常情況下幾乎不能運行的複雜軟件，這些軟件即使在特殊情況下也無法運行。
我太愚蠢了，我寫不出好代碼。
所有人，現在，說出來……
這就是房間裏的大象。
當然有問題。首先，是經濟上的問題。
招更多的程序員，花費是更昂貴的。
招更多的人參與寫一個代碼庫，會使代碼庫變得混亂。
銀行有大量的程序員，只是爲了保持程序可以運行。要改變代碼庫，這個過程是緩慢的。
如果我們看看所謂的互聯網公司…這些人在做什麽？互聯網的效率是減少需要的人的數量。
其次，當前形勢有社會影響。
不快樂的程序員傾向于改變工作。
我想說明，大多數情況下，新來的人會使情況變得更糟。
另一個惡性循環，是這種情況像滾雪球越滾越大。我們應該對自己的工作感到滿意。當我們去上班時，應該感到高興。
員工高流動率的另一個方面是，許多程序員爲了逃避寫代碼，去了其他類型的工作崗位，如管理，業務分析師，甚至一些完全無關的專業崗位，因爲他們做程序員不快樂。
這導致程序員崗位從業人員經驗不足，情況變得更糟。
這個演講內容非常消極，甚至對許多人來說是個的人身攻擊。但是有什麽解決辦法嗎？我想會有解決辦法，但是是在遙遠的未來。
一些天才會想出軟件開發的新模式。我希望它是從根本上不同于我們現在的模式，類似于十八世紀將蒸汽機的引進礦業的發展。
也許人工智能可以用一個完全不同的方法來寫軟件，從而讓我們停止寫糟糕代碼。誰知道呢？在那發生之前，我想我們都停留在了計算的青銅時代。
用手寫代碼寫出每一個細節，但沒有創造出可以傳承知識，所以我們無法提高集體技能。
我想給你這個建議。
接吻原理-保持简单，直接（The KISS principle - Keep It Simple, Stupid.）。
當你寫代碼時，記住這是一件事。不要做額外的抽象。避免概括。避免繼承（inheritance）。
不要寫你認爲你將來可能需要的代碼。當沒有更多的代碼可刪除，那麽工作就完成了。
即使你正在工作的代碼真的很混亂，很糟糕，請不要讓這種情況變得更糟。
即使代碼很糟糕，如果你改善一點點，就會變好一點點。如果每個人都一點點，最終代碼會變好很多。還有，不要讓你的隊友讓把代碼搞得更糟糕！。
