Computer science is NOT a science, software engine

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

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

所有问题的根本是：
软件开发是否能找到一个合适的方法论
软件开发者是工程师还是艺术家。

这个问题，总结了软件开发过程中无数细节问题，这些问题统统没有答案。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计，只有模糊的建议，以经验性方法为主导，估算工期的方法叫「拍」，拍大腿抑或拍脑袋。从代码到项目形态无不千奇百怪。

这本书隐约夹杂着一种无力又沮丧的情感。虽然成书之时Chandler项目还在继续，但是直到现在也没能推出能用的产品，项目可以说是完全失败了。项目中遇到的种种问题，至今也没有答案。



扯一些自己的理解。到底为什么不能像造桥一样开发软件？造桥和软件开发的区别在哪？软件开发领域惊人的熵，一方面在于所面向问题域的范围广泛，另一方面在于软件本身技术的高速进化发展，这两方面相互推动。

桥梁工程、建筑工程以及其他传统工程行业发展至今，面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。1000年前的桥现在还在使用，而我们写的软件能用多久，10年？按现在互联网行业的状况，如果一年不做更新就被市场淘汰，10年之后，估计都找不到能运行程序的环境。

计算机技术近20年的发展速度有目共睹，从硬件到软件，技术更新换代速度之快，任何行业都望尘莫及。如今绝大部分的建筑都是钢筋混凝土结构，而常用的通用编程语言不下10种，各类编程框架更是数不胜数，并且在不断变化，如此对比可见一斑。何况写代码只是软件工程的内部方法，横向来看，软件工程的内部问题又包括计算、控制论、系统工程、人机交互等等。

这样来看，软件开发中遇到的问题，一方面是对问题域的理解和抽象的问题，另一方面是对软件开发技术本身的理解。软件开发团队，需要同时应对这两种难题

能不能像造桥一样写软件的问题，被细化分解成了两个问题：
软件工程的问题域什么时候能够收敛？
软件技术本身何时能够稳定？

这又是两个无法作答的问题。。。挫败感顿起

或许软件工程正好处在一个这样的阶段，刚刚兴起，发展迅速，体系模糊。亦或者软件工程并不是一种工程，它只是别的真正的工程领域中解决问题的工具。不过这个工具很复杂，材料是代码，建造方法是计算、系统工程和人机界面。Who knows.