梦断代码读后感

红太狼 2022-12-30 13:49 121阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjcyNzcw_size_16_color_FFFFFF_t_70][]

这本书的开头章节是零，在软件人的脑子里，总是以零为一段自然数的开头，因为计算机从开始计数！

于是，我睁大了眼睛，又返回去从第0章再次阅读；

一段话击中了我：

“hellow world"程序一无所用，但足以 蛊惑人心；

多少软件项目雄心勃勃，最终却未结善果。                         ------------ 经历一学期的磨练之后，对此话深有感触。

书以chandler项目的诞生开头，以chandler项目的落幕而结束，

一代软件人的辛酸绝望，犹如撞上冰山的泰坦尼克号，缓缓沉没在无尽的深渊。

这本书读起来很顺畅，不用像一般技术书籍理解，可以当小说看。书中一开始就吸引了我的兴趣，明显描述的就是日常经常碰到的工作场景，真想知道这些技术大牛们日常开发会不会也像我们一样。看了几章后发现，虽然这些技术大牛们开发的项目目标比我们伟大多了，但是日常开发遇到的问题也大同小异，需求不明确，人员流失，沟通不顺畅,bug难修复等等。

看完这本书，有一些小故事想分享一下。

故事一：**死定了**。 开头以托伊的Chandler项目落后进程，解析了Chandler落后项目的原因，项目本身的缺陷修改问题，典型的提示框闪烁问题，同时延伸出导致软件时间问题诊断《人月神话》，讲述当项目处于尴尬的地步的时候增加人手只会将项目带入更加糟糕的情况。还简述了“开源时代”，并以托伊对Chandler项目失败的总结结尾。某位开发人员计划**修改这个闪烁bug**，需要4小时，但是实际上8个小时也没做出来，甚至给他8天也解决不了。文中提到的这个bug最终被解决是在几个月后。有时候修改这种棘手的bug正的像这位开发人员所说：有时候，你一觉醒来，脑中灵光闪现，于是手到擒来--大抵如此。

故事二：**开发模式的选择**，书中提到了“大教堂与集市”这本书，大教堂的模式可以说是传统的开发模式，而集市模式被很多开源项目采用,比如Apache Web服务器,Linux。咱们一般开发自然用的是大教堂模式了。

故事三：**历史上有很多失败的项目**，例如FBI耗资1亿7千万美元，为了提高反恐能力的计算机项目失败，失败原因是FBI受到９／１１事件的刺激把需求列表陡然拉长。美国国内税务局至今用的系统是20世纪60年代开发的，在95年曾试图升级，花费了20亿美金后，国会取消了这个失败的项目，失败原因：需求不断改变，预算和进度安排不切实际等。04年英国养老金系统全面停止运作，事故原因是：在把７台window 2000升级至window XP时，不小心把升级范围扩展到数千台没准备好的机器上。所以，如果你正在做的项目失败了，别太气馁，你不是第一个，也不是最后一个。

故事四：**项目语言的选择**。书中提到的项目经过了大家无数次的讨论，最终决定使用：Python。但是在项目的后期，另外一个Python高手加入后，曾经隐晦的说过，其实大家在用编写Java代码的方法编写Python。这让我想起，虽然大家都说其实语言是相通的，如果你一门语言很熟练了，其他语言也大同小异，但是毕竟每个语言都有自己不同的特性，所以项目组有机会选择语言的话，最好还是考虑一下开发人员对哪种语言最熟练。

故事五：**以时间来驱动版本的发布**。书中提到项目的0.2版是一个很烂的版本，但是还是发布了，因为承诺的发布时间到了。虽然书中的项目组汲取这次的教训，不再以时间来驱动，但是我觉得用时间驱动版本发布是一种比较有效的方式，它让开发人员有一个奋斗的目标，尽快完善自己的开发模块。

故事六：**GTD（get things Done）**,是一本书的名字，这本书的中心思想是让大家把所有要做的事情写下来，让脑子清空。我觉得这种方式不错。一次，我觉得事情太多，有点烦躁不安，不知道该从哪件事入手去做，后来想到这个做法，就把脑子里想的事情全部写下来，然后再一件一件来做。

故事七：**吃狗食**。意思就是使用自己开发的系统。在使用过程中，你会发现很多测试人员也没测到的问题。

故事八：**CMM，软件成熟度模型**。这是在80年代的时候，软件大牛们深感软件问题重重，为了帮助规模庞大的组织改进软件进度和质量制定出来的方法论，用来指导软件开发过程。现实状况是，美国国防部用CMM测量承包商的组织力量，很多印度公司都拿到了CMM3级及以上认证。因为CMM太过复杂，庞大，读完CMM的整个文档需要花费你一生的时间，后来大家才针对它提出敏捷式开发。

故事九：**软件是科学还是艺术**。如果是科学，应该能用数学来证明，但是至今没有人能用数学来证明一段程序是否正确。

故事十：**编程的本质。**一位软件开发人员曾经在85年的时候写过一篇论文，说美国的星球大战计划绝不可能实现，因为导弹防御系统天生无法在真实的工作条件下测试。而编程却是一种试错功夫，人们在写程序时，从不指望一次就写对，他们会犯错，然后再改正，测试和修正，如是反复。

故事十一：**编程是一种创造性工作吗**？看着像是，编程行为仍是一种写作行为，逐字逐句的写。一位软件大牛曾说，其实编程可以从写作世界中学到很多东西。写作时你需要读很多别人写的好文章，需要把自己写的文章让大家去评论，但是现在的编程领域却不是这样，大家很少会把自己写的代码展示给人看，也不去看别人的代码。

故事九：**注释。**注释是给读程序的人看的。实际上它不仅是说明性的文字，也是程序员情绪发泄的阀门。windows 2000 某个版本的部分源代码泄露到网上，大家发现微软的程序员们写的注释有很多这样的句子：we have to do this only because Exchange is a moron.(必须这么做，因为Exchange太白痴)

故事十二：**程序员的绩效考核。**书中提到一个小故事，一位项目经理要求大家把每天写的代码行数记录下来，作为考核的依据，他的上司知道后，对他说：我刚完成一个项目的修改工作，把一段5000行的代码缩到了4000行，那么我的工作是-1000行。你这样做，是鼓励程序员写出蹩脚臃肿的代码。

**第八章：白板上的即时贴：**如此，在程序开发的过程中，我们可能会出现偏离原先的计划的情况，毕竟开发需要创造力，我们难免会忘了初心。  
**第九章：方法**：失败了并不一定是成功之母，失败了很可能再失败。成功是有一些流程的，我们必须遵循计划，步步为营。   
**第十一章：通往狗食版之路**：Chandle的每个扩展，就其本身而言算不了什么，但如同摩根萨奇的相册程序做到的那样，每个扩展都给它最初的承诺注入了生命力。正式这些扩展，以及他们几乎不费吹灰之力就把貌似截然不同的信息拼到一起的能力，赢得了一片惊呼之声。  软件，那是另一个困难世界，跟生活相比，不太难的一种。

看完本书后 你会觉得程序员这个职业充满灰暗，真的和书上说过的一样：“只有比尔盖茨才是比尔盖茨”。真正如题目所述 梦断代码 dreaming in code，因为正如原作者所说，书中描写的：软件工程是一队人马并肩扛起代码大石，虽历经磨难仍欲将其推上山顶的故事，而正是这种故事成就着今天全世界亿万台服务器和PC机上运行的各种软件，成就着人类不断超越实现更伟大的梦想。

究竟选择大教堂还是集市？OSAF（chandler项目执行机构）决定两者兼而有之，一方面组建自己的员工攻坚

核心代码，另一方面将测试版本进行开源，寻求外界帮助。

OSAF老板，有着成功经验的卡普尔坚信自己会再次成功。对啊，有着丰富的经验，顶级的软件高手，充沛的

资金，大把的时间，谁都不认为这个项目能难得倒这群人。

但是，有太多的案例倒在了路上，被无处不在的黑洞拉扯直至无法前行。

FBI计划，未来战役系统计划，麦当劳项目，动碌上亿美金，却尸骨无存。

编程人员确定完成；

语言确定完成；

目标确定完成；

这个新的项目就要踏入历史，随车轮前行了。

“关于软件缺陷的话题，只要谈上几分钟，必会有人拍案叹道，‘为什么就是不能像造桥那样造软件？”正如书中所说的，许多人回想为什么不能像造桥那样造软件呢。实际上两者从根本上是不同的，一个是体力劳动；一个是脑力劳动。造软件，从来就不是一个确定的东西，每个人都有有自己的偏爱和偏见，对编程的结果充满了各种不确定性，以它为主的项目，自然不可能做到分毫不差，不能像造桥那样进行。通过读这本书，了解到我们要尽量把这种不确定性从项目中剥离出来，使做软件真正成为一个工程。

《梦断代码》书中讨论了“软件时间”这一概念，布鲁克斯在书中提出了一个十分著名的观点，“往以延误的项目中补充人力，只会使其继续厌恶”，经过了无数年间的实践，这一观点都成了程序猿和开发经理的梦魇。布鲁克斯指出了其中要害，”只有在任务能分派给许多相互之间无须沟通的工作者时，人和月才是可互换品。“制作软件的大量工作受困与”序列约束“”，它限制的任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。

“在对软件系统的加速依赖和踱步学习怎么做好软件之间，有一条巨大的叫人恐惧的壕沟，梦之所寄，行之所为，地狱之们就此洞开”，也许真的和作者说的一样，软件就是麻烦一堆，做软件和寻宝差不多，需要人手指点，在开工之前，要找到线索，但是却不知道花多久才能找到

一个处理bug的故事，其实在现实中也有体会，有时候写代码容易，改代码难，这不是4个小时或是8个小时的问题，想到就是想到了，没想到就改不出来了，就像人月神话中，工作量怎么可以是累加时间就可以解决的呢？几个月后bug终于解决了。可能就像安德森说的：“你一早醒来，脑中灵光一闪，于是手到擒来——大抵如此。”或许做梦是真的有用的呢。对于开发模式，大教堂的模式可以说是传统的开发模式，而集市模式被很多开源项目采用,比如Apache Web服务器,Linux。咱们一般开发自然用的是大教堂模式了。

失败，其实是一个很平常德问题，谁的成功没有失败过，今天看来，NLS不断闪烁的单色屏幕和粗糙模糊的字体已经是老古董，但其功能和设计确实树立了协同软件的标杆，现代系统克服重重困难才得以企及。所以，如果你正在做的项目失败了，别太气馁，你不是第一个，也不是最后一个。

项目语言的选择其实并不是很关键，但是还是使用自己熟悉的语言比较好，现在我们学过C++也帮其他专业的同学做过C语言作业，此外，我们也用JAVA编程，其实语言的差异并不是很大，大致的道理都是相同的，曾经有一次写代码总是报错，为什么呢？因为在eclipse里混用了C语言的输入输出却不自知，也检查不出俩错，可笑的是同学也看不出来，就像是就像是邓超经常说的那句“what are you 弄啥嘞”，呵呵呵。现在写小程序习惯了用C++写界面用qt，每个语言都有自己不同的特性，所以项目组有机会选择语言的话，最好还是考虑一下开发人员对哪种语言最熟练。

做一个项目有时间限制自然是极好的，用时间驱动版本发布是一种比较有效的方式，它让开发人员有一个奋斗的目标，尽快完善自己的开发模块。就像我们的软件工程课留的大作业，真的是在挤时间逼着自己去做的，如果王老师没有给我们时间约束的话，估计我们的项目就放到长毛了。

把自己应该做的事情列举出来，然后安排什么事情先做，什么事情后做，这样的生活有规律而又清晰，不会一头糟。做程序也是如此的啊，将需要做的项目分成几个板块由量力的人来认领，分工清晰，这样真的很好。

开发的软件会出现问题吗？当然会出现，可是会出现什么 问题呢？谁也不知道，每个软件在发布之前都是经过多次测试的，可是谁又能保证测试就能万无一失呢，可能问题连测试员都没有发现呢，这就是吃狗食了吧。

编程这种创造性的工作感觉就像是将一个个文字通过语言巧妙地结合，结合不好就得改，语法用错了还得改，但是他终归不是不是我们能够轻而易举级就能读懂的语言，所以注释当然是必要的，省得那天你看到自己以前写的代码都不认识了这可就糗大了。

关于程序员的考核到底什么才是一个标准呢？编写代码的行数？那就大错特错了，其实我觉得重要的是思路，就像一个简单的查找帖子中的水王，我们可以一遍遍的查然后计数在做比较，谁都做得到，可是怎样实现才能让我们编写的代码少而且软件运行的又快呢，同学的思路真是一语惊醒梦中人。

程序员的梦和实际有着巨大的鸿沟。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjcyNzcw_size_16_color_FFFFFF_t_70 1][]

**布鲁克斯法则**：往已延误的项目中补充人力，只会使其继续延误。----《人月神话》作者  
2、布鲁克斯发现，在实际开发中，编码只占软件项目开发时间的1/6，  
 有一半时间用于测试和修正缺陷。  
3、布鲁克斯提到，“在预估及安排项目进度上的每一分努力”都是“危险且具欺骗性的神话”。  
 所谓“人月”，是一种科学管理概念，它假定生产力可被拆分为不连续、无差异、可替换的单元。  
4、布鲁克斯观察到，“只有任务能分派给许多相互之间无需沟通的工作者时，人和月才是可互换品。”  
5、布鲁克斯发现，制作软件的大量工作受困于“序列约束”，  
 它限制了任务分解的程度：完成某项任务的先决条件，这与人力投入多少无关。“十月怀胎”，  
 布鲁克斯写到，“无论多少妇女参加都一样。”

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjcyNzcw_size_16_color_FFFFFF_t_70]: /images/20221120/c66700895b094b6385cc54a3a1991b02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyNjcyNzcw_size_16_color_FFFFFF_t_70 1]: /images/20221120/a2c296bc3516495ab9254516b72d5350.png