微軟亞洲研究院首席研發經理鄒欣在工作之余，出版了幾本書，其中《編程之美》、《構建之法》在程序員界頗具名氣。他還是在微博社交網絡平臺擁有 30 余萬粉絲的大 V。既然寫書，可能也是個讀書人？這次，我們請他談談他喜歡的專業書。

我今天想通過三個公式，向大家介紹 IT 行業中一些有趣的書。

第一個公式：程序 = 數據結構 + 算法

Algorithms + Data Structures = Programs

中文版：《算法 + 數據結構 = 程序》

作者：Niklaus Wirth

推薦理由：《算法 + 數據結構 = 程序》是一本經典書籍，我在大學三年級的時候，要做編譯原理課的項目，就去圖書館借了這本書看。當時覺得這種經典書籍一定非常難懂，結果卻出乎我的意料，這本書對編譯原理和程序設計的各種技術講解得非常清晰。說實在的，它比我們課堂上用的自編教材好多了。后來隨著閱讀書籍的增加，我發現要真的弄懂一個領域，還是要讀那個領域經典的書，而且這些大部頭的經典往往非常好懂（當你有耐心的時候）。

編程領域還有很多好書，今天我們主要講軟件工程和創新方面的書，所以編程方面只列一本。

第二個公式：軟件 = 程序 + 軟件工程

很多 IT 專業的同學不但不看書，連程序都寫得少，考試就靠老師劃的重點。談起專業書，有人問，專業書是否都充斥著好多原則和教條，需要劃重點線和背誦的，例如 “二十三條設計模式”？其實并不對，IT 行業這幾十年有這么多有趣的技術、人物、故事，這些都在各種有趣的書里面，錯過這些書，實在太可惜了。本文中推薦的書都很有意思，而且能引起思考，并不強求大家劃重點和背誦。

Agile Software Development, Principles, Patterns, and Practices

中文版：《敏捷軟件開發：原則、模式和實踐》

作者：Robert C. Martin

推薦理由：這本書從實踐出發，講解了敏捷方法、OO 設計原則和設計模式。這本書并不是靜態地羅列并贊美 N 種設計原則和模式，而是分析原則和模式產生的必要性和使用的時機。例如對于 “單一職責原則（SRP）”、“開放封閉原則（OCP）”，作者寫到：

變化的軸線僅當變化實際發生時才具有真正的意義。如果沒有征兆，那么去應用 SRP，或者其他原則都是不明智的。

遵循 OCP 的代價也是昂貴的…… 顯然，我們希望把 OCP 的應用限定在可能會發生的變化上。… … 最終，我們會一直等到變化發生時才采取行動。

回頭看看許多大學在編程和軟件工程課上給學生布置的作業，有 “變化的軸線么”? 有需求的變化么？沒有！那既然不用考慮任何變化，為何不把所有的功能放在一個大類里面，或者就寫在 main () 函數里面？管他什么 SRP、OCP 原則、內聚、耦合、信息隱藏？當在課程中沒有足夠復雜性、易變性的軟件工程要求的時候，學生的低質量作業恰恰是明智地完成了老師的要求。有同學還陷入 “軟件工程的原理沒用” 的誤區：

"

哎，你看我搞了一通宵，就寫好了程序，得了高分。也不用啥軟件設計的原則，事先也不用需求說明書，也不留什么文檔，就搞定了，軟件工程對我沒用！

"

這是值得軟件工程老師深思的。

Refactoring: Improving the Design of Existing Code

中文版：《重構：改善既有代碼的設計》

作者：Martin Fowler

推薦理由：“Make it work, make it right, make it fast, make it extensible.” 這本書提供了許多在 OO 開發模式下 “make it right”、“make it extensible”的建議。重構是 “不改變軟件可觀察行為的前提下改善其內部結構”。我們想把程序的結構變好，方便程序員理解、測試、維護 (right)，也方便將來的擴展 (extensible)。大學生們交了軟工大作業之后，還會去理解、測試、維護、擴展它么？如果沒有，那就解釋了為何在大學里沒有人理解重構的意義，也沒有得到軟件工程的鍛煉。

很多同學認為，科學和理論很重要，軟件工程似乎就是多寫代碼。這種觀點是非常錯誤的。計算機科學與軟件工程各有自己的特點和側重點，要在這兩個領域取得成就，就要按照不同領域的規律來實踐。計算機科學家 Tony Hoare 精辟地總結過兩個學科的不同側重點：

Engineering—An Endless Frontier

中文版：《工程學：無盡的前沿》

作者：歐陽瑩之

推薦理由：本書作者論證了當今的工程學不僅是科學的合作者，而且應該處于等量齊觀的地位。

譯者之一李嘯虎對本書的解讀是：

哲學家的宗旨是：“我思，故我在。”

科學家的宗旨是：“我發現，故我在。”

而工程活動主體（工程師和企業家）的宗旨則是：“我構建，故我在。”

工程師構建了新的軟件、新的交流工具（互聯網），讓新一代的科學家們能在此基礎上作更多的科學研究。

最近火熱的 AI 的主要核心算法在三十年前就已經出現，為何三十年前 AI 沒有突破，而現在才有大規模的突破？因為工程師搭建了互聯網和與互聯網相關的各種應用，讓大量的數據能產生并為科學研究所用；并且，計算機體系結構工程師、芯片工程師、軟件工程師設計和實現了各種分布式算法，讓以高性能 GPU 為代表的算力能有效率地為 AI 訓練服務。這才讓 AI 有了今天百花齊放、百家爭鳴的繁榮景象。

工程學不是別的學科的附庸，它有自己的規律，我們工程師要認真研究和探索。

Dreaming in Code

中文版：《夢斷代碼》

作者：Scott Rosenberg

推薦理由：很多同學胸懷大志，覺得自己技術很牛，萬事俱備，就差一大筆啟動資金了；也有同學發現了很好的想法，就差一個給力的程序員。如果把技術和想法結合起來，創業賺大錢豈不是如同探囊取物一般簡單？這本書就講了這樣一個故事：一個有技術大牛、資金和宏大目標的團隊，為何七年做不出一個好軟件？作者 Scott 忠實地記錄了這個團隊七年中的各種折騰、各種軟件工程的錯誤。這些實踐中的錯誤和對錯誤的分析，價值遠遠大于那些成功學的雞湯和煽情的新聞報道。

軟件開發離不開人：人的動力，人的發展

PeopleWare: Productive Projects and Teams

中文版：《人件》

作者：Tom Demarco、Timothy Lister

推薦理由：由一群人組成的團隊怎么樣才能提高軟件開發的效率？把辦公區搞成整齊劃一的格子間有助于電源線和網線的布置和衛生的清理，但是對工程師的效率有正面還是負面的影響？IT 工業有軟件、硬件，它們都很容易被替換，那么在 IT 工業中的人是否也是統一規格，隨時可以替換的 “人件”？這本書通篇講述了相反的觀點：不是把人當作零件來用，而是要尊重人，發揮人的潛能，通過有情商的人來創造高效率的團隊。在這樣的原則下，很多令人煩惱的問題都有不錯的解決方案：如何提高效率、如何處理質量和成本的矛盾（注：它們沒有矛盾，高質量會帶來低成本和愉悅的團隊）、人員去留、團隊文化等等。本書特別適合互聯網公司的中層領導來閱讀。

Professional Software Development

作者：Steve McConnell

推薦理由：“軟件工程” 和 “計算機科學” 有什么區別和聯系？現在軟件和 AI 都很時髦，那么熱潮過后呢？如果軟件工程是一個獨立的 “職業”，那么個人、機構和整個行業應該有什么樣的原則、規范和行為準則？例如，現在的醫生都要通過嚴格的考試獲得行醫執照，你才有信心把自己的身體和各種個人信息交給醫生。那么，碰到一個自學編程、號稱能做 AI 應用的業余愛好者，客戶似乎很輕易地就把自己的電腦和各種信息都交給了 TA，這是一個成熟產業應該有的現象么？這本書可以給你這些問題的答案。

Programmers at Work

中文名：《編程大師訪談錄》

作者：Susan Lammers

推薦理由：本書是 19 位 1980 年代的優秀程序員的采訪錄。和這本書的中文名字暗示的不一樣，他們當時還是不是“大師”，而是在第一線每天寫代碼的工程師。在計算機行業發展的早期，計算機的能力還是很有限，但是這些程序員無一例外都認為計算機能極大地改變社會，十分熱情地投入他們的工作，他們堅信星星之火可以燎原。幾十年過去了，回過頭看看那些先鋒人士總結他們成功的經驗，他們對 “未來” 的期望（有些預計非常準確！），是非常有意思的事情。

Coders At Work

中文版：《編程人生：15 位軟件先驅訪談錄》

作者：Peter Siebel

推薦理由：本書是對 15 位頂級程序員的深入采訪，600 頁內容中有非常多的心得可以在軟件工程的實踐中借鑒。這些優秀工程師、科學家閱人無數，對于優秀程序員的特點， 都說是 “熱情”。

但是如果在面試時問 “你對技術有熱情么？”所有回答都是肯定的。如何判斷一個程序員是否真正有熱情？他們的建議是：

你要在場景中、對話中感覺對方的 “熱情”。如果一個念了 5-7 年計算機專業的人，不能 “兩眼放光” 地給你講他自己最得意、最激動人心的項目或創造，如果他除了老師的作業和實驗室的項目之外，沒有別的想法，也不能對你所在的領域提出深刻的問題，你覺得這種人有多少 “熱情”?

Code Complete (2nd Ed)

中文版：《代碼大全 (第二版)》

作者：Steve McConnell

推薦理由：本書是軟件開發的百科全書，是這個領域必讀的一本書。“Code Compete” 是指軟件開發過程中的一個狀態 “代碼完成”，表示所有該寫的代碼都寫出來了（可能還有很多 bug）。中文名比較誤導，這本書并不是包括所有千奇百怪的代碼。

另外一本經常被引用的是：《人月神話》，我個人感覺，這兩本經典都被大多數人買來裝飾了書架，并沒有認真讀、經常讀，不然我們軟件行業就不會還有那么多不靠譜的項目計劃和那么多 bug 了。

第三個公式：企業 = 軟件 + 商業模式

顛覆式創新，有規律嗎？

Where Wizards StayUp Late: The Origins of the Internet

作者：Matthew Lyon、Katie Hafner

推薦理由：這本書用生動的筆觸描述了互聯網在美國建立的過程，有許多計算機科學和工程的早期人物在此出現，很多我們現在習以為常的規矩（例如 email 中的 @符號）就是那時候出現的。

Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age

作者：Michael A. Hiltzik

推薦理由：本書講述了施樂公司 PARC 研究院的故事，可歌可嘆。1970-1980 年代的天才和怪才們在一個非計算機專業的 “外行” 領導下，在遠離公司總部的硅谷做出了很多開創性的工作，包括四項圖靈獎水平的創新。遺憾的是，這些創新死于施樂公司內部的短視和官僚流程中，但是這些創新深深地影響了之后的計算機行業 —— 包括蘋果和微軟。

我記得書里面講了這樣一個故事：一個學歷不高的小伙子很有熱情，非常想加入 PARC，但是研究院沒有正式名額了，研究院的人非常愛才，就把他召了進來，不能開正式的工資，就以 “打印機耗材” 等名義，撥錢給他，算作他的報酬。很多年后，這個小伙子在多媒體領域做出非常出色的成就。現在言必稱創新、愛才的各種研究院敢這么做么？

這本書的標題很難被翻譯成中文，大家看過書后，可以試一試，歡迎留言分享你的翻譯。

浪潮之巔

作者：吳軍

推薦理由：本書講述了各個科技公司在各次技術浪潮中的命運。公司領導的洞察力和科技、商業模式、資本的適當結合，是公司走向浪潮之巔的訣竅。

關于創新的書有很多，下面的四本書兩兩成對，都是作者在第一本成名作后的二十年左右，寫了第二本書，進一步拓展了原有理論，并給出了第一本書中問題的答案：

The Innovators Dilemma

中文版：《創新者的窘境》

作者：Clayton M. Christensen

Competing Against Luck

中文版：《與運氣競爭》

第一本書的推薦理由：成功的大公司能聽取用戶的意見，把精力投入增量改進現有產品中；成熟的價值鏈從多方面阻止公司去冒險嘗試新興領域；同時，公司為了爭取更高的利潤率，不得不忽視萌芽階段的小市場；專家對新興市場的分析往往基于現有經驗，結論往往大錯特錯！就這樣，往往有一些名不見經傳的小公司從薄利的小市場切入，使用比較粗糙的顛覆式技術，慢慢掀翻了大公司。

第二本書的推薦理由：怎樣創新？如何找到用戶真正需要解決的問題？不能光說 “窘境” 而不給出解藥。這本書提出了 “Jobs To Be Hired”理論，來指導如何提高創新產品的成功率，而不是只靠運氣。

Cross the Chasm

中文版：《跨越鴻溝》

作者：Geoffrey A. Moore

Escape Velocity: Free Your Company's Future from the Pull of the Past

第一本書的推薦理由：很多人認為大眾對技術的接受是一道連續的曲線：一個好技術在實驗室取得專家的好評，接著就得到早期嘗鮮者的追捧，然后大眾開始跟進，開始大賣，一舉改變世界。然而，Moore 指出在早期嘗鮮者那里有一道鴻溝（chasm，可以讀作 “開森”)，很多早期產品只有某種新技術，但不能解決用戶真正的需求，它就會掉在溝里，IT 界的專業人士應該聽說過很多這樣的故事，很多高大上的技術創新，在技術圈子里引起了陣陣叫好聲，但是它們往往跨不過鴻溝而折戟市場，成為非常小眾的產品，或者失敗。作者在這本書里還分享了眾多關于打造暢銷產品的真知灼見。

第二本書的推薦理由：一個行業大家都了解，大家的招數都差不多，都在類似的軌道中打轉，沒有明顯的贏家。除了降價，你似乎想不出什么辦法，怎么辦？這本書教你如何分析決定產品成功的各種因素，如何調整動能和勢能，讓你的產品比別人好十倍，獲得 “逃離速度”，別人的產品還在辛苦地繞著地球轉，你的產品已經擺脫了地球引力，一飛沖天了。一個團隊的資源和時間非常有限，我們可以開發各個方面的新功能，你通過什么方法來取舍，決定優先級？Geoffrey 提倡的四個象限的分析方法獨具一格。

企業成長需要什么精神：Build To Win

我們做軟件有各種做法：

Build To Learn：開發軟件，構建系統的目的是做進一步的試驗，試圖發現客觀規律或某個試驗方法的優點與缺點。這些項目經常是科研論文的基礎工作。

Build To Show：為了突出地展現某個技術的作用，開發一些演示為目的的軟件，這些項目很吸引眼球，經常獲得新聞報道，但是功能未必全面或實用。

Build To Serve：為了服務一定范圍的目標用戶而構建的工具等，有時以公開的 SDK 形式發布，讓別的研發人員使用。

Build To Win：以在市場上贏得用戶為目標而構建的軟件。這也是種種科學發現、技術突破最好的試金石。所有以營利為目的的公司和團隊都在為此努力。

下面推薦幾本體現了 “Build To Win” 精神的書：

盛田昭夫：日本制造精神是這樣創造的

作者：江波戶哲夫

推薦理由：這本書描述了以索尼公司創始人盛田昭夫為代表的那一代技術人員朝氣蓬勃的創新精神，和各種關于創新、冒險的故事。這套書有很多值得技術人員和企業家學習的地方。他們創新的第一個產品是電飯鍋！但是由于技術不過關，這個創新失敗了。但隨后，他們在收錄機、電器和游戲機開創了一個時代。

索尼公司的電飯鍋產品

Hard Drive

作者：James Wallace、Jim Erickson

推薦理由：本書客觀描述了 Bill Gates 的成長和微軟公司的前 15 年的發展。讀了這本書，你就不會相信各種關于微軟早期成功的小道消息了。當被問到成功秘訣時，Bill 的回答很簡短：“You've got to drive hard”。這里 “Hard Drive” 不是指硬盤，而是指 “猛踩油門”。

Inside Intuit

作者：Suzanne Taylor、Kathy Schroeder、John Doerr

推薦理由：商業理論會談到 “先發優勢”（Frist Mover Advantage）和 “后發優勢”（Second Mover Advantage），Intuit 的創始人分析了市場上所有個人財務軟件的情況，發現市場上已存在 46 家公司，他們自嘲說自己有 47th Mover Advantage。結果就是這第 47 名的后來者最后成為了市場的 “老大”，打敗了包括微軟公司在內的諸多對手。Intuit 早期的兩位工程師還創下了軟件行業最早的結對編程記錄 ——1987 年 3 月，為了趕進度，他們兩人輪換一人敲代碼，一人在旁邊指揮，連續工作了六十小時。

Revolution in The Valley: The Insanely Great Story of How the Mac Was Made

中文版：《硅谷革命：成就蘋果公司的瘋狂往事》

作者：Andy Hert***eld

推薦理由：作者 Andy 是 Mac 早期團隊成員，這本書記錄了 Apple 公司的一群年輕人創造 Macintosh 的故事。這些故事有些振奮人心，有些很幽默，有些比較瘋狂。我特別喜歡里面的 “圓角矩形框” 的故事：

在設計 Macintosh 界面的時候，技術牛人比爾用了各種技巧，讓 Mac 能很快地畫出各種圓形和橢圓，這在 1981 年的 Mac 機器上是很了不起的事情。因為第一版的 Mac 都沒有浮點計算芯片，運算開方和乘除法都很慢。Bill 的算法只用加減法，就做到了畫橢圓，所以速度非常快。他激動地給喬布斯演示，喬布斯說：“你也可以把帶圓角的矩形框畫得很快吧？” 比爾有點不爽，因為產品經理不但不衷心佩服這個技術，而且還提了新的要求。他說：“不，沒法做，實現不了，而且我們不需要這樣的圓角矩形框！” 喬布斯認真地指出來辦公室里很多物件都是有圓角矩形框，而且他還把比爾拉到屋外散步，一邊走，一邊指出周圍生活中的各種圓角矩形，它們正是用戶非常熟悉的用戶界面元素。比爾只好說 “我試試看……”。第二天，比爾就實現了快速畫圓角矩形框的算法，這就是 Mac、iPhone、iPad 上面用戶習以為常的圓角矩形框的來歷。

你也可能注意到了，有些操作系統上的圖標默認是直角的矩形框，這兩種設計影響你使用的效率么？影響你對它們 “美” 的評價么？

Steve Jobs

中文版：《喬布斯傳》

作者：Walter Isaacson

推薦理由：《喬布斯傳》中有很多關于個人成長、情商、創新、項目管理、企業成長的經驗教訓。它也讓我們全面了解了喬布斯生命中的閃光點和不那么閃光的地方。

在年輕的時候，我很不喜歡看人物傳記，覺得那都是宣傳和吹牛。當我有了一些人生閱歷、能耐心讀書的時候，我發現有些傳記還是很有看頭的。例如在《杰克?韋爾奇自傳》中，杰克在回顧了自己幾十年來招聘員工時所犯的錯誤：

根據應聘者的外表和畢業學校來決定是否錄用。（后來他發現：有些人徒有其表，外強中干）

在亞洲招聘時，如果應聘者的英語說得不錯，我就很有可能接受了他。（后來他發現：語言能力不是全部能力）

我對那些受過多門學科教育，有著多個學位頭銜的簡歷十分偏愛。（后來他發現：有些人不能集中精力在某一項業務上，容易散漫，不愿承諾，缺乏對任何一件事情的緊張與熱情）

走了這么多彎路后，杰克意識到真正要尋找的是那些充滿了熱情，希望做出點成績來的人 —— 這和我們前面看到的編程大師的總結挺像的，可能大家都走過類似的彎路吧？

In Search of Excellence: Lessons from America's Best-Run Companies

中文版：《追求卓越》

作者：Thomas J. Peters、Robert H.、Jr. Waterman

推薦理由：這本上世紀八十年代的書調查了當時美國優秀公司的管理經驗，總結了卓越管理的幾大要素。里面關于惠普公司的故事給我留下很深印象：惠普公司的創始人看到公司管理人員下班時把儀器庫房都鎖起來了，很生氣，命令庫房都不上鎖，這樣員工可以拿儀器回家做各種實驗。

在書中當年作為正面例子出現的公司如惠普、IBM 現在都碰到了新挑戰，而有些公司已經不存在了（如王安電腦）。是舊的管理原則不起作用了，還是新的領導層不再真正追求卓越，而是把精力花在創新公司的 logo 這種表面文章上了？下面是我體會比較深的兩個原則：

崇尚行動。實施 “走動管理”，到問題現場去；鼓勵試驗。

用交流、培訓、保障和獎勵代替死板的員工手冊；高層主管實行 “不關門制度”，任何人都可以上門交流。

后記

我估計你們會問：為什么推薦的書單有這么多老書？

20 世紀末，有人問軟件工程專家戴維?帕納斯（David Parnas）：將來會有什么令人興奮的軟件工程技術出現？他回答：最有用的技術不在將來，而是已經出現好些年了，只不過我們沒好好用。我們同樣也可以說，優秀的書已經出現好些年了，只不過我們沒好好讀。

還有人問：在繁忙的工作之余，你怎么有時間寫完三本書？

我曾經在《Weinberg On Writing: The Fieldstone Method》書中學到了一個方法：當寫作遇到阻礙時，我會上網逛逛，通常會發現一些和軟件工程有關的案例或趣聞軼事，就把它們都收集起來以備不時之需。《編程之美》、《構建之法》中的一些內容，就是來自于網上看到的討論，以及和同事閑聊中得到的靈感。

IT 行業不光有 996， 還有很多有趣的人、有趣的書， 大家平時喜歡哪些書？歡迎留言分享。