查爾斯.西蒙尼：

在某些情況下，如果你倒著做事情，之前顯得很復雜的問題突然之間會變得非常簡單。例如，解析前向引用（forward reference）可能很難。要是倒著掃描，它們就變成了後向引用（backward reference），很容易解析。只要從新的角度看待程序，原本可能很難解決的問題也會變得容易解決。

什麽是編程？人們對此一直各持己見。有人說它是科學，有人說它是藝術，還有人稱之為技能或手藝。我認為這三方面兼而有之。我們喜歡說它蘊含大量藝術成分，但是我們都知道它裏面更多的是科學。

孩子們在學校裏學習數學，高中畢業時，他們會以為數學就是加法和乘法，甚或代數和微積分。其實，算術，即使簡單如加法的運算，背後也有令人難以置信的科學理論作支持。

計算機編程背後也有大量科學理論作支持。例如，哥德爾定理的數學證明冗長而復雜，但是如果借用計算機科學的圖靈定理，證明起來不費吹灰之力。信息理論和計算機科學其他領域對數學影響巨大，反之亦然。

編程包含有大量科學，同時，它也有點像手藝。實際上，在許多人看來，編程是一項復雜的技能，這跟工具制造很像，需要精雕細琢。我認為，只要將科學、藝術和技能這三者拿捏得恰到好處，你就能取得一些引人矚目的成績。

在我看來，編程顯然有審美的一面，對用戶界面而言，不僅設計中存在，甚至連外觀也不例外。當你看到那些醜陋的屏幕時，程序員在藝術上的不足便一覽無遺。在其他方面，計算機編程也堪稱藝術，正如高能物理也可視作藝術一樣。

審美也直接影響到其他程序員分析該程序並探究其編寫方式，毋庸置疑。我覺得代碼清單和計算機自身的美感一直讓我陶醉其中。

“匈牙利命名法”：

命名規範其實是要讓代碼更易讀。這套規範能夠很好地控制程序中所有變量的命名。

要是分解一個程序，把它放進磨床，然後對碎片進行分類，你就會發現程序的大部分都是名字。寫下“apples + oranges”，你會發現名字“apples”有6個字符，運算符“+”只有1個字符，名字“oranges”有7個字符，一共14個字符，只有一個字符即加號與運算有關。因此，對我來說，要起到作用或有所改進，合乎邏輯的做法就是盡力完善程序的主要部分，也就是名字。“匈牙利命名法”是一種根據變量的屬性自動為其創建名字的命名方法。這跟人們把當裁縫（tailor）的叫做泰勒（Taylor）以及把當鐵匠（blacksmith）的叫做史密斯（Smith）非常相似。

因此，面對一個具備某些屬性的結構，不要隨隨便便地取個名字，然後讓所有人去琢磨名字和屬性之間有什麽關聯，你應該把屬性本身用作結構的名字。這種方法有很多優點。首先，造個名字很容易，想到那些屬性時，把它們寫下來，名字自然就有了。第二，它很容易理解，因為當你讀到某個變量時，從名字本身就能了解到與屬性有關的大量信息。這些屬性會越來越多，因此很難簡明地描述它們。為此“匈牙利命名法”引入了一種縮寫符號，以很小的空間就能展現具體屬性。當然，這在不知情的人看來完全是一團亂麻，那個玩笑就是這麽來的。

有些人認為，如果他們可以讀出代碼裏的每個字，那麽程序就是可讀的。實際上，這種意義上的可讀性並不可取。沒有人會拿著代碼清單，站到演講臺上大聲朗讀程序。關鍵在於理解。只是能閱讀單詞並發出音來，這毫無用處。當人們看到采用“匈牙利命名法”的代碼清單時，他們發現這些詞很難念，可能就會認為代碼不是可讀的。但實際上，由於名字和屬性之間存在關聯，它更容易理解，也更便於溝通。那些使用匈牙利命名法編程的人，即使在離開我的部門之後，仍會繼續使用它。這種命名法已經打入蘋果電腦、3Com及其他許多公司。

創建程序的整個過程（適用於所有程序的過程）

對編程而言，我認為我們應該知道自己想要做什麽。如果不知道，那麽有一個過程確實是解決各種問題的必經之路，那就是要弄清楚：我試圖做什麽？目標是什麽？

打個比方，我想開發一個菜單驅動的文本編輯器，要求響應速度快，並且提供拼寫檢查器等。在開始真正編程之前，我需要先弄清楚最終產品。有時候，目標的選擇取決於我都掌握了哪些技巧。以Bravo為例，這個程序是以算法為導引的。巴特勒·蘭普森描述了兩個很有意思的算法，於是我們試圖圍繞這些算法來編寫這個編輯器，以充分利用這些算法。此外，J. 斯特羅徹·摩爾（J. Strother Moore），就是Boyer-Moore字符串查找算法的Moore，在文檔編輯方面有幾個很有意思的算法。於是我們決定：“嘿，這個編輯器要包含摩爾編輯算法、蘭普森的屏幕更新算法還有兩個緩存。”等到對目標有充分的把握之後，我才會開始真正的編程。我調整姿態，關上房門，並且大聲宣布：“現在我要開始編程了。”

第一步：

編程的第一步是想象。就是要在腦海中對來龍去脈有極為清晰的把握。在這個初始階段，我會使用紙和鉛筆。我只是信手塗鴉，並不寫代碼。我也許會畫些方框或箭頭，但基本上只是塗鴉，因為真正的想法在我腦海裏。我喜歡想象那些有待維護的結構，那些結構代表著我想編碼的真實世界。

一旦這個結構考慮得相當嚴謹和明確，我便開始寫代碼。我會坐到終端前，或者換在以前的話，就會拿張白紙，開始寫代碼。這相當容易。我只要把頭腦中的想法變換成代碼寫下來，我知道結果應該是什麽樣的。大部分代碼會水到渠成，不過我維護的那些數據結構才是關鍵。我會先想好數據結構，並在整個編碼過程中將它們牢記於心。

*******這是最重要的一步

最優算法的知識當屬科學，結構的想象則是藝術。這些算法的細節，以及編寫高效代碼實現這些結構的轉換，是編程像手藝活的一面。從技術上講，這就是所謂維護結構的不變性。編寫代碼以維護不變性是相對簡單的技藝，不過這需要非常用心並輔之以大量訓練才能練就。

如何管理手下的程序員？

管理的最佳方法是言傳身教，經常復審代碼。我們一直堅持開展代碼復審。

讓多名程序員開發一個程序，開發速度不一定會更快：

編寫同一個程序的人員越多，人均產出的實際代碼量越少。結果，總的代碼產出一開始會更多，之後實際上可能會減少。以兩個人為例，也許單位時間只能多寫百分之五十的代碼。

順便提一下，代碼的效率還會隨著開發同一個程序的人員數量的增加而有所降低。最高效的程序往往是一個人寫的。唯一的問題是，它可能需要寫上一輩子，而這顯然是無法接受的。因此你需要找上三五十個，甚或好幾百個人開發一個項目。

預估編寫一個程序要用多長時間：

預估編寫程序要花的時間難度很大。之所以難度很大，原因多種多樣。這並不意味著我們就不用盡全力預估，因為預估時間可能用處很大，就像天氣預報不僅有經濟效益還有其他好處一樣。

挑選合適的人並培養成優秀程序員，有不少套路可循。我們招攬有天分的員工。我不清楚他們何以有如此才華，我也不用去弄清楚。但是他們確實很有才。在此基礎之上，環境可以起到很大作用。

進入公司第一天，程序員就會拿到幾本書。其中一本是數學家喬治·波利亞寫的《怎樣解題》。（西蒙尼邊說邊從他辦公桌旁的書櫃裏取出那本書，翻到某一頁。）這兩頁很重要。這本書的其余內容就是基於這兩頁展開的。這就像一張問題求解的檢查單。這是起飛前、起飛和著陸檢查單。它不會教你如何飛行，但是如果不照做，即使你已經懂得怎麽飛行，也有可能會墜機身亡。

求解問題時，我們遵循以下四個步驟：首先理解問題，然後擬定計劃，接著執行計劃，最後回顧整個過程。這樣的書我們大概有四本，我覺得我們能使程序員比剛加入公司時變得更加優秀。

編程大師訪談錄01----查爾斯.西蒙尼