在外行看来，程序员们是一群聪明的工程师。他们整日思考复杂深奥的工程问题，编写逻辑缜密的程序代码，开发可靠易用的用户软件。然而，在内行看来，在软件工程这件事上，程序员们的工作往往不尽人意。为什么聪明的工程师们写不出聪明的代码呢？针对这个问题，作者结合多年的职业生涯经历，从多个角度进行了分析和讨论，涉及范围包括程序员的大学教育，软件开发的生命周期，软件工程的复杂性，程序设计语言发展历史，软件工程方法演变历程，等等。本书行文幽默风趣，将经典翔实的史料和形象生动的例子娓娓道来，不仅对软件工程的本质进行了深入的探讨，还为软件工程的从业者提出了实用的建议。

无

1988年11月，尚处于萌芽状态的互联网上的计算机遭到了一种计算机病毒攻击。这种病毒滥用了一个程序员的错误：假定可以信任另一台计算机发送了正确数量的数据。这是一个简单的错误，其修复也很容易，但是所使用的编程语言很容易受到这种类型错误的攻击，并且没有一种标准的方法来检测这种问题。
2014年4月，现在无处不在的互联网上的计算机遭到一种计算机病毒攻击。这种病毒同样滥用了一个程序员的错误：假定可以信任另一台计算机发送了正确数量的数据。这是一个简单的错误，其修复也很容易，但是所使用的编程语言依然容易受到这种类型错误的攻击，并且依然没有一种标准的方法来检测这种问题。
在经历了四分之一个世纪的发展之后，软件工程仍然停滞在“易受攻击的编程语言”和“无法检测错误”的阶段，这显然不是人们期望的。其他新的工程学科在发展初期会生产出不可靠的产品。例如，在航空业发展的早期，人们在车库里制造飞机，结果是可想而知的。而一百年后，我们已经无法想象那个没有航空旅行的世界了—我们已充分掌握了这项技术，在统一的工程标准的基础上，可以制造出非常可靠的飞机。
但是，编写软件却不是这样的。虽然软件被称为工程学科，但它几乎没有工程的特征，即随着时间的推移，在严格的实验基础上建立起一个知识体系。人们自然会问关于工程产品的那些问题：它有多坚固？可以使用多久？什么情况下可能失败？对于软件来说，无论是针对程序的一个部分还是整个软件，这些问题都无法得到可靠的答案。专业许可是大多数工程学科的标志，但这却被软件行业视为潜在的诉讼来源，而不是制定标准的机会。
这样做不仅造成了用户可见的错误，还造成了程序员的重复工作、大量精力浪费、挫败感增加，并且使软件发布被延迟或永远无法发布。
如果你听说过软件行业，那可能是因为不同寻常的程序员面试方式。网站、书籍，甚至是为期一周的培训课程都致力于帮助人们为令人畏惧的编码面试做准备，在这个过程中要么完全有机会展示你的技能和知识，要么完全没有机会。尤其是“白板编程”，候选人必须在白板上匆匆写出短程序。一些求职者抱怨说，这并不能准确反映他们的日常工作，他们希望公司把注意力集中在他们背景中的其他方面。然而，这些求职者可能没有意识到，在他们的背景中并没有太多可以关注的方面。与其他工程学科不同，拥有软件工程学位并不能保证你理解已有的关于编程工具和技术的知识，因为这样的东西根本不存在。你在大学期间可能写了很多代码，但是没有办法知道这些代码是否有用。因此，要求求职者在白板上写代码片段是我们评估一个人的最佳方式。
请看这个笑话，尽管这不是什么好笑的事：你怎么称呼医学院毕业排名最末的人？答案是“医生”—因为从医学院毕业并完成实习意味着他已经学会了如何做医生。我问过医生，他们是如何面试然后被聘用的。他们说，面试时从未被问过具体的医学问题或完成某种简单的医疗程序；相反，面试官谈论的是他们如何与患者交谈、他们对新药物的看法如何这类事情，因为面试官知道他们已经掌握了医学的基本知识。但是，对于计算机科学专业的毕业生来说，这样的普遍要求并不实际。
早在1990年11月，卡内基–梅隆大学的玛丽·肖（Mary Shaw）为《IEEE软件》杂志撰写了一篇题为《软件工程学科的前景》的文章，她解释说：“工程依赖于有关技术问题领域的、以实践者可以直接使用的方式编纂的科学知识，从而为实践中常见的问题提供答案。普通的工程师可以用这些知识来更快地解决问题。这样一来，工程部门就可以共享先前的解决方案，而不是总依赖于某个行家的问题解决方案。”她将软件工程与土木工程进行了比较，并指出，“尽管大型土木结构在有历史记载之前就已经建成，但在过去的几个世纪里，它们的设计和建造都是基于理论知识，而不是凭直觉和积累的经验。”1我翻阅了美国土木工程师协会的出版物目录，其中尽是有趣的标题，如《水管情况评估》和《寒冷地区路面工程》，我很欣赏在其他工程学科中有这么多的理论知识。
回顾各种形式的工程史，肖写道，“工程实践是从商业实践中产生的，它充分利用了一门伴随科学的成果。科学成果必须成熟和丰富到能够建模实际问题。这些知识也必须以对实践者有用的形式组织起来。”2然而，自从她的文章发表以来，软件工程界在构建支持真正的工程学科所需的科学结果方面几乎没有取得进展，它仍然停留在“直觉和积累的经验”阶段。同时，软件在现代生活中变得至关重要，人们认为软件比支撑它的工程方法的保障更可靠。
肖在文章的结尾说：“好的科学依赖于研究者和实践者之间强有力的互动。”然而，文化差异、无法访问大型且复杂的系统，以及完全难以理解这些系统，都干扰了支持这些交互的交流。同样，对如何将研究结果转化为生产环境的有用元素的理解不足，阻碍了研究界研究结果的采纳……简单地说，如果能够培养学术界和工业界之间的建设性交互，那么软件的工程基础将发展得更快。”3
在2013年由计算机协会（ACM）主办的“系统、编程、语言和应用：服务人类的软件”（SPLASH）会议上，一位名叫格雷格·威尔逊（Greg Wilson）的程序员发表了题为“两个独行侠”的主题演讲，讨论了软件学术界和工业界之间的这种分歧。在做了一段时间的程序员之后，威尔逊发现了里程碑式的书籍《代码大全》（Code Complete），这是第一批尝试解释软件工程实践的书籍之一，也是少有的关于软件实践研究的书籍之一。威尔逊意识到他以前不知道这一切，正如他在演讲中所说的：“我怎么不了解我们熟悉的事情呢？”4后来他意识到他的同事跟他一样，而且，他们对自己的这种无知很满足，也不想多学点东西。他还评论说：“参加软件工程国际会议的人中，不到20%来自工业界，而且大多数人在微软研究院这样的实验室工作。相反，只有少数的研究生和一两个富有冒险精神的研究人员参加大型的工业会议，比如年度敏捷大会。”5
对软件工程的焦虑这一术语自50多年前被发明以来就一直存在。本书不会提出解决方案，虽然我在最后给出了一些建议，但本书将尝试提供软件行业从早期到现在所经历的路线图。
除了几章以外，其他章节是按时间顺序编排的，始于1980年左右，大致与我作为一名程序员的经历平行。本书并没有尝试给出软件行业的完整历史，相反，它深入挖掘了一些特别重要和具有代表性的特定时刻。这些时刻包括一系列号称可以一并解决程序员面临的所有问题的想法，这些想法在还没有不可避免地回到现实时就被下一件大事取代了。与此同时，学术界和工业界之间的鸿沟不断扩大，使得每一个新的想法在研究中都不那么持久，而软件则进一步远离而不是更接近玛丽·肖希望的工程基础。
从根本上讲，本书是关于一个我经常问自己的问题：是软件开发确实太难，还是软件开发人员能力不足？
最后，提醒一下不喜欢技术细节的读者：本书含有一些代码。不要惊慌。如果不了解程序员在想什么，就不可能了解软件行业；而如果不深入了解程序员编写的实际代码，就不可能了解程序员在想什么。好软件和差软件之间的区别可能就是一行代码—一个程序员做出的看似无关紧要的选择。要理解软件中的某些问题，需要对代码有足够的理解才能明白，以及为什么程序员编写了糟糕的代码，而不是优质的代码。
所以请阅读代码吧！非常感谢。
注释
1. Mary Shaw, “Prospects for an Engineering Discipline of Software,” IEEE Software 7, no. 6 (November 1990): 16, 18.
2. 同上，21页。
3. 同上，24页。
4. Greg Wilson, “Two Solitudes” (keynote address, SPLASH 2013, Indianapolis, IN, October 30, 2013), accessed December 18, 2017, https://www.slideshare.net/gvwilson/splash-2013.
5. Greg Wilson and Jorge Aranda, “Two Solitudes Illustrated,” December 6, 2012, accessed December 18, 2017, http://third-bit.com/2012/12/06/two-solitudes-illustrated.html.

计算机\程序设计

Adam Barr将他数十年来在软件行业中的实战经验集结于书中，字字珠玑，文风幽默。对于业内程序员来说，本书将帮助他们更加从容地应对日常工作的挑战；对于对软件感兴趣的外行来说，本书将帮助他们了解软件是如何形塑这个世界的。
——Scott Rosenberg，Axios的技术编辑，《Dreaming in Code》的作者

本书对高校教师和程序员都很有价值。书中深入研究了软件的复杂性和软件开发的问题，讨论了多种编程语言和方法的特点以及优缺点，帮助程序员理解如何构建高质量的软件。作者提供了许多例子，其中许多来自他自己丰富的经验。软件工程专业确实面临着很多问题，如毕业生的专业能力欠缺、创新意识淡薄等，本书给出了难得的解决方案。
——Victor Basili，马里兰大学计算机科学系荣誉退休教授

关于如何编写好软件的书已经太多了，本书另辟蹊径，通过丰富的实证资料讨论了为什么存在那么多糟糕的软件。既然我们知道了问题所在，也许就能找到解决办法。那些拥有软件工程和计算机科学背景的人一定会发现本书的价值所在。现在真正的问题是：为什么我上学的时候没有读到这样的好书呢?！
——Scott Hanselman，Open Source .NET的高级项目经理，Hanselminutes Tech Podcast的主办人

现代社会越来越依赖于软件产品，现代人的生活就像离不开电力一样离不开软件。另外，软件作为一种有别于普通商品的人类智能产品，很容易包含平时在外表上或者功能上不易显现的瑕疵或者缺陷，业内一般将这类瑕疵或者缺陷称为bug。软件bug在一定条件下被触发后，轻则使软件不能完成预期功能，打乱人们的工作和生活秩序，重则造成重大财产损失，甚至危及用户的人身安全。
为什么软件容易包含bug？为什么软件的生产如此困难，以至于人们难以预测开发所需的时间，造成软件发布延迟甚至被迫取消发布？为什么软件的生产不能像其他商品的生产一样，按照某种标准流程来确保商品质量和生产周期？
软件工程其实并没有多少“工程”的成分，这已经是公开的秘密了。自计算机诞生以来，特别是20世纪60年代大批软件问世之后，围绕软件的种种问题一直伴随且困扰着从事软件生产和研究的人们。本书对这些问题做了深入细致的分析和探讨，并提出了诸多实用且可行的建议。作为一名在微软工作超过20年的资深软件工程师，亚当·巴尔指出了造成当前软件工程困境的诸多因素。一方面，在大学里，学生并没有学到在团队中如何编写便于后续维护的软件，他们在大学里完成的软件作业仅达到了课程项目的要求，却与业内软件开发的实际规模和真实复杂度完全脱节；另一方面，在工业界，靠自学成长起来的一代聪明的程序员习惯于凭自己的直觉和经验来解决问题，他们相信软件必然会包含bug，但这些包含了bug的软件照样可以带来巨大财富，这些根深蒂固的观念导致工业界缺乏改进软件工程的动力。针对这一现状，巴尔提出了一些可行的建议。例如：在大学里让学生学习最新的知识，编写易于理解的代码，阅读和使用更大型的软件；工业界应加强与学术界的合作，推进软件工程的学术研究，特别是实证研究。巴尔认为，随着软件的消费方式由套装软件逐步转向云服务，软件工程将迎来更光明的前景。
在阅读本书的过程中，我们与作者有同样的感慨：为什么学校没有教授学生那些已经存在的重要知识？为什么人们在重复发明轮子上浪费了如此多的时间和精力？作者对软件发展的细致分析表明，软件发展历史上积累的知识或许比我们想象的还要多得多，这些知识对于学术界和工业界来说是一笔宝贵的财富。无论是对于改进软件生产过程还是对于开发更可靠的软件来说，这些知识都具有非同寻常的指导意义。
本书的翻译得到了许多同行的支持，感谢孙榕舒编辑的工作，使得译文清晰顺畅了许多！限于译者水平，译文中难免出现疏漏和错误，欢迎大家批评指正！

译者
2019年6月于中山大学东校区

译者序
前言
致谢
第1章　早期的日子 …… 1
第2章　程序员接受的教育 …… 32
第3章　软件的层次 …… 62
第4章　夜晚的小偷 …… 94
第5章　做正确的软件 …… 132
第6章　对象 …… 162
第7章　设计思维 …… 197
第8章　你最喜爱的程序设计语言 …… 230
第9章　敏捷开发 …… 272
第10章　黄金时代 …… 309
第11章　未来 …… 331