梦断代码读书笔记

梦断代码，Dreaming in Code， 是作者讲述软件开发路上一系列的坎坷与经验之谈。

 

第0章 软件时间

　　从0开始的技术方式，自然也就讲了计算机从0开始的原因。+1，-1正是我们对计算机所作的操作。

　　"Hello World " 程序能够唤醒每个程序员心中乐观的一面。既然能叫它说话，就能让它做任何事！

　　为什么就是不能像造桥那样造软件？

　　在现代软件研究领域多有建树的专家弗里德里克·布鲁克斯(Frederick Brooks) 在1987 年写了一篇题为（ 没有银弹(No Silver Bullet )〉的著名论文。布鲁克斯在论文中称，我们始终无法找到突破，无法得到银弹。

 

第1章    死定了

　　软件项目难以按进度安排实现，这种情况极为常见。在软件开发的世界里，进度延误普遍到人们特意生造出—个委婉词来描述它：slippage（失速）

　　布鲁克斯法则：向已延误的项目中补充人力，只会使其继续延误。

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

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

　　开源运动的兴起，对于我们学生来说自然是益处多多，促进了计算机世界的发展，以与大教堂方式相对的立场成果林立。

 

第2章    Agenda之魂

　　莲花公司有个叫做Agenda 的项目，为了解决卡普尔的小纸片问题而设立。即采用计算机人工智能来管理记录信息的小纸片——名片、随手贴、笔记页等。莲花公司于1988 年发布了Agenda 软件。

　　Agenda的“自动分派”特性一一在意义模糊的短语里面，如“ 下周五与约翰共进午餐"'找出“下周五”这个曰子——如同魔法一般，没有其他软件能与之媲美。它还引入了一种管理数据的新手段——介于传统计算机数据库的严格结构和字处理软件的自由格式之间。

 

　　Agenda的创建者们认定这样一些超乎常规的原则：用户不用关心软件的存储结构，只管输入数据就好，用户应该能够容易地扩展和修改数据结构、添加新分类， 且不会导致数据丢失，用户应该能够用自己创建的新方式查看数据——也可以在自己创建的视图中操作和修改数据。

关于Chandler，米奇.卡普尔只知道三个要素：它应当开源，它应当挠到Exchange 的痒处，它应当承继Agenda 之精髓。

文章又介绍了很多失败项目，并指出失败的原因是项目需求的不断变化。无法标准把心，时间一天天流逝，预算也会超支，最终导致项目破产。

 

第3章 原型与Python

　　Python 是一种“解释型语言(interpreted language)" 。“编译型语言(compiled language)" 通过编译器先将程序员的源代码翻译为机器可读的二进制代码后再运行，而解释型语言则是在运行时做类似的工作——解释器逐行翻译源代码，再喂给处理器运行。解释型语言效率较差，因为你要同时运行自己的程序和解释器。但这也使得解释型语言较为敏捷。

　　Python是一种动态语言，每次调用变量时都要去判断变量的类型，但是在书写代码时就很方便

　　电梯游说：就是当你有幸在电梯间遇到某位权钱人士时，能脱口而出，在短时间内说服他。

 

第4章 乐高王国

　　模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周而复始，不断地在多个程序员身上上演。

　　大概满足需求的开源代码我们都能找到很多，但是能恰好契合契合我们问题的却很难，除非是很传统的练习题，如果是创新性的项目就需要我们自己去解决这些差异。

 

第5章 管束奇客和狗

　　国外技术人员不愿承担项目经理这种管理岗位，而在国内正好相反，许多时候还是不会编程的人来管理。

　　用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。

关于奇客的2种定义：

　　以（计算机）程序缺陷为食----不善社交、身有恶臭、面色苍白的偏执狂，具有奶酪刨丝器一般的人格特点。

专注于己事的人；追求技术（特别是专业技术）和梦想、不融入主流社会的人。

　　我们在制作工具的时候，不要花费太多的时间，虽然磨刀没有错，但毕竟时间有限，我们的主要任务还是砍柴。

 

第6章 搞掂设计方案

　　持续集成应该更利于产品的定期发布。

　　关于Linux的作者李纳斯托瓦茨的话：

　　别做大项目。从小项目开始，而且永远不要期望它变大。如果这么想（指做大型软件），就会做过度设计，把它想象行过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大图景和好设计。如果项目没解决某些需求，多半就是被过度设计了。

　　别指望在短时间内达到大成就，我致力于Linux达13年之久，我想后面还得花上好些时间。如果一早就妄想做个大东西，可能现在还没动手呢。

　　应该要脚踏实地，不要妄想一口吃成个胖子，从小一步步积累，一步步提高自己的能力。

 

第7章 细节视图

　　需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。

　　一定要弄清楚需求，否则白白浪费时间和人力。最好能让负责这一块的人复述一下让他说一下自己的理解。

 

第8章 白板上的即时贴

　　非常敬佩写标准的人，你要用5年为计量标准的眼光看问题。得花上5年时间，才能得到你真正想要的有用之物。

　　贴纸法应该是在敏捷开发里被重点推广的，方便标注哪些功能暂未开始，那些正在进行，哪些已经完成，项目各个小版本的功能特性都清清楚楚。

 

第9章 方法

IBM执行强制进度纪律的成功基于两条原则：

1）计划是强制性的

2）计划必须符合现实情况 ----“从底向上”，依据那些负责按计划执行的程序员的经验和知识而来，而不是“从顶至下”，靠管理者拍脑袋或对市场的期望而来

2001年17位领军人物，提出了敏捷软件开发宣言，向这种笨重的CMM宣战，从此极限编程XP和SCRUM开始流行。

祖尔测试的12个问题：

1）你们使用源代码控制吗？

2）你们一步就能完成构建吗？

3）你们做每日构建吗？

4）你们有缺陷数据库吗？

5）你们会在写新代码之前修复缺陷吗？

6）你们有与当前工作吻合的进度安排吗？

7）你们有规约吗？

8）程序员工作环境安静吗？

9）你们采用了市面上最好工具吗？

10）你们有测试人员吗？

11）你们会要求应聘者在面试时写代码吗？

12）你们做走廊可用性测试吗？

CMM开发在国内还是比较困难的吧，比较注重过程，国内很多公司都把这个工程流于形式，很多都是为了向用户提高价码。

 

第10章 工程师和艺术家

　　squeak一种为少儿定制的samlltalk最新开源实现

　　如果说编程是一门艺术，那么让孩子今早的接触好像没有什么不好，还有一种说法认为编程是一种工程。

　　高德纳写的书名叫《计算机程序设计艺术》，他在1984年获得图灵奖时发表感言说，“计算机编程是门艺术”。写《计算机程序设计艺术》这本书他花了十年，写TeX和metafont程序没想到也花了近10年。他宣称，写软件要比写书“难多了”。

 

第11章 通往狗食版之路

　　我们要尝试下自己写出来的软件，把自己带入到用户的地位，想像一下用户的体验，如果我们自己都无法承受，那客户要爆炸的吧。。。

集开发、测试与用户与一身，如果把修复啥的都包给别人，自己做完就走有点像甩手掌柜，全套负责开发出能让人满意的产品才能提高我们的境界。