阅读笔记06

 梦断代码

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

于是，我睁大了眼睛，又返回去从第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行。你这样做，是鼓励程序员写出蹩脚臃肿的代码。