編程大師訪談錄 讀書筆記

蓋茨

程序員能夠看看之前其餘人是怎麼作的，從其餘項目得到改進本身程序的想法和經驗。

我認爲大多數優秀的程序員都但願周圍有其餘優秀的程序員。當他們想出了一個很好的算法時，他們但願周圍有可以欣賞其絕妙之處的同事。由於你在構想那個算法、腦海中產生那樣一個模型時，那是個寂寞的事情。若是你原來覺得處理過程很複雜，但卻找到一個辦法，讓過程變得很簡單，那種感受好極了。不過你須要從其餘程序員那裏獲得一些反饋。若是已經有了幾個優秀的程序員，就會吸引更多優秀的程序員。

採訪者：你認爲開發優秀的程序有什麼特定規則嗎？蓋茨：有些人剛一進到項目中就開始坐下來編碼，而有些人則在編碼以前把全部的過程都想清楚，我認爲你會發現那些一開始就坐下來編碼的程序員只是在把那些代碼當作草稿使用。那些在他們頭腦中思考的內容纔是最重要的。

採訪者：通過多年的經驗積累後，編程是否必定會更容易呢？蓋茨：不，我認爲在過了最初的三四年後，就會很是明顯地顯現出你是不是一個優秀的程序員。剛開始的幾年中，你可能會更多地知道怎樣去管理大型項目和不一樣個性的人了。在微軟沒有哪一個程序員是在平庸了幾年以後忽然間一舉成名的。我和一我的談談他的程序，立刻就能知道他是不是個好程序員。若是他真的很棒，每一個細節他都會脫口而出。就像下棋的人同樣。若是你特別喜歡下棋，會很容易記住10盤棋中的每一步，由於你已置身其中了。其餘人看到國際象棋選手或程序員能記住每一個細節時，以爲他們像個怪物。其實這很正常。即便到了今天，在我寫了微軟的BASIC程序10年後，我仍能夠在黑板上大段大段寫出當時的源代碼。

編程須要很是大量的精力，因此大多數程序員都比較年輕。這就會帶來一個問題，由於編程須要不少的訓練。在年輕時，目標不是很持久，可能會被這樣那樣的事分心。可是年輕的程序員應當堅持下去，他們會變得更出色。

佩奇

佩奇：你必須瞭解客戶，瞭解計算機，爲客戶和計算機設計出最優秀的產品，除此以外，就沒有什麼基本原則了。你必須瞭解客戶，知道他們想要什麼。這樣才能爲他們設計出合適的產品。產品多是一個很簡單的程序，好比PFS:FILE，也多是一個極其複雜的程序，好比編譯器。前者是爲普通用戶設計的，後者是爲程序員或工程師設計的。我不會容忍一個軟件工程師只想作複雜的程序設計。首先，我認爲這樣的態度不夠成熟。一個好的建築師無論是設計一個小涼亭仍是設計一個大博物館，都能從中獲得快樂，它們各有各的挑戰。 第二，我認爲真正的挑戰是如何設計出一個外表簡單而內部複雜的軟件。我對那些不喜歡這種挑戰的人感到困惑，由於這種挑戰對我來講很是有趣。

萊特萊夫

採訪者：你能不能再詳細說說這種平衡和優雅的感受？萊特萊夫：平衡有不少種形式。代碼應當乾脆精煉。你應當能夠用一句話解釋任何一個模塊。若是可能，內容應當按字母順序排列。僅從視覺角度講，代碼不該當在任何地方掉出打印紙的邊緣。不該當有一個很大的「if」，而「else」卻很小。一切東西在任何地方都應當平衡。平衡是這裏的關鍵字。

我寫程序老是力爭把代碼寫得穩固、清晰、乾淨，哪怕是須要額外多寫五行。 我通常認爲，你須要寫的註釋越多，你的程序就越糟糕，確定是哪裏出了什麼問題了。好的程序並不須要不少的註釋。程序自己就應該是註釋。

弗蘭克斯頓

採訪者：即便這樣，目前大部分編程工做仍是由一小部分人完成的。是什麼因素決定一我的能成爲一名優秀的程序員，而不是衆多用戶中的一員？弗蘭克斯頓：什麼因素令人在某一方面出類拔萃？是什麼因素讓人成爲優秀的做家？優秀的人通常須要知足兩個因素：正好具有這個知識領域所須要的心智，而且在能力上又不是太愚鈍。這樣的組合很罕見，但並不是難以想象。

採訪者：你在程序中會寫不少註釋嗎？弗蘭克斯頓：那要看我以爲代碼是否易於理解。**程序語言越高級，我寫的註釋就越少。**我盡力編寫可讀性好的代碼。在編程語言中，我只使用有意義的常規用語，若是我以爲一段代碼不是很容易讀懂，就會寫上註釋。

採訪者：你對年輕程序員的忠告是什麼？弗蘭克斯頓：總的來講，不要覺得你知道全部的東西，要嘗試學習並質疑那些假定的東西。要信心十足，但要保持謙虛，要猜測你可能作錯了什麼。要有恰好夠多的罪惡感——不要太多，否則就會懼怕去作任何事情——但要足以創建美感。嘗試去作更深入的理解。不要由於你曾使它運行成功了，就覺得再也沒有什麼須要去了解的了。

採訪者：是什麼讓人成爲好的程序員？關鍵是天賦仍是培訓？薩奇：是天賦、氣質、動機和努力工做的結合。我知道有不少人指望在很短的時間就成爲一名好的程序員，但能成功作到這一點的人並很少。成功來自一遍又一遍地作一樣的事情，每一次學習一點點，下一次都作得更好一點。

薩奇

有些人很擅長優化每一步指令。他們可讓一小段代碼變得極爲緊湊。而另外一些人只注重算法和實現過程。我介於這二者之間。我不是很擅長很是緊湊地壓縮代碼。多年前我就發現，若是那樣編程的話，每次須要修改代碼時，都必須拆開整個程序並重寫一遍。但若是稍退一步，只在很是重要的幾個點上讓代碼很是緊湊，那麼程序在完成後就容易維護得多了。

奧奇

採訪者：你對如今的年輕程序員有什麼建議？奧奇：若是你是硬被拉入編程這一行的，我建議你保持樂觀的心態，儘可能多編程，同時儘量參加各類不一樣的項目。儘量多把時間花在計算機上，還要學會準確判斷本身的職業倦怠情況（burnoutlevel）。要是別人以爲你很古怪，不用放在心上。

羅伊森

採訪者：你可不能夠描述一下你是怎麼編程的？羅伊森：我是個很是「自底向上」的程序員。我不爲總體戰略傷腦筋，由於除非完成了全部細節，不然我歷來看不清全貌。若是你想要把工做交給其餘人作，「自頂向下」的編程天然很好——很顯然，你須要瞭解各個部件是如何在一塊兒工做的。對我而言，編程是一個反覆迭代的過程。我老是一次作一個程序的一小部分。若是我在一個地方改動一下代碼，就極可能須要在其餘地方也動一下。我會這樣上下調整，直至方案合適爲止。我也很是實際。我見過不少不實際的聰明人，他們在追逐一些徹底無用的學術目標時迷失了方向。實際對編程很重要。你必須可以猜出完成一個項目的準確時間，具備推斷能夠作哪些、不能夠作哪些的能力，而後據此去作，抵制中途停下來幹其餘事情的誘惑。當你想作好每一件工做時，實際一些尤其重要，畢竟你能夠分配在每件工做上的時間頗有限。若是你想把一個項目作到盡善盡美，每每輕易就會多花上兩倍的時間。可東西若是沒完成的話，就不會賣得好。沒有可銷售的產品，你就很難維持生計。

採訪者：你寫的源代碼採用特殊風格嗎？羅伊森：我想每一個人都有本身的風格。個人代碼很散，裏面有大塊的留白。我老是讓不一樣例程須要用到的函數彼此獨立，來節約代碼、提升速度。