大師是怎樣煉成的——讀《程式設計大師訪談人物——比爾·蓋茨》有感

畫外音

話說日前讀過《程式設計大師訪談人物——比爾·蓋茨》後，只覺得心潮澎湃、熱血沸騰，但一時間又覺得無從下筆。恰巧參與了活動“尋找GEEK活動開始-----你就是極客”，並創作“極客之我見”一文後，才有了思路，並重新修改了本文題目。

開始之前

開始程式設計之前通常要清晰定義系統的軟體執行環境及其硬體配置情況，其目的是為了給設計、開發、及測試階段提供必要的約束，以便程式部署後能在真實環境下以最佳狀態執行。同理，開始閱讀文章、書籍之前也有必要搞清相關的背景，如創作時間、人物履歷、關鍵專業詞彙等，其目的是為了準確理解文字內容，進而深刻理解文字背後所要傳達的含義。

言歸正傳，在《程式設計大師訪談人物——比爾·蓋茨》一文中並未註明訪談的準確日期，不過通過訪談內容就可以推算出訪談年份，以下內容透露了相關線索：

……這樣當我在1975年坐下來編寫微軟的BASIC解釋程式時，問題已經不在於是否能寫出程式來，而在於能不能把程式壓縮到4K，並得到非常快的執行速度。……

……即使到了今天，在我寫了微軟的BASIC程式10年後，我仍可以在黑板上大段大段寫出當時的原始碼。

由此可知，訪談應該發生在1985年，當然也不排除1986年的可能。

另，比爾·蓋茨的個人履歷在文章的開始就介紹了。至於，專業詞彙BASIC和Microsoft BASIC可以在維基百科上查到相關解釋。

接下來，就讓我們一起看看大師是怎樣煉成的吧！

緣起BASIC

文中提到蓋茨“從少年時代熱衷於電腦遊戲，富於想像力，14時不再上數學課，因為他已很好地掌握了數學知識。”，可見他從小天資聰慧，而且高中時就在軟體開發方面顯露過人的天賦：

比爾·蓋茨從年輕時就開始了計算機軟體的職業生涯。當蓋茨和微軟的聯合創始人保羅·艾倫還在華盛頓州的西雅圖上高中時，兩人就開始做起了程式設計顧問的工作。

人們常說“機會是留給有準備的人”，接下來發生的一切恰恰證明，蓋茨所做的這些準備是多麼重要。

……1974年，蓋茨在哈佛大學讀本科時，他與艾倫合作為第一臺商用微型計算機MITS Altair開發了一套BASIC程式語言。在那個專案順利完成後，兩人創辦了微軟公司，為新興的微機市場開發並銷售軟體。

毫無疑問，蓋茨抓住了這個千載難逢的好機會，既贏得了創業之路上的第一桶金，又為創業之路指明瞭前進方向。

關注細節，酷愛程式設計

在微軟成立之初，蓋茨絲毫不敢懈怠，而是苦練“內功”、事必躬親，如他自己所說：

在公司成立後最初的4年，我參與編寫和設計了微軟所有的程式。在所有這些最初的產品中，無論是BASIC、FORTRAN、BASIC 6800還是BASIC 6502，沒有一行程式碼是我沒有檢查過的。……

……作為程式設計師，我認為自己在1975年到1980年之間的提高是最明顯的。在1975年，我會說：“嘿，看看，我什麼事情都能做。”我真的認為自己可以，因為我讀了大量程式碼，從來沒有發現哪段程式碼是我無法快速讀懂的。……

不僅如此，蓋茨為了把BASIC解釋程式壓縮到4K的記憶體區域中，可謂煞費苦心：

……我們得到了一個機會，在新墨西哥州的阿爾伯克基花了整整一個夏天，把程式徹底重寫了一遍。我認為可以節省幾個位元組，讓程式更精簡。我們非常非常仔細地除錯著，最終得到了那個4K的BASIC解釋程式。

當你非常瞭解一個程式，覺得沒有人在看了程式後會說“還可以做得更好”時，那種感覺真是太棒了，而且程式用在了很多機器中，讓人覺得編寫那樣一個程式是件很興奮的事情。

除此之外，當被問及“你在程式設計時是什麼樣的感覺”時，蓋茨答道：

在編譯程式並計算出正確的結果時，我會非常開心。這是真的，不是開玩笑，所有偉大的事情都會有感情因素，程式設計也不例外。人們很想一上來就開始編碼，但是如果編寫程式碼只是為了得出結果，過後卻發現所有難題都還沒有處理，那麼沒有什麼比這更糟糕的做法了。因為如果真是那樣的話，你就不得不修改已經完成的程式。為了享受編碼並看著程式碼執行起來的樂趣，我喜歡等一等，把基礎打好。這就像吃飯時把最好的食物留到最後才吃一樣。

可見，蓋茨認為程式設計的目的是為了解決實際問題。當編譯程式並計算出正確的結果時，他之所以非常開心，是因為正確結果表明他精心設計的解決方案是切實可行的。

簡單設計，整體把握

對於蓋茨而言，程式設計最重要的不是把程式碼寫出來編譯通過，而是“必須在心中模擬程式是如何工作的，必須完全瞭解程式各部分是如何一起工作的”。為了能在心中模擬程式執行，因此無論演算法、程式、還是功能都應儘量保持簡單。正如蓋茨所說：

最困難的部分是確定採用什麼演算法，然後還要儘可能地簡化演算法。……

如果能夠提供一些簡單的命令，程式通過這幾個簡單的命令就能有效地滿足使用者的需求，那麼結果會好得多。非常好的程式的一個標誌是在內部也能遵循簡單的理念。如果程式想實現複雜的功能，可以通過簡單的內部操作呼叫程式碼，而不必從頭開始去做一系列複雜的操作。

這些觀點與KISS（Keep it simple, Stupid!）設計原則簡直如出一轍。

即便訪談之時，微軟已有160名程式設計師，蓋茨對於簡單設計的重視絲毫沒有放鬆：

……編寫程式設計文件是至關重要的，因為在把問題當做演算法看的時候，問題會得到很大的簡化。可以說演算法是最簡單的形式，從中可以看出問題在什麼地方是重疊的。

除了簡單設計，蓋茨對於程式的整體把握也非常重視，他這樣說道：

……最好的軟體是其中有一個程式設計師完全瞭解程式的工作方式。要做到這一點，必須要特別熱愛程式設計，集中精力讓程式變得極為簡潔。

最糟糕的程式是原來的程式設計師在開始時沒有打好基礎，而他們也沒有再參與到程式的後續開發中。在這類程式上繼續工作就會遇到一種我所說的“實驗性程式”的情況。程式設計師對那些程式瞭解得太少，他們不知道改動之後會影響什麼，比如說會不會影響執行速度。他們可能會使用已經存在的程式碼，他們也有可能並不知道如果修改了程式碼，會破壞何種依賴關係。於是他們加入了新程式碼，並在執行之後說：“噢，看哪，它不是那樣執行的。”這種處理程式的方法效率非常非常低，但很多專案到了最後卻都是這樣的。

而且，當被問及“你的程式設計風格是什麼”時，蓋茨答道：

我喜歡在坐下來編寫程式碼之前先把整個設計方案構想清楚。而在完成程式碼後，我喜歡回去把它從頭到尾再全部重寫一遍。

回答中提到，在完成程式碼後，蓋茨喜歡回去把它從頭到尾再全部重寫一遍——這樣做既有利於對設計細節加深理解、優化設計，又有利於對程式的整體把握。

誠實、謙虛、協作、溝通

蓋茨不僅為人誠實、謙虛，而且願意與他人協作，相互學習、取長補短。蓋茨對於遇到的良師益友，不僅清晰記得每個人的名字，而且對於他們給予的幫助更是記憶猶新。其中，諾頓扮演了良師的角色。正如蓋茨所說：

我一直記得一個人，他是我在TRW公司遇到的，名叫諾頓。我沒有做到特別好的時候，他總會給我指出來。所以當我草率或偷懶的時候，我總是想象著他會走過來，看一看程式，然後告訴我：“你看，這兒有一個更好的方法。”

還有TRW公司的約翰·諾頓，他在讀別人的程式碼時會寫一些備忘錄——在此之前我從來沒有見過有人這麼做。後來我也開始嘗試那樣做了，看別人的程式碼時我會寫下心得。

除了這位印象深刻的良師以外，還有許多優秀、甚至傑出的程式設計師與蓋茨一起開發過程式：

我還非常喜歡為Model 100編寫的那個程式，特別是我們把一個非常有用的小編輯器壓縮到了軟體中。我和一個名叫傑米·鈴木（Jey Suzuki）的日本程式設計師合作完成了那項工作。……

……那時我已經開發完成了8080上的BASIC程式，接下來有大約兩週的時間可以和馬克·查姆伯林（Mark Chamberlain）一起開發6809版本的BASIC程式。

……後來在微軟期間，查爾斯·西蒙尼和微軟其他一些人也影響了我。

當然，保羅·艾倫作為蓋茨的至交好友，又是微軟的聯合創始人，他對於蓋茨的幫助和影響非同小可。

……最初編寫BASIC時，我在紙上畫出了設計草案。我的合作者保羅·艾倫設計並實現了所有開發工具。

……當時保羅·艾倫給我帶來一本介紹Altair的雜誌，我們就想：“老天，我們最好在上面做些事情，這些機器肯定會很受歡迎的。”於是我不再去上課了，我們開始沒日沒夜地工作起來。……

我和保羅·艾倫一起編寫過很多程式，我們之間總會有些共同的想法。當你除錯程式碼或者不能確定一些特定的權衡時，馬上就可以找人交談，那種感覺真的很好。從某種意義上說，那就像是一種休息，可以緩解緊張情緒，不必轉換主題就可以與別人接著討論。在創作的過程中，能夠減輕一些壓力，但仍能集中注意力，這樣是很好的。我和保羅知道如何能夠有效地一起工作。你不會發現太多像我們這樣的搭檔。他對我的影響巨大。……

蓋茨不僅積極與他人協作，而且大力提倡溝通，從而收集優秀思想，並不斷提高程式質量、及程式設計師的個人能力。

……在微軟，通常在晚上或週末會有一個集思會。大家會有些大致的想法，比如說，我們要做世界上最好的字處理器，我們希望技術出版部門藉助這個字處理器能夠做他們想做的每一件事。為此我們會坐下來討論：怎樣才能讓程式真正快捷？能夠嵌入繪圖功能嗎？能夠讓字型平滑但又不降低程式的效率嗎？各種各樣的問題都會透徹地討論，接著就會出現一些好的想法。

另一個重要因素是程式碼複查，要確保程式碼是看過的，看看資深人士是否能提出如何做得更好的建議。而且你必須參考類似的、做得特別特別好的專案。程式設計師可以看看以前其他人是怎麼做的，從其他專案獲得改進自己程式的想法和經驗。

成功源於對失敗的系統反思

蓋茨在創辦微軟之前，也曾參與過一些焦油坑般的大型專案，他是這樣說的：

在我和保羅創辦微軟之前，我們參與過一些大型的軟體開發專案，那些專案可真是災難。他們只是在不停地往專案組加人，卻沒有人知道要如何去穩定專案。我們發誓說自己可不能做成那樣，我們要做得更好。要多花一些時間組織規劃開發組的工作，這種想法對我們一直都非常重要。

正因為蓋茨之前擁有了這些關於失敗專案的經驗，他才有可能進行系統反思，並分析、總結出一套行之有效的專案管理方法：

最好的方法是顯而易見的：保持專案團隊精簡；確保小組中每個程式設計師都非常聰明；為他們提供強大的工具；有一套公用術語，以便大家很有效地溝通。而在這些小組外，找一些經驗豐富的資深人士，在遇到問題時能夠出謀劃策。在專案過程中遇到的困難型別有著驚人的共性。在做設計評審時，我非常樂於根據我自己的專案經驗提出建議。

結束語

儘管像比爾·蓋茨等程式設計大師的人生經歷是獨一無二的，各有精彩所在。然而從訪談的字裡行間中仍可一窺大師的所思所想、所作所為，以及習慣和好惡等等細節。這些內容對於喜愛程式設計的極客而言是無價之寶！正如《道德經》所云：”天下大事，必作於細；天下難事，必成於易。“我們不妨從個人的實際情況出發，在日常工作、生活中，從力所能及的點滴小事做起，養成優良的程式設計習慣，並積極學習、思考，不斷完善程式設計思想。

最後，讓我們去努力精煉有限的人生，使它綻放出無限精彩吧！