《梦断代码》（《Dreaming in Code》）读书笔记

《梦断代码》（《Dreaming in Code》）读书笔记

在看了这本书之后，我在豆瓣看到一段书评：做软件难。软件乃是人类自以为最有把握，实则最难掌控的技术。这本书揭示了好多软件开发的根本性问题。

里面有一些给我留下深刻印象的论述：

"Hello World " 程序能够唤醒每个程序员心中乐观的一面。既然能叫它说话，就能让它做任何事！为什么就是不能像造桥那样造软件？造桥和软件开发的区别在哪？软件开发领域惊人的熵，一方面在于所面向问题域的范围广泛，另一方面在于软件本身技术的高速进化发展，这两方面相互推动。桥梁工程、建筑工程以及其他传统工程行业发展至今，面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。

软件开发是否能找到一个合适的方法论

布鲁克斯法

向已延误的项目中补充人力，只会使其继续延误。

布鲁克斯写道，软件开发者通常都是乐天派，他们认定每个缺陷都可以被迅速修正，且修正旧缺陷必能减少新缺陷的数量。

布鲁克斯发现，在实际开发中，编码只占软件项目开发时间的1/6, 有一半时间用于测试和修正缺陷。但只有少数项目经理会真正按照这种思路来安排开发人员的工作时间。

所谓“人月", 是一种科学管理概念，它假定生产力可被拆分为不连续、无差异、可替换的单元。

布鲁克斯观察到，“只有在任务能分派给许多互相之间无须沟通的工作者时，人和月才是可互换品。

“对于软件而言，项目各有差异、工具不断升级，每当团队中加入一个新组员，老组员就得放下手边的工作，帮助新组员进入角色，每位组员都要等待重新分派任务，好让新组员有事可做。在你意识到这一切之前，已经远远落后于进度了。也就是说，每次重新安排进度计划，都导致雇用更多人力，于是又不得不重新安排进度。

制作软件的大量工作受困于“序列约束＂，它限制了任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。

布鲁克斯法则暗示最理想的开发组规模是一个人——无须停下工作与同事沟通的单个开发者。

乐高假设

指未来程序将由可复用的部件组合而成。部件将在全球范围内提供。虽然实际上这种假设不太容易实现，甚至不能实现。做好项目的关键在于复用，而不是重复发明。

祖尔测试

索伯斯基提出了祖尔测试( Joel Test)，基于他自己的经验和“集体智慧＂，给出一套快餐式原则， 判断开发组织是否符合这条原则—— “不会叫人头疼的CMM”。

祖尔测试询问以下十二个问题：

 

1）Do you use source control? 你们使用源代码控制吗？

 

2）Can you make a build in one step? 你们一步就能完成构建吗？

 

3）Do you make daily builds? 你们做每日构建吗？

 

4）Do you have a bug database? 你们有缺陷数据库吗？

 

5）Do you fix bugs before writing new code? 你们会在写新代码之前修复缺陷吗？

 

6）Do you have an up-to-date schedule? 你们有与当前工作吻合的进度安排吗？

 

7）Do you have a spec? 你们有规约吗？

 

8）Do programmers have quiet working conditions? 程序员工作环境安静吗？

 

9）Do you use the best tools money can buy? 你们采用了市面上最好工具吗？

 

10）Do you have testers? 你们有测试人员吗？

 

11）Do new candidates write code during their interview? 你们会要求应聘者在面试时写代码吗？

 

12）Do you do hallway usability testing? 你们做走廊可用性测试吗？

 

“得12分为最佳，“索伯斯基写道， “11分还可以接受，得10分或更低就说明你们问题大了。其实多数软件组织只能得2、3分，他们迫切需要帮助，因为微软等公司一直都得12 分。”

工程师和艺术家

软件开发者是工程师还是艺术家。

这个问题，总结了软件开发过程中无数细节问题，这些问题统统没有答案。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计，只有模糊的建议，以经验性方法为主导，估算工期的方法叫“拍”： 一拍脑袋有了，一拍胸口干了，一拍大腿坏了，一拍屁股走了。往复循环！一地鸡毛！

以前有一篇文章叫“谦卑的程序员”，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。

（一辆车刹车失灵，摔下悬崖，项目经历，硬件工程师和软件工程师的对话：软件工程师说了句，动手开干之前，我想应该把车推回山上，看看事故是否会重现！！！亮了）如果向程序员报告缺陷，他的第一反应是问你：“重现问题了吗？”--意思是说，你能确实让问题重现一次吗？如果答案是肯定的，事情就成了一半；如果是否定的，程序员就会耸耸肩，把责任推卸给硬件或者宇宙射线！ 介个~~~我们遇到bug也先问能不能重现，不过目地多...

  写程序，这句话值得驻足思量。那么编程是工程还是文学？是科学还是艺术？如何解决编程的双重问题成为改领域中许多人的困惑所在。、

  高德纳在1984年获得图灵奖时说：’计算机编程是门艺术‘。艺术是什么，艺术是人类智慧所做之物，相对于源自天然或本能的行为而言。