软件工程，“我们不一样”？

“软件工程”是个老话题了，我以前写过一篇文章《名不副实的“软件工程”》，当时还引起了不小的争议。回头看，当时更多的思考还是在“软件工程”本身。我们完全可以把讨论的范围扩得更大一些：“软件工程”和“工程”有关吗？如果有，到底有多大的关系？（这里的“软件”泛指IT的各种开发，不存在“软件”和“互联网”的分别。）

不要以为这些问题很好回答。在大学里，“计算机/软件开发”专业到底属于理科还是工科？似乎一直没有明确答案。到了社会上，一说起“计算机/软件”，很多人都觉得它既不同于文科，也不同于传统的“工程”（硬件）。

那么，“软件工程师”和“程序员”究竟有什么区别？似乎一直也没有人说清楚，只是名称不一样。就我所知，不少搞软件开发的人认为，软件是全新的领域，应当有全新的知识体系和工作范式，所以学校教育根本没啥用。甚至，有些人在内心看不上传统的工程人员，认为那都是“夕阳行业”的过时经验。

“软件工程”真的有这么特殊，可以大喊“我们不一样”吗？中国历史上有过“白马非马”的辩论，“软件工程”和“工程”之间也是这种关系吗？

下面结合软件工程，讲几个“传统”工程的故事。如果你也好奇“软件工程”和“工程”的关系，相信可以得到启发。

工程与理论

在软件开发的行业，大家争论不休的问题之一是：数学对于软件工程师到底重要还是不重要。或者更泛化一点：数学、算法、计算机体系结构等理论知识，对于软件工程师到底重要还是不重要。

许多人的答案是“不重要”，并且有现身说法：你看我，工作这么多年，学校学的东西早都忘记了，我不是一样在写代码，交付各种业务功能吗？没有理论，并不影响我工作。

说“重要”的也有许多人（我也在内）。理由是：软件虽“软”，背后却是有严密的逻辑体系做支撑的。如果凡事都要靠经验、靠试验去得到结论，那么成本未免也太高了。

这里不争论这个问题，我们看看土木工程的故事。

1742年，教皇本尼迪克特十四世（Benedict XIV）需要派人诊断罗马圣彼得大教堂拱顶出现的裂纹。传统上，这种事情总是要找建造经验最丰富的工匠。但是这次不一样，教皇把任务指派给了三位数学家，其中一位还曾编辑和注释过伊萨克·牛顿的《自然哲学的数学原理》。

在那个年代，三位数学家的诊断方法和结论都引发了巨大的争议，因为这违背了无数工匠的经验和直觉，他们都积累了丰富的建筑经验。按照三位数学家的结论，拱顶的箍环承受不了水平的推力，必须新增三个带链条和铁钉的铁环，才能确保建筑的完整。

最终，三位数学家的建议被采纳了。今天如果你去罗马，仍然可以看到完整的圣彼得大教堂。

土木工程师兼历史学家斯特劳布评论说：这份报告在土木工程史上有划时代的意义……重要性在于，与所有的传统和常规相反。从此，所有人都明白了，对建筑结构的稳定性的勘测，不应该建立在经验规则和静态感觉的基础之上，而是应当基于科学的分析和研究。

从此大家也相信，建筑不再是一门“手艺”，要想建造更复杂、更伟大的建筑，谁也离不开科学和研究。今天，如果土木工程师开展工作不依照模型、理论、计算，而是完全按照经验和直觉，哪怕他的经验再丰富，也不能称为“工程师”。

工程与规模

在软件开发行业，“规模”其实是绕不过去的话题。

今天仍然有许多工程师，对“工业开发”的理解就是“改改网络上现成的示例代码”，以及“写一段在本地运行没有问题”的代码。软件开发人员跟人吵架时有句著名的托词：“你看，在我这是好的”，这可以算是背后的心理根源。

实际上，“在本地运行，实现指定功能，得到正确结果”的代码很容易。同样的功能，要在成千上万台服务器上运行，每天运行成千上万遍，挑战就截然不同。这种挑战极富技术含量，值得特别重视。

不信的话，让我们换个角度，看看化学工程的故事。

19世纪直到20世纪早期，德国的化学工业都是相当发达的，远远领先世界各国。这是化学工业的早期，在这个阶段，把化学反应从实验室按比例扩大到工业生产的工作，是由与机械工程师合作的化学家完成的。对德国人来说，这种合作方式相当满意，部分原因在于，他们精通复杂产品。这些复杂、专业、高价值的产品，需要复杂的化学知识，而不是科学技术。用途也限于高价值领域，所以规模并不是问题。

据统计，德国1913年一共生产了13.7万吨染料，涵盖上千个品种，其相对高昂的价格能够带来足够的收益，足够让德国的化工企业维持运转。

作为对比，在同一年，美国仅硫酸就生产了225万吨。美国的化学工业，考虑更多的不是如何精工细作，而是如何利用已有的化学知识，借助更多的工程技术，按比例扩大到巨大的生产规模。

于是，工业化学家诞生了。他们不是把每种生产看成一套单元，而是将其解析为多个构成部分，并根据其效用概括出一般结论。许多具体的操作，例如增压和蒸馏，并不属于严格意义上的化学领域，也受到了当时一些“化学家”的鄙视。但是，化学工程师对此毫不在乎，坚持认为这些问题值得科学家关注，因为这些单元操作是化学反应从实验室规模跃升到工业水平的主要难关。从中暴露出来的各种问题，恰恰是化学工业需要面对和重视的。

1923年，沃克、刘易斯、麦克亚当斯在《化学工程学原理》中写道：所有重要的单元操作都有许多共通之处，如果领会了理性设计和操作基本类型的工程设备所取决的内在原理，那么它们能成功应用于制造工业流程，就不再是碰运气的事情了。

培养工业化学家、发展化学工程学、追求规模的结果是，美国的化学工业迎头赶上，甚至超过了德国。今天，众多国际知名的化工和制药企业都位于美国。

工程与用户

软件工程师和用户之间的矛盾，能引发经久不息的讨论。

矛盾的场景往往大同小异：软件工程师抱怨用户智商太低、知识太少、脑子转得慢、看不懂说明书，所以玩不转高科技的系统；用户抱怨软件工程师不说人话，做出来的系统不人性化，不符合直觉。

其它行业的工程师也会遇到这样的问题吗？他们是如何解决的？我们看看船舶工程的故事。

人类很早就发明了用来掌控船舶前进方向的船舵。哪怕是没有操船经验的人，也很容易感觉到船舵的操作和船舶前进方向之间的关系。稍微加以训练，就可以基本掌握船舵的操作，保持船舶前进的稳定性。

但是在蒸汽船兴起之后，麻烦出现了。对于排水量达到几千吨的船只，靠手工转动船舵已经难以为继，当时的军舰在全速行驶时，仅仅转动扳动船舵就需要上百人。借助蒸汽的力量转动船舵当然是很容易的事情，但仅仅机械地“转动船舵”是不够的，因为蒸汽不懂得舵手的意志，舵手也没法获得直观的反馈，精确船舶前进方向就成为空谈。

船舶工程师们不能抱怨舵手“不懂技术、跟不上时代”，强迫他们“必须学习”，而是必须想出办法，让船舵能够聪明、灵敏地响应舵手的操作，不能机械死板地摆动。

1866年，苏格兰工程师麦克法兰·格雷（J. Macfarlane Gray）发明了具有反馈控制功能的操舵引擎（Steering Engine，今天叫“舵机”）并获得了专利。这种发动机率先安装在排水量18915吨的Great Eastern号上，其控制机械能精确跟踪、匹配舵轮的变化，根据船舵的反馈持续修正。有了舵机，舵手才能真正操控船舵，准确把握船只的前进方向。

这种大获成功的自动控制器被称做“伺服机构”（servo mechanism），其名称源自拉丁文servo，意思是“奴隶”或者“仆人”，它不只是机械执行操作者的意志，而是可以形成闭环，根据实际情况不断反馈修正，确保实现使用者设定的目标。今天，伺服机构已经被广泛应用于各种设备。今天的每一台数码相机上，你都可以找到“伺服”对焦模式。

工程与生产

我不知道有多少软件工程师真正去过生产线，但我记得我第一次去到生产车间的感受。

面对着生产线、工位、SOP、物料管理……，我感到震撼。以前我总觉得软件开发复杂，但现实的生产一点也不比软件开发简单。尤其是看到自己开发的软件被一线用户真正实用的时候，之前的各种不理解、委屈、抱怨，似乎全都泄了气。从此我深刻理解了，“深入生产一线”到底是什么，它有什么用。

其实不只对软件工程，对任何高科技工程来说，“深入生产一线”的重要性，怎么强调都不为过。作为例子，我们可以看看航空工程中的故事。

在航空业大名鼎鼎的“臭鼬工厂”（Skunkworks）是洛克希德公司高级开发项目的官方绰号，由著名飞机设计师克里·约翰逊（Kelly Johnson）创立于1943年。臭鼬工厂以担任秘密研制任务著称，先后研制了升限2.4万米的U-2高空侦察机、空速3马赫的SR-71侦察机、史上第一架隐身轰炸机F-117等著名飞机。

臭鼬工厂研制出这么多了不起的飞机，当然聚集了一批了不起的工程师。这些工程师是不是”关起门来攻关“呢？不是。按照约翰逊的规定，工程师在设计过程中，每一个步骤都必须经过反复的商讨和推敲。一旦工作中遇到问题，他们需要与试飞员、机械车间工人、管理人员紧密合作，共通面对。

约翰逊还为臭鼬工厂设定了若干基本规则，其中有两条是：第一，工程师应当守候与机械车间不应当超过“扔石头能打到的距离”；第二，“坏消息传到高层的速度必须和好消息一样快”。在实际工作中，这两条规则执行得相当好，设计工程师每天上班至少要花1/3的时间在生产车间待命。

不同职能、不同团队的紧密协作，呈现出强有力的团队面貌和高度激励精神，也形成了多学科、系统化的工作方法，将行政管理上的官僚作风减少到最低限度。员工不会在移交工作之后推卸责任，而是在移交之前拼尽全力。

这样工作的结果不难想见，突出的例子是F-117。“臭鼬工厂”的F-117隐身轰炸机因为造型太过怪异，一度被行业人士判断”飞不起来“，事实证明，F-117的性能完全满足设计需求。

工程与成本

有多少软件工程师会考虑成本问题？似乎相当部分的软件工程师没什么成本意识。

相当多的软件工程师在乎的是，写下代码，用代码去实现功能。如果说成本，可能最先想到的是人工成本，也就是写代码的时间。至于其它方面的成本，比如运行的资源消耗、维护的难易程度，愿意考虑的人并不多。

作为对比，在传统工程领域，合格的”工程师“大都明白，工程和科学之间的差别。科学问的是”是什么“和”为什么“，工程问的是”为了什么“、”怎样实现“、”评价好坏的标准是什么“。正因为这三个问题对工程相当重要，合格的工程师一定清楚意识到，在实现目标价值的情况下，成本越低越好。航天工程的例子，正可以作为注解。

20世纪60年代，美国政府在航天领域持续投入巨资，先后进行了”水星“、”双子星“、”阿波罗“计划，将人类送上月球。然而，即便是有天量投入为支撑，航天工程中仍然要时时秉承”节约“的原则。

在阿波罗登月计划中，指令舱隔热罩的材料遇到了巨大挑战。在太空中，它朝向太阳的一面炽热，背向太阳的一面极冷，重返大气层时还需要经受极高温的考验。如何设计才能解决这个问题，工程师陷入了深深的思索。

最终，工程师们没有发明某种特异的复杂材料，而是让指令舱每小时绕自转轴旋转一周。在登月往返中，指令舱始终保持这种”翻转烤肉“的模式，利用太阳的热量有规律地烘烤，所以再不用考虑低温的考验。

尽管航天工程花费巨大，这种”节约成本“的例子却比比皆是。2003年”哥伦比亚“号航天飞机在返航中失事，事后确认原因是：发射升空过程中，脱落的隔热瓦撞破了飞机机翼，在重返大气层过程中，炽热的气体灌入飞机内部，最终导致解体。

怎样发现机身的破损？工程师的办法并不是给航天飞机全身装上破损检测传感器，而是在返航之前新增一项检查：航天飞机在返航之前，必须在太空做360度转体，由太空望远镜或空间站观测，确认机身没有破损。

工程与人

“软件工程师”对普通人来说，是怎样的形象？

看看周围的媒体就知道，“软件工程师”（或者叫“程序员”）已经形成了相对固定的刻板印象：木讷、无趣、不善交际、缺乏趣味。软件工程师似乎默认了这种印象，在自己的亚文化圈子中寻找共鸣。

这种现象，是软件工程师独有的吗？看看工程学的发展就会清楚，“吾道不孤”。

今天的许多人，无论怎么看工程师，至少都会归类到“有知识的人”里。但是在历史上，“知识”很长时间里等同于文学、历史、艺术，与今天大家所说的“知识”有很大不同。

所以，工程师的先驱者们大多都是自学成才的。他们大多来自社会底层，出身学徒，凭借好奇心和兴趣，孜孜不倦地学习，从“工匠”升华为“工程师”。制造了蒸汽机车的斯蒂芬森是这样，建造了埃迪斯通灯塔的斯米顿是这样，爱迪生也是这样。

因为出身底层，难入上层阶级法眼，又清楚学习交流对于促进理解、启发灵感的作用，工程师们只能自己创建职业协会。英国土木工程师协会成立于1771年，机械工程师协会成立于1846年，德国也在1856年成立了自己的工程师协会，带动德国综合技术学校率先上升到大学地位。

行业协会的兴起，逐步产生了“工程”专门教育的需求。于是，理工科大学也诞生了。突出的例子就是1794年成立的巴黎综合工科学校，不仅在工程技术上，而且在一般科学上都是教育突破。在这里，最优秀的科学家、工程师教授聪明的年轻人各种工程知识。拿破仑甚至希望，在遇到重大危机的紧要关头，也不要让学生卷入战斗，因为这是“下金蛋的鹅”。

工程技术的飞速发展，重要性不断提升，改变了普通人的生活，也打破了社会原有的格局。作为回应，原有的“轻视”变成了敌视。工程师们，大概只有两种形象：一种是科学怪人弗兰肯斯坦，一种是书呆子、极客。他们不懂高雅艺术、不懂审美、没有情趣、缺乏交流……

这种印象能站得住脚吗？起码工程师们是不赞成的。麻省理工学院工学院创始人威廉·罗杰斯（James Henry Williams, Jr.）在创建新学院的建议中说：

我们提供的教育，虽然就其目的而言价值非凡，但与那种只按经验惯例进行的教育没什么关系；而经验惯例式的教育，有时被吹嘘为对要从事实业来说最合适的教育。相反，我们认为，大多数真正实用的教育，即便按照实业的观点，也是一种建立在透彻的科学定律与原理的知识基础上的，而且是一种将缜密观察、精确推理结合起来的教育，是一种全面的综合素养。

不只麻省理工学院，已经有越来越多的工程师意识到，工程绝不是冷冰冰的、机械的产物，它一脚踩在科学领地，一脚踏进社会万象。过分强调一条腿，忽略另一条腿，都是非常危险的。

其实，古代的工匠就已经懂得这个道理，充分懂得并重视人的因素。

古希腊建筑大师卡里克拉特要小心翼翼地挑选雅典城墙的承建者，因为他知道城墙的建筑并不是简单机械的劳动。这个故事给普鲁塔克留下了深刻的印象，在《希腊罗马名人传》里专门记载。写下不朽的《建筑十书》的古罗马建筑大师维特鲁威更是明确说，建筑师如果要正确设计建造屋檐和下水道，就必须熟悉城市制定的各种法律法规，懂得并且重视和商界、政界打交道。

现代的优秀工程师也不会忘记这点。普林斯顿大学航天工程毕业，先后在道格拉斯飞机公司担任研究工程师、总工程师，之后任洛克希德·马丁公司CEO的诺曼·奥古斯汀（Norman R. Augustine）曾经说过一句话，得到了众多工程师的认同：合格的工程师，必须能像处理重力和磁力那样熟练处理社会的和政治的力量。

我知道不少软件工程师都喜欢称自己为“手艺人”，都喜欢讲“三个石匠“的故事——同样在干活，“混饭吃”的石匠一生都在混饭吃，“想做最好石匠”的石匠大概获得了点名声，“造大教堂“的石匠最终功成名就。

我以前也喜欢讲这个故事，很动听，但也很给人安慰。后来我终于发现，这个故事的问题就在于，它太简单了：从来没有人告诉过第三个石匠，要想造大教堂，可不能专心当石匠，你还得学习很多其它的技能，比如画图、计算、选材、算账、砍价、了解天气和气候、排生产计划、检查质量、化解冲突……