《程式員修煉之道》——第一章 注重實效的哲學

　　注重實效的程式員的特征是什麼？我們覺得是他們處理問題、尋求解決方案時的态度、風格、哲學。他們能夠越出直接問題去思考，總是設法把問題放在更大的語境中，總是設法注意更大的圖景。畢竟，沒有這樣的更大的語境，你又怎能注重實效？你又怎能做出明智的妥協和有見識的決策？

注重實效的程式員有這樣幾個特征：

　　（1）負責。（“我的源碼讓貓吃了”，“軟體的熵”）。

　　（2）不斷接受變化

　　（3）謹慎的權衡各種利弊。

　　（4）不斷學習。

　　（5）多交流。 

一、 我的源碼讓貓吃了（負責）

　　1. 在所有的弱點中，最大的弱點就是害怕暴露弱點。——J.B Bossuet, Politics from Holy Writ, 1709

　　2. （1）充分分析每項任務的風險，不能做到的事情不負責。一旦接受任務，就要負責到底。對可能存在的風險，要有相應的預案。比如代碼丢失就完全屬于自己的錯誤。

　　　 （2）錯誤總會發生，不要害怕自己的無知，要勇于承認自己的錯誤。當犯錯時，不要責備别人或拼湊借口，不要把問題歸咎于程式設計語言、管理部門、或是你的同僚。應該冷靜思考各種解決方案。

　　　 （3）不要着急尋求幫助，在告訴别人壞消息之前，應該自己思考還有沒有試過其他的解決方案。實在無法解決時，再求助他人。

　　　 （4）不要說事情做不到，要能說明能夠做什麼來挽回局面。不要害怕提出要求，也不要害怕承認你需要幫助。

二、軟體的熵（負責）

　　　1. 不要留着破窗戶，（低劣的設計、錯誤決策、或是糟糕的代碼）不修。發現一個就修一個。如果沒有足夠的時間進行适當的修理，就用木闆把它釘起來。或是你可以把問題的代碼放入注釋（comment out），或是顯示“未實作”消息，或是用虛設的資料（dummy data）加以替代。采取某種行動防止進一步的損壞，并說明情勢處在你的控制之下。

　　這的确是一個極端的事例，但我們必須以這樣的方式對待軟體。一扇破窗戶-----一段設計低劣的代碼、團隊必須在整個項目開發過程中加以忍受的一項糟糕的管理決策——就足以使項目開始衰敗。如果你發現自己在有好些破窗戶的項目裡工作，會很容易産生這樣的想法：“這些代碼的其餘部分也是垃圾，我隻要照着做就行了。”項目在這之前是否一直很好，并沒什麼關系。在最初得出“破窗戶理論”的一項試驗中，一輛廢棄的轎車放了一個星期，無人理睬。而一旦有一扇破窗戶被打破，數小時之内車上的裝置就被搶奪一空，車也被翻了個底朝天。

　　按照同樣的道理，如果你發現你所在的團隊和項目的代碼十分漂亮——編寫整潔、設計良好，并且很優雅——你就很可能會格外注意不去把它弄髒，就和那些消防員一樣。即使有人在咆哮（最後期限、釋出日期、會展示範，等等）你也不會想成為第一個弄髒東西的人。

三、石頭湯與煮青蛙（勇于接受變化）

　　在有些情況下，你也許确切地地知道需要做什麼，以及怎樣去做。整個系統就在你的眼前——你知道他是對的。但請求許可去處理整個事情，你會遇到拖延和漠然。大家要設立委員會，預算需要準許，事情會變得複雜化。每個人都會護衛他們自己的資源。有時候，這叫做“啟動雜役”(start-up fatigue)。

　　這正是拿出石頭的時候。設計出你可以合理要求的東西，好好開發它。一旦完成，就拿給大家看，讓他們大吃一驚。然後說：“要是我們增加....可能會更好。”假裝那并不重要。做回椅子上，等着他們開始要你增加你本來就想要的功能。人們發現，參與正在發生變化的成功要更容易。讓他們瞥見未來，你就能讓他們聚集在你周圍。

四、足夠好的軟體（軟體品質的權衡）

　　欲求更好，常把事情變糟。——李爾王 1.4

　　不要過度追求完美，要編寫足夠好的軟體——對你的使用者、對未來的維護者、對你自己内心的安甯來說足夠好。你會發現，你變得更多産，而你的使用者也會變得更加高興。你也許還會發現，因為“孵化期”更短，你的程式實際上更好了。

　　短語“足夠好”并非意味着不整潔或制作糟糕的代碼。所有系統都必須滿足其使用者的需求，才能取得成功。我們隻是在宣揚，應該給使用者以機會，讓他們參與決定你所制作的東西何時已足夠好。

　　讓你的使用者參與權衡，你所制作的系統的範圍和品質應該作為系統需求的一部分規定下來。　　

　　不要因為過度修飾和過于求精而損毀完好的程式。繼續前進，讓你的代碼憑着自己的品質站立一會兒。它也許并不完美，但不用擔心：它不可能完美。

五、你的知識資産（不斷學習）

　　知識上的投資總能得到最好的回報。——本傑明·富蘭克林

　　你的知識和經驗是你最重要的職業财富。遺憾的是，它們是有實效的資産（expiring asset)。随着新技術、語言環境的出現，你的知識會變的過時。不斷變化的市場驅動力也會使你的經驗變得陳舊或無關緊要。考慮到“網年”飛逝的速度，這樣的事情可能會非常快地發生。

　　随着你的知識的價值降低，對你的公司或客戶來說，你的價值也在降低。

你的知識資産

　　我們喜歡把程式員所知道的關于計算技術和他們所工作的應用領域的全部事實、以及他們的所有經驗視為他們的知識資産（Knowledge Portfolios)。管理知識資産與管理金融資産非常相似：

　　1. 嚴肅的投資者定期投資——作為習慣。

　　2. 多元化是長期投資的關鍵。

　　3. 聰明的投資者在保守的投資和高風險的、高回報的投資之間平衡他們的資産。

　　4. 投資者設法低買高賣，以擷取最大回報。

　　5. 應周期性地重新評估和平衡資産。

　　要在職業生涯中獲得成功，你必須運用同樣的指導方針管理你的知識資産。

　　經營你的資産

• 定期投資。就像金融投資一樣，你必須定期為你的知識資産投資。即使投資量很小，習慣自身也和總量一樣重要。
• 多元化。你知道的不同的事情越多，你就越有價值。作為底線，你需要知道你目前所有的特定技術的各種特性。但不要就此止步。計算技術的面貌變化很快——今天的熱門技術明天就可能變得近乎無用（或至少是不再搶手）。你掌握的技術越多，你就越能更好地進行調整，趕上變化。
• 管理風險。從高風險、可能有高回報，到低風險、低回報，技術存在于這樣一條譜帶上。把你所有的金錢都投入可能突然崩盤的高風險股票并不是一個好主意；你也不用太保守，錯過可能的機會。不要把你所有的技術雞蛋放在一個籃子裡。
• 低買高賣。在新興的技術流行之前學習它就和找到被低估的股票一樣困難，但所得到就和那樣的股票帶來的收益一樣。在Java剛出現時學習它可能有風險，但對于現在已步入該領域的頂尖行列的早期采用者，這樣做得到了非常大的回報。
• 重新評估和平衡。這是一個非常動蕩的行業。你上個月開始研究的熱門技術現在也許已像石頭一樣冰冷。也許你需要重溫你有一陣子沒有使用的資料庫技術。又或者，如果你之前試用過另一種語言，你就會有可能獲得那個職位。

　　目标

　　關于何時以及增加什麼到你的知識資産中，現在你已經擁有了一些指導方針，那麼什麼事獲得智力資本、進而為你的資産提供資金的最佳方式呢？這裡有一些建議。

• 每年至少學習一種新語言。不同語言以不同方式解決相同的問題。通過學習若幹不同的方法，可以幫助你拓寬你的思路，并避免墨守成規。
• 每季度閱讀一本技術書籍。書店裡擺滿了許多書籍，讨論與你目前的項目有關的有趣話題。一旦你養成習慣，就每個月讀一本書。在你掌握了你正在使用的技術之後，拓寬範圍，閱讀一些與你的項目無關的書籍。
• 也要閱讀非技術書籍。記住計算機是由人——你在設法滿足其需要的人——使用的，這十分重要。不要忘了等式中人這一邊。
• 上課。在本地的學院或大學、或是将要來臨的下一次會展上尋找有趣的課程。
• 參加本地使用者組織。不要隻是去聽講座，而要主動參與。與世隔絕對你的職業生涯來說可能是緻命的；打聽一下你們公司以外的人都在做什麼。
• 實驗不同的環境。如果你隻在Windows上工作，就在家玩一玩Unix（可以自由擷取的Linux更好）。如果你隻用過makefile和編輯器，就試一試IDE，反之亦然。
• 跟上潮流。訂閱商務雜志和其他期刊。選擇所涵蓋的書與你目前的項目不用的刊物。
• 上網。想要了解某種新語言或其他技術的各種特性？要了解其他人的相關經驗，了解他們所使用的特定行話，等等，新聞討論區是一種很好的方式。上網沖浪，查找論文、商業站點，以及其他任何你可以找到的資訊來源。

　　持續投入十分重要。一旦你熟悉了某種新語言或新技術，繼續前進。學習另一種。

　　是否在某個項目中使用這些技術，或者是否把它們放入你的履歷，這并不重要。學習的過程将擴充你的思維，使你向着新的可能性和新的做事方式拓展。思想的“異花授粉” （cross-pollination）将十分重要；設法把你學到的東西應用到你目前的項目中。即使你的項目沒有使用該技術，你或許也能借鑒一些想法。例如，了解面向對象，你就會用不同的方式寫純C程式。

　　學習的機會

　　于是你狼吞虎咽的閱讀，在你的領域，你站在了所有突破性進展的前沿（這并不是容易的事情）。有人想你請教一個問題，答案是什麼？你連最起碼的想法都沒有。你坦白承認了這一點。

　　不要就此止步，把找到答案視為對你個人的挑戰。去請教古魯。上網搜尋。去圖書館。

　　如果你自己找不到答案，就去找出能找到答案的人。不要把問題擱在那裡。與他人交談可以幫助你建立人際網絡，而因為在這個過程中找到了其他不相關問題的解決方案，你也許還會讓自己大吃一驚。就有的資産在不斷的增長。

　　所有的閱讀和研究都需要時間，而時間已經很短缺。是以你需要預先規劃。讓自己在空閑的片刻時間裡總有時間可讀。花在等醫生上的時間是抓緊閱讀的好機會——但一定要帶上你自己的雜志，否則，你也許會發現自己在翻閱1973年的一篇卷角的關于巴巴新幾內亞的文章。

　　批判的思考

　　最後一個要點是，批判地思考你讀到的和聽到的。你需要確定你的資産中的知識是準确的，并且沒有受到供應商或媒體炒作的影響。警惕聲稱他們的信條提供了唯一答案的狂熱者——那或許适用、或許不适用于你和你的項目。

　　不要低估商業主義的力量。Web搜尋引擎把某個頁面列到最前面，并不意味着那就是最佳選擇；内容供應商可以付錢讓自己排在前面。書店的顯著位置展示某一本書，也并不意味着那就是一本好書，甚至也不說明那是一本受歡迎的書；它們可能是付了錢才放在那裡的。

　　批判地分析你讀到的和聽到的。

　　和古魯打交道的禮節和教養

　　随着Internet在全球普及，古魯們突然變得像你的Enter鍵一樣貼近。那麼，你怎樣才能找到一個古魯，怎樣才能找一個古魯和你交談呢？

• 确切地知道你想要什麼，并盡量明确具體。
• 小心而得體地組織你的問題。記住你是在請求幫助；不要顯得好像是在要求對方回答。
• 組織好問題之後，停下來，再找找答案。選出一些關鍵字，搜尋Web。查找适當的FAQ
• 決定你是想公開提問還是私下提問。
• 坐回椅子上，耐心等候。人們很忙，也許需要幾天才能得到明确的答案。
• 最後，請一定要感謝任何回應你的人。如果你看到有人提出你能夠解答的問題，盡你的一份力，參與解答。

六、交流

 　　我相信，被打量比被忽略要好。——Mae West， Belle of the Nineties, 1934　　

　　也許我們可以從West女士那裡學到一點什麼。問題不隻是你有什麼，還要看你怎樣包裝它。除非你能夠與他人交流，否則就算你有最好的主意、最漂亮的代碼、或是最注重實效的想法，最終也會毫無結果。沒有有效的交流，一個好想法就隻是一個無人關心的孤兒。

　　最為開發者，我們必須在許多層面上進行交流。我們把許多小時花在開會、傾聽和交流上。我們與最終使用者一起工作，設法了解他們的需要。我們編寫代碼，與機器交流我們的意圖；把我們的想法變成文檔，留給以後的開發者。我們撰寫提案和備忘錄，用以申請資源并證明其正當性、報告我們的狀态以及提出各種新方法。我們每天在團隊中工作，宣揚我們的主意、修正現有的做法、并提出新的做法。我們的時間有很大一部分都花在交流上，我們需要把它做好。

　　我們彙總了我們覺得有用的一些想法。

　　

　　知道你要說什麼

　　在工作中使用的更為正式的交流方式中，最困難的部分也許是确切地弄清楚你想要什麼。小說家在開始寫作之前，會詳細地構思情節，而撰寫技術文檔的人卻常常樂于做到鍵盤前，鍵入“1. 介紹···”，并開始敲入接下來在他們的頭腦裡冒出來的任何東西。

　　規劃你想要說的東西。寫出大綱。然後問你自己：”這是否講清了我要說的所有内容？“提煉它，直到确實如此為止。

　　這個方法不隻适用于撰寫文檔。當你面臨重要會議、或是與重要客戶通電話時，簡略幾下你想要交流的想法，并準備幾種把它們講清楚的政策。

　　了解你的聽衆

　　隻有你是在傳達資訊時，你才是在交流。為此，你需要了解你的聽衆的需要、興趣、能力。我們都曾出席過這樣的會議：一個做開發的滑稽人物在發表長篇獨白，講述某種神秘技術的各種優點，把市場部副總裁弄得目光呆滞。這不是交流，而隻是空談，讓人厭煩的（annoying）空談。

　　要在你腦海裡形成一幅明确的關于你的聽衆的畫面。下面幾條建議可能會對你有幫助。

　　1. 你想讓他們學到什麼？　　What do you want them to learn?

　　2. 他們對你講的什麼感興趣？　　What is their interest in what you've got to say?

　　3. 他們有多富有經驗？　　How sophisticated are they?

　　4. 他們想要多少細節？　　How much detail do they want?

　　5. 你想要讓誰擁有這些資訊？　　Whom do you want to own the information？

　　6. 你如何促使他們聽你說話？　　How can you motivate them to listen to you?

　　假設你想提議開發一個基于Web的系統，用于讓你們的最終使用者送出bug報告。取決于聽衆的不同，你可以用不同的方式介紹這個系統。如果可以不用在電話上等候，每天24小時送出bug報告，最終使用者将會很高興。你們的市場部門可以利用這一事實促銷。支援部門的經理會以為兩個原因而高興：所需員工更少，問題報告得以自動化。最後，開發者會因為能獲得基于Web的客戶-伺服器技術和新資料庫引擎方面的經驗而感到享受。通過針對不同的人進行适當的修正，你将讓他們都為你的項目感到興奮。

　　選擇時機

　　這是星期五的下午六點，審計人員剛進駐已有一周。你的老闆最小的孩子在醫院裡，外面下着滂沱大雨，這時開車回家肯定是一場噩夢。這大概不是向她提出PC記憶體更新的好時候。

　　為了了解你的聽衆需要聽到什麼，你需要清除他們的“輕重緩急”是什麼。找到一個剛剛因為丢失源碼而遭到老闆批評的經理，向她介紹你關于源碼倉庫的構想，你将會擁有一個更容易接納的傾聽者。要讓你所說的适得其時，再内容上切實相關。有時候，隻要簡單地問一句”現在我們可以談談嗎？”就可以了。

　　選擇風格

　　調整你的交流風格，讓其适應你的聽衆。有人的是正式的"事實“簡報。另一些人喜歡在進入正題之前高談闊論一番。如果是書面文檔，則有人喜歡一大摞報告，而另一些人卻喜歡簡單的備忘錄或電子郵件。如果有疑問，就詢問對方。

　　但是，要記住，你也是交流事務的一方。如果有人說，他們需要你用一段話進行描述，而你覺得不用若幹頁紙就無法做到，如實告訴他們。記住，這樣的回報也是交流的一種形式。

　　讓文檔美觀

　　你的想法很重要。它們應該以美觀的方式傳遞給你的聽衆。

　　太多程式員（和他們的經理）在制作書面文檔時隻關心内容。我們認為這是一個錯誤。任何一個廚師都會告訴你，你可以在廚房裡忙碌幾個小時，最後卻因為飯菜糟糕的外觀而毀掉你的努力。

　　在今天，已經沒有任何借口制作出外觀糟糕的列印文檔。現代的字處理器（以及Latex和troff這樣的排版系統）能夠生成非常好的輸出。你隻需要學習一些基本的指令。如果你的字處理器支援樣式表，就加以利用。學習如何設定頁眉和頁腳。檢視你的軟體包中包含的樣本文檔，以對樣式和闆式有所了解。檢查拼寫，先自動，再手工。畢竟，有些拼寫錯誤是檢查器找不出來的。

　　讓聽衆參與

　　我們常常發現，與制作文檔的過程相比，我們制作出的文檔最後并沒有那麼重要。如果可能，讓你的讀者參與文檔的早期草稿制作。擷取他們的回報，并汲取他們的智慧。你将建立良好的工作關系，并很可能在此過程中制作出更好的文檔。

　　做傾聽者

　　如果你想要大家聽你說話，你必須使用一種方法：聽他們說話。即使你掌握着全部資訊，既使那是一個正式會議，你站在20個衣着正式的人面前——如果你不聽他們說話，他們也不會聽你說話。

　　鼓勵大家通過提問來交談，或是讓他們總結你告訴他們的東西。把會議變成對話，你将能更有效地闡明你的觀點。誰知道呢，你也許還能學到點什麼。

　　回複他人

　　如果你向别人提問，他們不做出回應，你會覺得他們不禮貌。但當别人給你發送電子郵件或備忘錄、請你提供資訊，或是采取某種行動時，你是否經常忘記回複？在匆忙的日常生活中，很容易忘記事情。你應該總是對電子郵件和語音郵件做出回應，即使内容隻是“我稍後回複你。”随時通知别人，會讓他們更容易原諒你偶然的疏忽，并讓他們覺得你沒有忘記他們。

　　你說什麼和你怎樣說同樣重要。

　　電子郵件交流

　　我們所說的關于書面交流的所有東西都同樣适用于電子郵件。現在的電子郵件已經發展成為公司内部和公司之間進行交流的主要手段。它被用于讨論合約、調解争端，以及用作法庭證據。但因為某種原因，許多從不會發出低劣的書面文檔的人卻樂于往全世界亂扔外觀糟糕的電子郵件。

　　我們關于電子郵件的提示很簡單：、

• 在你按下SEND之前進行校對。
• 檢查拼寫。
• 讓格式保持簡單。有人使用均衡字型閱讀電子郵件，是以你辛苦制作的ASCII藝術圖形在他們看來将像是母雞的腳印一樣亂七八糟。
• 隻在你知道對方能夠閱讀rich-text或HTML格式的郵件的情況下使用這些格式。純文字是通用的。
• 設法讓引文減至最少。沒有人喜歡收到一封回郵，其中有100行是他原來的電子郵件，隻在最後新添了三個字：“我同意”。
• 如果你引用别人的電子郵件，一定要注明出處。并在正文中進行引用（而不是當做附件）。
• 不要用言語攻擊别人，除非你想讓别人也攻擊你，并老是糾纏你。
• 在發送之前檢查你的收件人名單。最近《華爾街日報》上有一篇文章報道說，有一個雇員通過部門的電子郵件散布對老闆的不滿，卻沒有意識到老闆也在收件人名單裡
• 将你的電子郵件——你收到的重要檔案和你發送的郵件——加以組織并歸檔。

　　總結

• 知道你想要說什麼
• 了解你的聽衆
• 選擇時機
• 選擇風格 
• 讓文檔美觀
• 讓聽衆參與
• 做傾聽者
• 回複他人