《构建之法》 参考书和链接汇总

参考书汇总

一些读者对《构建之法》引用过的参考书也感兴趣，因此我把所有参考书单独列出来。其实人大部分的思想都是受某些外部信息的启发影响而来，很多道理看似新颖，其实别人早就讲过了。这个参考书列表大致按照 类别  – 字母/拼音 的顺序排列。有些参考书是第三版加入的，第一、二版并没有：

行业和公司的兴衰

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

 “玩闪电的牛人们” … 施乐公司PARC 研究院的故事，可歌可泣可叹。1970 – 80 年代天才们的创新, 在PARC 这个温床上孕育, 发展并被公司忽视。但是这些创新深深地影响了之后的计算机行业 – 包括 Apple 和 Microsoft.

Dreaming in Code  by   Scott Rosenberg，  中文版 《梦断代码》

一个有技术大牛，有资金，有宏大目标的团队，为何7年做不出一个好软件nbsp;

Fumbling the Future: How Xerox Invented, then Ignored, the First Personal Computer

        施乐公司的Parc 研究院如何发明了第一个PC (以及其他先进技术)， 施乐公司的领导如何又错过了这个浪潮。 

Hard Drive  by  James Wallace, Jim Erickson

Bill Gates 的成长和微软的前15 年。  You got to drive hard. 

In Search of Stupidity: Over 20 Years of High-Tech Marketing Disasters by Merrill R. Chapman

中文版 《IT 大败局》

很多精彩的IT 行业失败的故事和分析，大多是20世纪80年代 – 90年代PC 浪潮中的事件， 字处理软件，浏览器， 络计算机(NC)等。故事有些老，但是经验教训是非常类似的。

Information Rules: A Strategic Guide to the Network Economy by Carl Shapiro, Hal R. Varian

信息时代的产品和竞争和以往的竞争不同, 有一些特殊的规律, 这本书通过不少实例, 描述了这些规律。一个领域的先行者，就能制定规范，这是先发优势的一个例子。

Inside Intuit by Suzanne Taylor , Kathy Schroeder , John Doerr

Intuit 的创始人分析了市场上所有个人财务软件的情况，发 现市场上已存在46家公司，他们自嘲说自己有 47th Mover Advantage. 结果就是这第 47 个竞争者最后成为市场的老大，打败了包括微软公司在内的诸多对手。 微软在2009年宣布停止其个人财务软件 Money 项目，退出这个市场。

Intuit 早期的两个工程师还留下了最早的结对编程的记录(见第三章 两人合作)

科技公司在各次浪潮中的命运，科技、商业、资本的结合。

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

Walkman 的故事被收录在创新一节中。这本书(三册)有很多值得技术人员和企业家学习的地方。

Steve Jobs by Walter Isaacson

《乔布斯传》

这个传记里有很多关于创新，项目管理，企业成长的经验教训。

Where Wizards Stay Up Late: The Origins of the Internet by Matthew Lyon , Katie Hafner 

互联 在美国怎么建起来的过程，很多计算机科学和工程的早期人物在此中出现，很多我们现在习以为常的规矩 (例如email 中的 @ 符 )就是那时候出现的。

公司、团队的管理，创业和创新 

Competing Against Luck Clayton M. Christensen

这本书提出了 “Jobs To Be Hired” 理论，来指导如何提高创新产品的成功率，而不是只靠运气。 

Cross the Chasm by Geoffery A. Moore

著名的early adopter 和 early majority 之间的鸿沟(chasm) 就来自于这本书，非常有洞察力的分析方法。 2014年更新的第三版有很多新的案例分析。

Death by Meetings: A Leadership Fable, by Patrick Lencioni

如果说交流是团队合作的重要途径，那么，要开多少会，怎么开好会，很值得研究。 Lencioni 很会讲故事，故事之余他提供了一个 “以什么节奏开什么会，解决什么问题” 的框架。

Driven by Difference: How Great Companies Fuel Innovation Through Diversity by David Livermore

怎样让背景和思路各异的团队成员凝聚在同一目标下，达成最终结果/p>

书中提出很多独到的解决办法，其中 pre-postmortem 做法， 让团队成员想象现在就是产品发布后一个月， 但是产品失败了，让团队成员列出可能的原因。这样能促使团队成员讨论目前项目的风险在哪里，如何面对。

Escape Velocity: Free Your Company’s Future from the Pull of the Past   by Geoffrey A. Moore

大家都在类似的轨道中打转，你怎么调整动能和势能，获得 “逃离速度”， 让你的产品比别人好一个等级Geoffrey 的分析方法独具一格，从这个视频也能看出他的洞察力和激情。《构建之法》的创新一章中引用了其分析方法。

The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni

通过讲故事的形式，描述了领导团队崩溃的五个特征，以及怎么去解决这些问题。

Hackers and Painters by Paul Graham 

The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers  by Ben Horowitz

创立一个企业是为什么 Build To Win.

假设公司花了12小时的时间备课并给10个员工培训四小时。总共花费12 + 10*4 = 52 小时。在培训后的一年中，这10个员工会有20,000 个小时的工作时间，如果培训能提高1% 的效率，那么公司将会节约200 小时。 

In Search of Excellence: Lessons from America’s Best-Run Companies by Thomas J. Peters , Robert H., Jr. Waterman

中文版《追求卓越》

这本1980 年代的书调查了当时美国优秀公司的管理经验，总结了卓越管理的几大要素，我大约是在1993年读到的，里面关于HP 公司的故事给我留下很深印象：

HP 的创始人看到公司管理人员下班时把仪器库房都锁起来了，就命令让库房都不上锁，这样员工可以拿仪器回家做各种实验。

当年的在这个书上作为正面例子的公司如HP、IBM都碰到了新挑战，有些公司已经不存在了(如王安电脑)，是旧的管理原则不起作用了，还是新的领导层不再追求卓越面是这本书总结的管理原则：

(1) 崇尚行动    实施“走动管理”，到问题现场去；鼓励试验。(2) 贴近顾客 (3) 自主创新 

(4) 以人促产    用交流、培训、保障和奖励代替死板的员工手册；高层主管实行“不关门制度”，任何人都可以上门交流。

(5) 价值驱动    有效的价值体系应该致力于激励公司基层员工。

(6) 不离本行    不进行多元化，或只进行相关行业的多元化，尽量避免大规模的并购。

(7) 精兵简政    控制管理层规模；切分大的部门避免管理的复杂度。

(8) 宽严并济    宽松的工作氛围，严格的价值观体系。

Innovation: The Five Disciplines for Creating What Customers Want by Curtis R. Carlson, William W. Wilmot 

SRI 的专家总结了创新的方法，NABC，《构建之法》中的NABCD 就是来自这里。 

The Innovators Dilemma,  by Clayton M. Christensen

中文版《创新者的窘境》

成功的大公司， 能听取用户的意见，把精力投入增量改进现有产品中；成熟的价值链从多方面阻止公司去冒险尝试新兴领域； 同时公司为了争取更高的利润率，不得不忽视萌芽阶段的小市场；专家对新兴市场的分析往往基于现有经验，结论往往大错特错！ 就这样，往往有一些名不见经传的小公司从薄利的小市场切入，使用比较粗糙的颠覆式技术，慢慢掀翻了大公司。 

The Innovator’s Solution, by Clayton M. Christensen

Kiss Theory Goodbye, Bob Prosen

一本实话实说的领导力手册。每一本类似书籍都会提到分析问题并改进，大部分团队在实施改进计划后一段时间，又会人走灯灭，旧毛病又回来了。我欣赏他强调的是 ICA: Irreversible Corrective Action，怎样保证这个改进措施不会随着时间和人事的变动而消失/p>

The Myths of Innovation by Scott Burken

创新的迷思。《构建之法》中创新的很多内容受到这本书的影响。

Secret of Software Success  by by Cyriac R. Roeding, Gert Purkert, Sandro K. Kindner, Ralph Muller, Deltiv J. Hoch

中文版《软件业的成功奥秘》

1999 年出版。 麦肯锡的商业顾问们采访了全世界很多软件团队，总结经验并展望未来。成功的奥秘之一是: 每天都有成功的构建 – have working daily build. 

Six Thinking Hats by Edward De Bono

六顶不同颜色的思维帽子，非常有效的工具，能帮助团队思考问题，解决问题。

The Tipping Point by Malcolm Gladwell

中文版 《引爆点》为什么有些产品能迅速扩张什么产品之外的因素/p>

The Wisdom of Teams by Jon R. Katzenbach

什么是团队群各自行事，没有依赖关系的人可以叫 “工作组”， 而不是团队。 强行把一群人命名为团队，只会得到效率低下的假团队。 (构建之法第17章团队一节)

软件工程之理论和实践

After The Gold Rush by Steve McConnell

这是Steve McConnell 另一本著作 Professional Software Development  的beta 版本。 

Agile Project Management with Scrum by Ken Schwaber

敏捷开发的专家解释敏捷和SCRUM。 

Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin

中文版 《敏捷软件开发 原则、模式和实践》

变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆，那么去应用 SRP，或者其他原则都是不明智的。

遵循OCP 的代价也是昂贵的……显然，我们希望把OCP的应用限定在可能会发生的变化上。… … 最终，我们会一直等到变化发生时才采取行动 。

回头看看我们在软件工程课上给学生布置的作业，有“变化的轴线么” 有需求的变化么有！ 那既然不用任何考虑变化，为何不把所有的功能放在一个大类里面，或者就写在main()函数里面，尽快实现就交作业了，管他什么SRP , OCP原则，什么内聚，耦合，信息隐藏这说明我们的学生恰恰是明智地完成了老师布置的作业。没有足够复杂性，易变性的软件工程作业要求，反而让学生陷入 “我有银弹”， “软件工程的要求没啥用” 的误区：

“哎，你看我搞了一通宵，就写好了程序，得了高分。也不用啥软件设计的原则，事先也不用需求说明书，也不留什么文档，就搞定了！软件工程对我没用！”

Art of Project Management, by Scott Burken (后续版本叫 Make Things Happen)

中文版 项目管理的艺术

Scott 在1994 到 2003 在微软 IE 等团队做Program Manager,  后来又做了内部培训工作。他对以微软为代表的项目管理有很深的见解。(我参加了他离开微软前做的最后一次讲座，他喝了啤酒，弹起吉他…) 

Behind Closed Doors: Serects of Great Management by Johanna Rothman, Esther Derby

通过一个虚拟的项目，几个经理和员工交流的各种场景一个来串联很多关于交流和管理的建议。

Best Kept Secrets of Peer Code Review by Jason Cohen

很多关于代码复审的心得，同时还清晰地描述了 PSP, TSP, CMMI 的关系。 

Code Complete (2nd Ed)Steve McConnell ISBN: 9780735619678

中文版 代码大全 (第二版)斯蒂夫·迈克康奈尔 ISBN: 7121022982

我的书评

Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams by Steve Maguire

这本1994年出版的书总结了微软鼎盛时期的软件工程实践心得。 

Engineering—An Endless Frontier by Sunny Y. Auyang

译者之一李啸虎的解读：

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

科学家的宗旨是：“我发现，故我在。”

而工程活动主体(工程师和企业家)的宗旨则是：“我构建，故我在。”

Engineering Software as a Service: An Agile Approach Using Cloud Computing by Armando Fox and David Patterson

UC Berkeley 的软件工程+云计算课程

Facts and Fallacies of Software Engineering by Robert Glass

The Mythical Man-Month: Essays on Software Engineering by Fred Brooks Jr. 

中文版《人月神话》

PeopleWare: Productive Projects and Teams  by  Tom Demarco / Timothy Lister  中文版 《 人件》 由一群人组成的团队怎么样才能提高软件开发过程的效率办公区搞成整齐划一的格子间, 容易布线，但是对效率有正面还是负面的影响及很多值得深思的问题 (效率，人员去留，团队文化，领导力，如何应对过多的会议和邮件…) 

Professional Software Development by Steve McConnell如果软件工程是一个独立的学科，它和“计算机科学”  有什么区别和联系果软件工程是一个独立的“职业”， 那么个人，机构，和整个行业应该有什么样的原则，规范和行为准则apid Development  Steve McConnell (ISBN 1-55615-900-5)

中文版 快速软件开发斯蒂夫·迈克康奈尔 著 译者: 席相霖 等 ISBN 9787505372856

Refactoring: Improving the Design of Existing Code by Martin Fowler

中文版 《重构 改善既有代码的设计》 

Make it work,  make it right, make it fast, make it extensible.  这本书提供了许多在OO 开发模式下 “make it right”, “make it extensible” 的建议。 

重构是 ”不改变软件可观察行为的前提下改善其内部结构”。 如果软件的行为不变，为啥要折腾代码因为我们想把程序的结构变好，这样方便程序员理解，测试，维护(right)，也方便将来的扩展(extensible).  大学生们交了软工大作业之后，还会有人去理解、测试、维护、扩展它么如果没有，那就解释了为何在大学里没有人理解重构的意义。 

Software Engineering: The Current Practice by Rajlich Vaclav

Writing Solid Code by Steve Maguire

历久弥新的指南。

深入分析中国软件企业和员工的常见毛病，给出很多好的建议。

软件工程之人机交互与设计

About Face: The Essentials of Interaction Design   by Alan Cooper, et al. 

中文版:《软件观念革命》

Design of Everyday Things by Donald Norman

茶壶嘴和茶壶把手在同一边的茶壶就出自这本书。

Emotional Design: Why We Love (Or Hate) Everyday Things  by Donald A. Norman

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

对以“技术人员为主导” 的设计给予辛辣的讽刺和鞭笞 (就像疯子在管理疯人院)。给出了怎么从普通用户出发做设计的办法。

Microinteractions: Full Color Edition: Designing with Details by Dan Saffer 

在小小的移动设备上，怎么做人机交互/p>

Success through Failure: The Paradox of Design by Henry Petroski

从PowerPoint的前生， 到各种桥梁的演化，设计思想也在各种失败中演进。