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

拿到《梦断代码》书后，一口气翻了一遍，然后又用了3天时间仔细读了一遍，也不禁掩卷长叹一声，做软件难。虽难，仍要继续走下去，可以把软件的范围限制得小一些，用敏捷方法等过程会使软件失败的风险小一些，毕竟我们还没有写书上所说的那样的大型软件。

 

第0章 软件时间

一开始看到第0章并没有感觉多么奇怪，可能程序员的思维方式已经固化在大脑中了，但读到作者关于第0章无意搞笑时，也不禁哑然失笑，为什么程序员要从0开始计数？因为计算机从0开始计数！多么直接的答案，程序员要学习计算机的计数方式，要从0计数转换到真实用户的从1计数，不停地在程序中进行+1 和-1操作。

读到Hello World，上网google了一下这个200多个hello world的网页，许多都是闻所未闻的语言。

http://www2.latech.edu/~acm/HelloWorld.html

http://www.roesler-ac.de/wolfram/hello.htm   这个不知道为什么无法显示，难道这东西也被QIANG了？

1987年Frederick Brooks写了《没有银弹》的著名论文，1/4个世纪过去了，银弹确实没有发现，各种方法论产生了一大批。

 

第1章 死定了

Bugzilla软件在我们的团队里没有使用过，我们主要用JIRA，主要是在软件快发布前用上一段时间，随着时间的推移，一些项目就慢慢不用了。

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

做软件的人都听说过这个法则，但在项目吃紧的时候确实都忽略它的存在，或者认为这法则对自己的项目不成立。此时领导的决策通常不是靠大脑，而是凭通常的直觉，人多力量大，但在软件行业不适用。“十月怀胎，无论多少妇女参加都一样”，是个非常形象的比喻。

 

第2章 Agenda之魂

卡普尔（Mitchell Kapor）在接受戴维·甘斯的采访时说过的一段话：

在变成数字资本家之前，我曾教人超觉静坐，还在一家社区医院的精神科做过心理咨询师，这些经历对我影响极深。我拥有心理咨询的硕士学位。所以，我另有志趣。我只是误入计算机领域，无意成为比尔·盖茨----只有比尔·盖茨才能做比尔·盖茨。我向来不求做大公司、赚大钱。我只是办了家叫做莲花的小公司，做了个几百万人争相购买的软件产品，结果这家小公司陡然暴长，员工数千，每年收入数亿美元。很不爽。至少对我个人来说，很不爽。所以我离开了。在某一天，我离开了。

 

第3章 原型与Python

语言的选择可能都是一个项目在前期选择时必须要经历的痛苦抉择。

文中谈到了汇编、Fortran、C、Perl，谈到了编译型语言和解释型语言，最后项目用Python语言来实现。

这章里提到了RDF（Resource Description Framework），好像在今年结题的国家863项目中也听到过这个名词，原来这玩意可以用来描述万维网中的语义。

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

 

第4章 乐高王国

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

最近有一个叫组件管理方面的项目，听起来让人毫无信心，连运行在什么平台上、给什么用户使用都不清晰，这样的组件管理有什么用？还不如就叫做文档管理算了。

书中提到一个叫考克斯的人，他创办了一家叫做Stepstone的公司，致力于向C语言系统搭造者提供插入式芯片级软件组件，最后的结论是：坏消息是这次试验显示，即便采用最新的技术，要想设计和制造既有用又真能复用的组件、为组件写文档以便于客户理解、移植组件到潮水般不断涌现的新硬件平台上、确保最新的改进或发布版本不与现存接口冲突、将组件销售到类似威廉姆斯堡枪械行业那种鼓励从头做起的价值体系，都是极其困难的。

可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需要的代码。但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处----也是创建这个项目的出发点。

 

第5章 管束奇客和狗

质量三角，既好、又快、还便宜，同时满足的事情不太可能发生。

从程序员转做经理常被说成是做了“前脑叶白质切除手术”，这个术语还是从刚从《How We Decide》这本书看到过，这种手术会让患者更新丧失感情、不知爱恨悲喜。国外技术人员不愿承担项目经理这种管理岗位，而在国内正好相反，许多时候还是不会编程的人来管理。

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

闲逛式管理MBWA(Management by wandering around)好像不能移植到软件领域中。

关于奇客的2种定义：

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

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

群件Groupware：即时通信、聊天室、缺陷跟踪、源借故传统的邮件列表等工具，个人感觉要慎用这些工具，否则你的工作时间会被这些工具吃得一干二净。

Wiki在chandler项目中也建立了起来，感觉这个chandler项目用到的工具太多，如果程序员不能合理地安排自己的时间，估计会被这些工具所淹没。

对于程序员来说，确实有一种制造工具的冲动。磨刀不误砍柴功本身没错，但程序员在磨刀的过程中会想弄到一块最好的石头，并花了大把的时间去把刀磨得吹毛断发，却忘了还要砍柴。

 

第6章 搞掂设计方案

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

这一章出现了GTD，没想到这本书的产品chandler竟然与GTD也有关系，原来这个软件的UI设计师尹咪咪受到了戴维艾伦的Get Things Done书的影响，不过这里翻译为《搞掂》，而不是《搞定》，看来如果chandler早点发布，流行于世面上的GTD工具可能不会是omnifocus，而是chandler了。

在www.floklore.org网站里有大量关于建立MAC操作系统的小故事，可惜这些英文看起来有点累。

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

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

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

 

第7章 细节视图

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

最著名也最声名狼藉的匈牙利命名法，可能在用C++写Windows程序的时代是需要，因为各种类型、结构、枚举、控件等等让人眼花缭乱，让人容易出错，而在Java和C#等这种强类型的语言中，这类命名法完全是对程序员审美观的践踏。

prepBut nI vrbLike adjHungarian! qWhat’s artThe adjBig nProblem?

我就是喜欢匈牙利命名法！有什么问题？

Chandler中的所有内容都是Item，对Item可以打戳算是一种创举，有机会看来还是可以试试这款应用。

 

第8章 白板上的即时贴

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

这里也提到了WebDAV，好像这协议在Mac里实现得比较全，但在Windows中都不完整。omnifocus也支持WebDAV同步。

这章里提到了37Signals公司（写《重来Rework》的那家公司），这种小型团队专注于AJAX的WEB应用，同样取得了成功。

用贴纸法来讨论项目各个小版本应该具有的功能特性，也是敏捷开发里重点推广的。

 

第9章 方法

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

1）计划是强制性的

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

CMM这个沉重的软件开发成熟度模型在国内完全变了味，曾看着一个软件公司为了通过CMM4，编出一堆从来无人细看的厚厚的文档，CMM果然只重过程，而国内更把这种过程流于形式，通过CMM，只为了向用户抬高价码。TSP、PSP也看过，感觉相当繁琐，在国内都难于实行。

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

Google让开发者把五分之一的时间花在个人项目上。这种管理方式在国内想都不敢想。

祖尔测试的12个问题：

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?    你们做走廊可用性测试吗？

 

第10章 工程师和艺术家

squeak一种为少儿定制的samlltalk最新开源实现，让少儿过早接触编程到底好不好？

编程是工程还是文学？是科学还是艺术？

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

 

第11章 通往狗食版之路

吃自己的狗粮，这种思路确实有助于提升软件质量和用户体验，想想连自己都不屑一用的软件凭什么去折磨用户呢？

麦卡锡从本质上用LISP描述了LISP，有时间得看看这个大名顶顶的LISP，先把这段天书贴上，据说与Haskell一样难学。

尾声 长赌

可怜的海湾大桥在2012年完工，上网查了查，看来需要在2013年才能完工，看来建桥与软件也有相似之处。

从网上搜了一张2013年完工时预计的样子。

 

看完书后，我上网查了一下，原来chandler1.0已经在2008年发布了，当前是1.0.3版本，也被称为一种GTD工具，凭着一点好奇心装上了，实在不会用，马上就删除了，满屏的东西不知道该按哪个，可能OmniFocus的概念已经彻底地占据了我的大脑了，让我放弃所有的omnifocus上的action全部导入到这里来管理，实在没有这个勇气。