程式設計師的天才神話

   自從軟體開發中的社交危機問題以書籍形式出現後，將關注焦點聚集於一個可變因素之上成為了可能，這個可變因素便是——人。

   人類天生就不是完美的。但你在瞭解到同事的缺點之前，需要先了解自身的問題。請你思考自己的行為舉止和態度。而作為回報，我們希望你可以獲得一些真正有用的在如何成為一名高效成功的軟體工程師的問題上的洞察力。你將在與他人就某一問題達成協議上花費更少的精力，而省下更多的時間創作優秀的程式碼。

   本章的重點是要理解，軟體開發是一項團隊活動。為了在工程團隊的基礎上完成目標，你需要改變受自身人格核心原則影響而產生的行為、尊重，和信任。

   在開始之前，先讓我們看看程式設計師在一般情況下的行為舉止。

幫我隱藏我的程式碼

   在過去6年間的開發大會上，我們兩人已經做過很多很多的演講。自從我們在2006年作為最初隊伍的一部分接手谷歌開源專案託管服務以來，我們收到了大量的關於產品的提問和請求。將時間調回2008年中，我們在一堆請求中注意到了一個與眾不同的趨勢。以下是我們得到的：

    - 你們有能力給出Google Code上的Subversion的詳細分支嗎？

    - 你們是否可以在建立專案並開始之前將其隱藏，直到開發完後再公佈於世呢？

    - 嗨，我想重寫草稿上的全部程式碼，你們可以清除掉所有的歷史記錄嗎？

   你可以發現這些請求的共同之處嗎？

   這裡的關鍵動機在於，不安全性。人們害怕他人在日常生活中看到並且評論自己的工作。從一方面講，這是一種人類天性——沒有人喜歡被批評，特別是在工作正在進行，尚未結束的時候。這種態度將我們推到了軟體開發的風口浪尖。不安全性從根本上講，是一個大問題的症狀表現。

天才的神話

   首先，我們需要明白一件事：我們並不是真正的體育運動粉。每當我們的妻子為電視上的籃球或橄欖球比賽而歡呼尖叫時，我們都撓頭苦思是什麼讓她們如此興奮。不過，我們確實經歷了20實際90年代初期，並親眼目睹了芝加哥公牛隊（這是一支籃球隊）奪冠。這段時間我們正好在芝加哥，全國的媒體（national media）對這支夢之隊的故事跟蹤報導了好幾年。

   我們在報紙和電視上聽到最多的是什麼？不是公牛隊這支球隊，而是Michael Jordan，那個超級球星。世界上所有的球員都希望成為下一個Michael Jordan。我們看到他繞著其他球員跳舞；我們看到了他電視上的商業廣告；我們觀看的一部他和一群卡通人物打籃球的電影（迪士尼1996年拍攝，空中大灌籃）。他是明星，每一條街區的每一個孩子都在私下裡練習投籃，希望跟著他的腳步成長。

   程式設計師有著同樣的天性——尋找偶像，崇拜偶像。Linus Torvalds，Richard Stallman，Bill Gates——所有的用豐功偉績改變了世界的傳奇人物都在其列。Linus獨立開發了Linux作業系統嗎？

當心出於本能的極端崇拜。

   事實上，Linus只是寫出了類Unix核心程式碼，並且將其發到郵箱列表中。這不是一個小小的任務分配，而絕對是一個令人欽佩的壯舉。但這只是冰山一角。Linux系統的全部程式碼量是Linus貢獻程式碼量的數百倍，由數百天才共同開發。Linus的真正成就是領導並協調眾人的工作。Linux是他們集體勞動的耀眼成果（順便說一句，Unix系統是由在貝爾實驗室的一個天才小組開發，而不是僅由Ken Thompson和Dennis Richie兩人創作）。

   同樣的，Stallman單獨開發了基於自由軟體標準的軟體嗎？他的確單獨完成了Emacs的初代版本。但其他數百名程式設計師認真負責地完成了bash、GCC工具鏈，以及所有執行在Linux下的支援軟體。Steve Jobs領導了一整支團隊構建Macintosh（蘋果麥金塔電腦）。當人們瞭解到Bill Gates為早期的家庭計算機寫了一個BASIC直譯器的時候，他已完成了更大的成就，基於MS-DOS創辦了一家成功的公司。最終他們都依靠出色的合作能力成為了領導者和領軍人物。

   而Michael Jordan呢？

   我們極端地崇拜他。但事實卻是，他並沒有靠自己贏過一場球賽。他真正的天賦其實是與他的團隊共事。球隊教練Phil Jackson非常智慧——他的指導戰術富有傳奇色彩：他把每一個從未贏過冠軍的球員重組在一起，並一MJ為中心將他們稱為“夢之隊”。球隊就像是一部上好油的機器，每個人都像MJ一樣為自己感到驕傲。

   那麼為什麼我們要反覆崇拜這些故事中的個人？為什麼大眾會買那些帶有名人簽名的產品？為什麼我們會想要購買與Michelle Obama所穿同款的裙子或Michael Jordan的同款戰靴？

   名人效應占原因的很大一部分。人類天性使然會尋找領導者或模範，並崇拜他們，嘗試模仿他們。我們都為了能受到鼓舞而需要英雄，在程式設計界也同樣如此。這種“技術大神”的現象幾乎成為神話。我們都希望寫出一些像Linux一樣可以改變世界的東西，或是設計下一個傑出的程式語言。

   內心深處我們都悄悄地希望自己是天才。終極極客幻想是被一種超棒的全新概念所衝擊。你在你的小角落中一呆便是幾周甚至幾月，為了一個點子的完美實現而拼命工作。然後你將自己的軟體“解放”到世界，讓人們為你的天才所震撼；讓同事們為你的聰明而驚訝。成群的人使用你的軟體。名望與財富自然而然地隨之而來。

   但請稍等，讓我們認清現實，你也許並不是一個天才。

   無意冒犯，當然——我們肯定你是一個聰明的傢伙。但你是否真正意識的到現實中的天才是怎樣的嗎？當然，你會寫程式碼，這是一項富有訣竅的技術，可以歸到超越大多數人的一類中去。但這還不足以將你劃為天才。天才也會失誤，即便擁有精英級的程式設計技術也無法保證你的軟體會一次成功。可以成就或毀掉你的事業的，是你能多好地與他人合作。

   你會發現，天才神話正是造成我們不安全性的另一個放面。大多數程式設計師都害怕分享他們剛剛開始的工作，因為這意味著同事們會看到他們的失誤，發現程式碼的編寫者並不是一個天才。在此引用另一個程式設計師Ben的部落格：

   我知道在人們完成工作之前我會嚴肅地審視他們，就像他們會認真評論我並且認為我是一個蠢貨一樣。

   這在程式設計師中是一個非常普通的感覺自然的反應是低調隱藏自己，然後工作，工作，再工作！沒有人會看到你的粗心大意。你仍有機會在完成之時將你的傑作公之於眾。隱藏它們，直到你將之完善到極致。

   另一種“將卡緊緊護在胸前”的一般動機是擔心另一個程式設計師會拿走你的創意並且先你一步付諸行動。你將其重重保護加密，從而控制創意不會外洩。

   我們大概知道你現在在想什麼了：那又如何？難道人們不應該被允許隨心所欲地工作嗎？

   事實上，這是不被允許的。在這件事上，我們斷言你是錯的，並且是大錯。接下來我們會給出理由。

隱藏是有害的

   如果你所有時間都在單獨工作，那麼你是在增加失敗的風險，欺騙你的成長可能性。

   首先，你如何知道自己是在正確的軌道上？

   想象你是一個自行車設計的骨灰粉，有一天你想到一個絕妙的方法去用一種全新的方式設計齒輪變速器。你收集零件，開始把自己關在車庫連續幾個星期試著做出一個原型。當你的鄰居——同樣是一個自行車愛好者，詢問你最近怎麼樣時，你決定不談論關於創意的事情。在完成作品之前，你不希望被任何人知道專案的存在。又幾個月過去，你在讓原型機正確執行上出現了麻煩。但由於你的祕密工作，向你擅長機械的朋友請教是不可能的了。

   後來的某天，你的鄰居從他的車庫中推出了一輛帶有全新齒輪變速器的自行車。原來他前段時間也在做一個和你的創意非常相似的玩意兒，只不過他是在一群車行朋友的幫助下完成的。這點使你非常惱怒，你向他展示了你的工作。他指出了你設計上的幾處簡單的缺陷——那些問題本可以在第一週就能得到完善的，如果你當時可以展示給他的話。

與世隔絕的工作常常通向失望。

   相似的教訓數不勝數。如果你堅持把好的創意隱藏起來並拒絕向任何人展示，直到完美實現為止，那麼你是在進行一場豪賭。在早期很容易犯一些基礎的設計錯誤。你冒著巨大的風險，並且失去了合作帶來的好處：注意到你的鄰居與他人合作工作帶來的快速高效了嗎？這就是為什麼人們在下到深水前會先探入腳趾：你需要確認自己在做正確的事，按著正確的方式，並且以前從未做過。早期的失誤機率是很高的。越早尋求幫助，越早降低風險。（注：我們應該瞭解，有時候在前期獲得太多的幫助是危險的，我們會在後續章節中解釋。）記住一句經過了實踐檢驗的名言：“越挫越勇，永不言敗！（Fail early,fail fast,fail often）”——我們將在本書的後面討論失敗的價值。

   早期的分享不僅代表了預防個人失誤以及審視創意，同樣重要的還有強化了專案中一種我們稱之為“Bus factor”的因素。

Bus factor（名詞）：在專案完全確定之前需要核對的參與人數。

你團隊的Bus factor是多少？

  你的專案為多少人所知？如果你是唯一一個理解原型程式碼運作的人，這可能對工作的保密性有好處，但也意味著一旦遇到困難，專案會被迫停止。如果你與你的一個朋友一起工作，那麼的專案擁有雙份Bus factor。如果你有一個小型團隊一起設計製作產品原型，事情會變得更好——專案不會因為一個團隊成員的離開而終止。牢記一點：團隊成員不會每個人逐個被公交命中，但生活中其他不可預知的事情仍會發生。他們中的某一個也許結婚了；或者被迫離開團隊，離開公司；或需要照顧生病的親友。你需要設法管理團隊Bus factor以促使專案的完成。

   在Bus factor的另一邊，是專案每一步進展的問題。人們很容易忘記獨立工作的艱辛及遠低於公認水平的速度。從獨立開發中你學到了多少？網路是獲取建議和資訊的極好的平臺，但這不能代替人類的真實經驗。與他人共事可以直接增加努力產生的的集體智慧。當你被某個荒謬的事困住時，浪費了多少時間使自己擺脫困境？設想有一些同事在身後第一時間告訴你你是呆瓜，以及如何能解決問題所帶來的經歷的不同之處。這真正是軟體工程公司中團隊協同開發（或結對程式設計）的原因所在：你會經常發現自己需要另一雙眼睛。

   另一個類比。思考一下你是如何使用編譯器的。當你坐下來寫下一個很大的軟體時，是否是花費數天或數週編寫程式碼，在感到自己已完美完成工作後第一時間按下編譯按鈕的情形？當然不是了。你能想象到有多少不幸需要重建，嘗試編譯50,000行初始程式碼的景象嗎？作為最好的程式設計師之一的我們反覆貫徹著：寫一個新的物件，編譯；新增一組測試，編譯；重寫一些程式碼，編譯。在產生新的程式碼後我們會盡快修復錯誤和漏洞。我們希望編譯器可以每一時刻都在身邊，就像僚機一樣（空戰中掩護隊友的戰機）；希望一些環境可以如我們設計的那樣穩定編譯我們的程式碼。這正是我們保持程式碼優質及軟體可以正確執行每一位元的方法。

   另外同樣需要反覆貫徹的幾點不僅僅是使用在程式碼方面，而是貫通了整個專案。目標遠大的專案都是進展迅速並且不得不接受專案所需的環境。專案陷入了不可預測的設計困境，或是黨派紛爭，或僅僅是簡單地發現專案並沒有按照計劃執行。軟體需求是變化的。你是如何得到反饋環節從而可以立刻得知你的設計或計劃需要改變的？答案是：**團隊**。Eric Steven Raymond經常引用一句話，“眾人使漏洞無處藏身。”（Many eyes make all bugs shallow.1999年出版文集《大教堂和市集》首次描述）但更好的版本是：“眾人使你的專案正常執行。”（Many eyes make sure your project stays relevant and on track.）井底之蛙，焉知世界之大。

工程師與辦公室

   在20年前，傳統觀點規定：一個富有成效的工程師應該擁有屬於自己的獨立辦公室。這可能是唯一的方法來保證她可以有大量連續不被打斷的時間專注於編寫大量程式碼了。

   我們認為，對於大多數工程師來說，一間獨立辦公室不僅是多餘的，更是危險的。（我們當然承認嚴肅的內向型人格者應該會比大部分人需要更安靜、獨立的環境，並且得益於此。）今天，軟體是由團隊開發，而不是個人；並且團隊工作的高效和隊員間溝通的高效可比你的網路連線有價值多了（在一個關著門的獨立房間，能與外界交流的，也就電話和網路了吧^_^）。你可以支配每一分有效時間，但如果將其用在了錯誤的事情上，就是在浪費生命。走進21世紀一家高速發展的高科技公司的辦公室，你會看到成群的工程師聚集在一個用來分享的小房間（shared-cubicles，又稱："bullpens"）或者圓桌區域（desk area）。你很少能看到他們把自己鎖在辦公室、疏遠彼此的情形。

   當然了，你也需要一些方法過濾掉噪音和干擾。這也是為什麼我們會看到很多團隊都做出了規定，用以在團隊忙碌的時候不會干擾到工作。我們曾使用過一條聲音干擾協議：如果你想開口，你要說：“斷點XX”（breakpoint Mary），XX就是你要說話的物件。如果XX在可以停下手頭工作的點上，他會轉動椅子聽你說。如果XX太忙了，他只會說：“確認”（ack），這時你就該繼續其他的事情直到XX完成手上的頭等要事。

   其他的團隊向工程師們釋出了噪音消除聽筒，使其可以更簡單地幹掉區域內的噪音。事實上，在許多公司穿戴上聽筒是一個通用的訊號，這表示“除非是非常重要的事情，否則不要打擾我。”更有一些其他團隊的成員使用一些動物作為其螢幕背景來傳達“若非緊急，請勿打擾”的訊號。

   請不要誤解我們——我們仍然相信工程師需要大量不間斷的時間專注於程式碼編寫；但我們也相信他們需要一個團隊成員間高效率，低摩擦的連線。

   這些點歸結到一起就是：獨立工作固有的比團隊合作更具風險。當你害怕有人竊取你的創意或者認為你是呆瓜的時候，你更應該害怕浪費大量時間在錯誤的方向上揮汗如雨。

   悲劇的是，“看緊你的金庫”（clutching ideas to the chest）的問題不僅僅面向軟體工程一方面——這是一個貫穿整個領域的普遍問題。舉一個例子：專業科學理應是免費、開放的資訊交換。但是對“發表或滅亡”、對授權認可的爭奪的極度渴望實際上起到了相反的效果。優秀的創意者不分享他們的創意。他們過分堅持，祕密研究，將所有的錯誤隱藏在自己的小路上。然後在最後公佈一篇文章使整個過程聽起來輕鬆且平淡無奇。然而結果往往是災難性的：他們或是意外重蹈他人的覆轍；或是在早期犯下了一個未知的錯誤；亦或他們所做的是一個在以前曾閃亮一時，但現在被歸為無用的事情。那些浪費的時間和努力，真是悲劇。

  不要成為另一個樣本！

團隊！團隊！！團隊！！！

   讓我們將時間倒退，將所有想法放在一起。

   我們反覆強調一個重點，獨行俠是非常稀少的——即使在他們謀生時他們也不會完成超人般的業績；他們改變世界的任務幾乎總是團隊努力的靈感的邊角料。

   打造一個明星團隊是真正的目標，但這會非常非常困難。最好的團隊會最大化利用他們的高手，但整體總是優於部分的總和。換成一句簡單的話說，就是：

   軟體開發是團隊活動。

   在最初，這也許是一種很難理解的觀念，直到這種觀念直接粉碎了我們心中天才程式設計師的幻想。試著想頌歌一樣禱唸它。

記住：軟體開發是團隊的運動。

    一個人宅在自己的黑客小窩中是不足以成為高手的。隱藏準備自己的祕密發明是不會改變世界或是讓眾多計算機使用者感到高興的。你需要與他人合作，分享你的觀點，劃分工作，取人之長，補己之短，然後建立一個耀眼的團隊。

   思考一下：有多少被廣泛使用，由你命名的成功的軟體是實際由一個人獨立開發出來的？（很多人也許會說“LaTeX”，但這個軟體很難稱為“被廣泛使用”，除非你將那寫寫學術論文的認定為所有計算機使用者中在統計學上有重大意義的一部分。）

   我們很樂意在書中不厭其煩地重複這種“團隊運動”的觀念。高效的團隊是目標，也是通向成功的關鍵。你應該盡最大可能將這些經驗設為你的目標，這是本書的目的所在。