《名不副实的“软件工程”》 后作

讨论的范围扩得更大一些:“软件工程”和“工程”有关吗?如果有,到底有多大的关系?(这里的“软件”泛指 IT 的各种开发,不存在“软件”和“互联网”的分别)

大学里,“计算机/软件开发”专业到底属于理科还是工科?似乎一直没有明确答案

到了社会上,一说起“计算机/软件”,很多人都觉得它既不同于文科,也不同于传统的“工程”(硬件)

“软件工程师”和“程序员”究竟有什么区别?似乎一直也没有人说清楚,只是名称不一样

不少搞软件开发的人认为,软件是全新的领域,应当有全新的知识体系和工作范式,所以学校教育根本没啥用。甚至,有些人在内心看不上传统的工程人员,认为那都是“夕阳行业”的过时经验

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

工程与理论

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

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

土木工程的故事

诊断罗马圣彼得大教堂拱顶出现的裂纹

传统上,这种事情总是要找建造经验最丰富的工匠。但这次教皇把任务指派给了三位数学家

那个年代,三位数学家的诊断方法和结论都引发了巨大的争议,这违背了无数工匠的经验和直觉,他们都积累了丰富的建筑经验

按照三位数学家的结论,拱顶的箍环承受不了水平的推力,必须新增三个带链条和铁钉的铁环,才能确保建筑的完整

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

这在土木工程史上有划时代的意义……

重要性在于,与所有的传统和常规相反。从此,所有人都明白了,对建筑结构的稳定性的勘测,不应该建立在经验规则和静态感觉的基础之上,而是应当基于科学的分析和研究

从此大家也相信,建筑不再是一门“手艺”,要想建造更复杂、更伟大的建筑,谁也离不开科学和研究

今天,如果土木工程师开展工作不依照模型、理论、计算,而是完全按照经验和直觉,哪怕他的经验再丰富,也不能称为“工程师”


 工程与规模

软件开发行业,“规模”是绕不过去的话题

今天仍然有许多工程师,对“工业开发”的理解就是“改改网络上现成的示例代码”,以及“写一段在本地运行没有问题”的代码

跟人吵架时有句著名的托词:“你看,在我这是好的”,这可以算是背后的心理根源

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


换个角度,看看化学工程的故事

化学工业早期,德国化学工业相当发达,把化学反应从实验室按比例扩大到工业生产的工作,机械工程师与化学家合作完成。

这些复杂、专业、高价值的产品,需要复杂的化学知识,而不是科学技术。用途也限于高价值领域,所以规模并不是问题

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

作为对比,同一年,美国仅硫酸就生产了 225 万吨

美国的化学工业,考虑更多的不是如何精工细作,而是如何利用已有的化学知识,借助更多的工程技术,按比例扩大到巨大的生产规模

于是,工业化学家诞生了

不是把每种生产看成一套单元,而是将其解析为多个构成部分,并根据其效用概括出一般结论

许多具体操作,例如增压和蒸馏,并不属于严格意义上的化学领域,也受到了当时一些“化学家”的鄙视

但是,化学工程师对此毫不在乎,坚持认为这些问题值得科学家关注,因为这些单元操作是化学反应从实验室规模跃升到工业水平的主要难关。从中暴露出来的各种问题,恰恰是化学工业需要面对和重视的

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


工程与用户

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

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

其它行业的工程师也会遇到这样的问题吗?他们是如何解决的?

船舶工程的故事

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

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

工程师发明了具有反馈控制功能的操舵引擎(“舵机”),其控制机械能精确跟踪、匹配舵轮的变化,根据船舵的反馈持续修正。有了舵机,舵手才能真正操控船舵,准确把握船只的前进方向

这种自动控制器称做“伺服机构”(servomechanism),源自拉丁文 servo,意思是“奴隶”或者“仆人”,不只是机械执行操作者的意志,而是可以形成闭环,根据实际情况不断反馈修正,确保实现使用者设定的目标


工程与生产

不只对软件工程,对任何高科技工程来说,“深入生产一线”的重要性,怎么强调都不为过。

航空工程中的故事

航空业大名鼎鼎的“臭鼬工厂”(Skunkworks)

了不起的工程师不是”关起门来攻关“

按照规定,工程师在设计过程中,每一个步骤都必须经过反复的商讨和推敲。一旦工作中遇到问题,他们需要与试飞员、机械车间工人、管理人员紧密合作,共通面对

若干基本规则,其中有两条是:

第一,工程师应当守候与机械车间不应当超过“扔石头能打到的距离”

第二,“坏消息传到高层的速度必须和好消息一样快”

实际工作中,这两条规则执行得相当好,设计工程师每天上班至少要花1/3 的时间在生产车间待命

不同职能、不同团队的紧密协作,呈现出强有力的团队面貌和高度激励精神,也形成了多学科、系统化的工作方法,将行政管理上的官僚作风减少到最低限度

员工不会在移交工作之后推卸责任,而是在移交之前拼尽全力

工作结果,F-117 隐身轰炸机因为造型太过怪异,一度被行业人士判断”飞不起来“,事实证明,F-117 的性能完全满足设计需求

工程与成本

相当部分的软件工程师没什么成本意识

可能最先想到的是人工成本,也就是写代码的时间。至于其它方面的成本,比如运行的资源消耗、维护的难易程度,愿意考虑的人并不多

作为对比,在传统工程领域,合格的”工程师“大都明白,工程和科学之间的差别

科学问的是”是什么“和”为什么“,工程问的是”为了什么“、”怎样实现“、”评价好坏的标准是什么“

阿波罗登月计划,隔热罩的材料遇到了巨大挑战

在太空中,它朝向太阳的一面炽热,背向太阳的一面极冷,重返大气层时还需要经受极高温的考验。如何设计才能解决这个问题,工程师陷入了深深的思索

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

尽管航天工程花费巨大,这种”节约成本“的例子却比比皆是

”哥伦比亚“号航天飞机在返航中失事,事后确认原因是:发射升空过程中,脱落的隔热瓦撞破了飞机机翼,在重返大气层过程中,炽热的气体灌入飞机内部,最终导致解体

怎样发现机身的破损?

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


工程与人

相对固定的刻板印象:木讷、无趣、不善交际、缺乏趣味。软件工程师似乎默认了这种印象,在自己的亚文化圈子中寻找共鸣

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

因为出身底层,难入上层阶级法眼,又清楚学习交流对于促进理解、启发灵感的作用,工程师们只能自己创建职业协会

英国土木工程师协会成立于 1771 年,机械工程师协会成立于 1846 年,德国也在 1856 年成立了自己的工程师协会,带动德国综合技术学校率先上升到大学地位

拿破仑甚至希望,在遇到重大危机的紧要关头,也不要让学生卷入战斗,因为这是“下金蛋的鹅”

不少软件工程师都喜欢称自己为“手艺人”,都喜欢讲“三个石匠“的故事

同样在干活,“混饭吃”的石匠一生都在混饭吃,“想做最好石匠”的石匠大概获得了点名声,“造大教堂“的石匠最终功成名就

这个故事的问题就在于,它太简单了:从来没有人告诉过第三个石匠,要想造大教堂,可不能专心当石匠,你还得学习很多其它的技能,比如画图、计算、选材、算账、砍价、了解天气和气候、排生产计划、检查质量、化解冲突……