周六把《梦断代码》（Dreaming in code）看完，一直在思索这本书的主题是什么，想了半天也没有头绪。翻到书一开始的《作者的话》，看到这么一句：「它提出问题，讲述故事」，啊哈，确实如此，作者回避给任何问题一个标准答案，甚至一点倾向都没有，以一个中立的观察者来讲述故事。好的书不仅在于传递知识或观点，更重要的是引发思考。这正是我给本书五星的原因。
整本书主线在描述Chandler项目的故事，不断从项目的各种现象中挖掘软件开发中的各种问题，并旁征博引其他项目的故事，罗列大家对问题的各种观点和方法，但是几乎所有提到的问题直到今天都没有明确的结论，比如卡普尔和卡兹维尔的对赌：2029年会不会有计算机通过图灵测试。 而最核心的问题：
「软件开发是否能找到一个通用的过程和方法，软件开发者是工程师还是艺术家」，总结了软件开发过程中无数细节问题。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计，所有的书中能找到的只有模糊的建议，以经验性方法为主导。估算工期的方法叫「拍」，拍大腿抑或拍脑袋。无论是代码风格还是项目形态都千奇百怪，毫无定型，与传统的工程行业相去甚远。 这本书隐约夹杂着一种无力又沮丧的情感。虽然成书之时Chandler项目还在继续，但是直到现在也没能推出能用的产品，项目可以说是完全失败了。而项目中遇到的种种问题，作者也没有答案。
为什么不能像造桥一样开发软件？
造桥和软件开发的区别在哪？扯一些自己的理解。软件开发领域惊人的熵，一方面因为其所面向问题域的范围广泛，另一方面在于软件本身技术的高速进化发展，这两方面相互推动。 桥梁工程、建筑工程以及其他传统工程行业发展至今，面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。1000年前的桥现在还在使用，而我们写的软件能用多久，10年、5年还是3个月？按现在互联网行业的状况，如果一年不做更新就被市场淘汰，10年之后，估计都找不到能运行程序的环境。 计算机技术近20年的发展速度有目共睹，从硬件到软件，技术更新换代速度之快，任何行业都望尘莫及。如今绝大部分的建筑都是钢筋混凝土结构，而常用的通用编程语言不下10种，各类编程框架更是数不胜数，并且在不断改进，如此对比可见一斑。何况写代码只是软件工程的内部方法，横向来看，软件工程的内部问题包括编程语言、计算理论、控制论、系统工程、人机交互等等。这样来看，软件开发中遇到的问题，一方面是对问题域的理解和抽象的问题，另一方面是对软件开发技术本身的理解。软件工程团队，需要应对这两种难题的杂糅，难上加难。 能不能像造桥一样写软件的问题，现在被细化分解成了两个问题：
- 软件工程的问题域什么时候能够收敛？
- 软件技术本身何时能够稳定？
对于第一个问题，可以预见的是，软件工程会和智能芯片一起，逐渐渗透到人类生活的方方面面，所以软件工程的问题域不断扩大，完全没有收敛的趋势。也许不把软件工程理解成一种特定的工程领域，而是当做别的工程领域中解决问题的工具可能会更合理一些（这和数学有些类似）。
对于第二个问题，目前软件工程也许正好处在一个这样的阶段，刚刚兴起，发展迅速，体系模糊，过一段时间就会稳定。但是我觉得在可预见未来，软件工程技术会不断发展、细化，会越来越复杂。
软件工程中种种的不确定也许令人沮丧。但是话说回来，我热爱计算机，热爱编程，热爱互联网，不正是因为种种未知和不确定性带来的挑战吗。在这样的环境里，没有办法偷懒，没有办法按部就班、循规蹈矩；在写代码做设计的时候，可以自由运用想象力、逻辑思维和审美抽丝剥茧，寻找用优美的代码、简洁的设计实现繁杂的业务逻辑的方法；不断地通过challenge myself获得动力向前走。
我更喜欢「梦中代码」作为这本书的译名。梦未醒，天已明。
One Response to Software Engineering is NOT an Engineering