编程书籍
作者：郑昌顺
链接：https://www.zhihu.com/question/50408698/answer/1489486317
来源：知乎
我们邀请到微软亚洲研究院首席研发经理邹欣来推荐IT行业的书。他在工作之余，出版了几本书，其中《编程之美》《构建之法》在程序员界颇具名气。此外，他还是拥有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 Stay Up 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 Hertzfeld
推荐理由：作者Andy是Mac早期团队成员，这本书记录了苹果公司的一群年轻人创造Macintosh的故事。这些故事有些振奋人心，有些很幽默，有些比较疯狂。我特别喜欢里面的“圆角矩形框”的故事：
在设计Macintosh界面的时候，技术牛人比尔用了各种技巧，让Mac能很快地画出各种圆形和椭圆，这在1981年的Mac机器上是很了不起的事情。因为第一版的Mac都没有浮点计算芯片，运算开方和乘除法都很慢。比尔的算法只用加减法，就做到了画椭圆，所以速度非常快。他激动地给乔布斯演示，乔布斯说：“你也可以把带圆角的矩形框画得很快吧？”比尔有点不爽，因为产品经理不但不衷心佩服这个技术，而且还提了新的要求。他说：“不，没法做，实现不了，而且我们不需要这样的圆角矩形框！”乔布斯认真地指出来办公室里很多物件都是圆角矩形框，而且他还把比尔拉到屋外散步，一边走，一边指出周围生活中的各种圆角矩形，它们正是用户非常熟悉的用户界面元素。比尔只好说“我试试看……”。第二天，比尔就实现了快速画圆角矩形框的算法，这就是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》书中学到了一个方法：当写作遇到阻碍时，我会上网逛逛，通常会发现一些和软件工程有关的案例或趣闻轶事，就把它们都收集起来以备不时之需。《编程之美》、《构建之法》中的一些内容，就是来自于网上看到的讨论，以及和同事闲聊中得到的灵感。