Software Engineering is NOT an Engineering

dreaming-in-code 周六把《梦断代码》(Dreaming in code)看完,一直在思索这本书的主题是什么,想了半天也没有头绪。翻到书一开始的《作者的话》,看到这么一句:「它提出问题,讲述故事」,啊哈,确实如此,作者回避给任何问题一个标准答案,甚至一点倾向都没有,以一个中立的观察者来讲述故事。好的书不仅在于传递知识或观点,更重要的是引发思考。这正是我给本书五星的原因。

整本书主线在描述Chandler项目的故事,不断从项目的各种现象中挖掘软件开发中的各种问题,并旁征博引其他项目的故事,罗列大家对问题的各种观点和方法,但是几乎所有提到的问题直到今天都没有明确的结论,比如卡普尔和卡兹维尔的对赌:2029年会不会有计算机通过图灵测试。 而最核心的问题:

「软件开发是否能找到一个通用的过程和方法,软件开发者是工程师还是艺术家」,总结了软件开发过程中无数细节问题。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计,所有的书中能找到的只有模糊的建议,以经验性方法为主导。估算工期的方法叫「拍」,拍大腿抑或拍脑袋。无论是代码风格还是项目形态都千奇百怪,毫无定型,与传统的工程行业相去甚远。 这本书隐约夹杂着一种无力又沮丧的情感。虽然成书之时Chandler项目还在继续,但是直到现在也没能推出能用的产品,项目可以说是完全失败了。而项目中遇到的种种问题,作者也没有答案。

为什么不能像造桥一样开发软件?

造桥和软件开发的区别在哪?扯一些自己的理解。软件开发领域惊人的熵,一方面因为其所面向问题域的范围广泛,另一方面在于软件本身技术的高速进化发展,这两方面相互推动。 桥梁工程、建筑工程以及其他传统工程行业发展至今,面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。1000年前的桥现在还在使用,而我们写的软件能用多久,10年、5年还是3个月?按现在互联网行业的状况,如果一年不做更新就被市场淘汰,10年之后,估计都找不到能运行程序的环境。 计算机技术近20年的发展速度有目共睹,从硬件到软件,技术更新换代速度之快,任何行业都望尘莫及。如今绝大部分的建筑都是钢筋混凝土结构,而常用的通用编程语言不下10种,各类编程框架更是数不胜数,并且在不断改进,如此对比可见一斑。何况写代码只是软件工程的内部方法,横向来看,软件工程的内部问题包括编程语言、计算理论、控制论、系统工程、人机交互等等。这样来看,软件开发中遇到的问题,一方面是对问题域的理解和抽象的问题,另一方面是对软件开发技术本身的理解。软件工程团队,需要应对这两种难题的杂糅,难上加难。 能不能像造桥一样写软件的问题,现在被细化分解成了两个问题:

  • 软件工程的问题域什么时候能够收敛?
  • 软件技术本身何时能够稳定?

对于第一个问题,可以预见的是,软件工程会和智能芯片一起,逐渐渗透到人类生活的方方面面,所以软件工程的问题域不断扩大,完全没有收敛的趋势。也许不把软件工程理解成一种特定的工程领域,而是当做别的工程领域中解决问题的工具可能会更合理一些(这和数学有些类似)。

对于第二个问题,目前软件工程也许正好处在一个这样的阶段,刚刚兴起,发展迅速,体系模糊,过一段时间就会稳定。但是我觉得在可预见未来,软件工程技术会不断发展、细化,会越来越复杂。

软件工程中种种的不确定也许令人沮丧。但是话说回来,我热爱计算机,热爱编程,热爱互联网,不正是因为种种未知和不确定性带来的挑战吗。在这样的环境里,没有办法偷懒,没有办法按部就班、循规蹈矩;在写代码做设计的时候,可以自由运用想象力、逻辑思维和审美抽丝剥茧,寻找用优美的代码、简洁的设计实现繁杂的业务逻辑的方法;不断地通过challenge myself获得动力向前走。

我更喜欢「梦中代码」作为这本书的译名。梦未醒,天已明。

This entry was posted in 技术学习 and tagged , . Bookmark the permalink.

One Response to Software Engineering is NOT an Engineering

  1. 李先Loki says:

    回头读一读 现在就指着你的分享了

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据