“拿来的代码所不能做到的部分，恰是项目与众不同的创新之处”。
《梦断代码》
终于看完了《梦段代码》。
其实整本书就是讲图灵机的不可判定性————软件开发过程中，很多过程都不知道什么时候能不能结束，甚至说能不能做出来，这导致整个软件工程不能够停止，这不是暗合了“停机问题”？纯属玩笑，问题并没有这么简单，否则Scott Rosenberg的书也不会这么畅销。
我最感兴趣的是如何能够在10个小时之内读完这本书的英文版，因为我十个小时才刚完成中文版的一半，而且只是大概的了解。不得不说，我不是很习惯作者的写作风格，以记叙文的风格去写说明文，必然会给信息的提取带来很多的不便，说白的就是文章中的“废话”太多，以至于不认真看还真找不到课上讲的东西，比如“Feature Driven”之类。不过话说回来，Scott Rosenberg真乃神人，能够把这么一件很理性的事情以如此幽默的方式表现出来而且不失深厚的文化底蕴，使得全文行云流水，酣畅淋漓的展现自己在项目管理和代码编写方面的才华，获得这么多读者的支持也是有理由的。
《梦断代码》以OSAF开发的名叫Chandler的PIM软件的开发过程为主要的线索，阐述了这个软件的4年来开发过程，这个梦并不是很美好，实际上是痛苦的，软件开发过程中的典型问题在Changler的开发过程中到能找到。不过本书主要还是要说明如何有效的应对由于生产力的发展而导致预期目激增而导致项目目标发生的变更，这样的变更通常是不可预知的，似乎在和你进行一场不公平的游戏，你在明处，他却在暗处————被动的总是你。
1、信仰
如果一个软件项目没有任何追求，那么可以做的很平庸，这样也就很难遇到Chandler开发过程中的种种困难。这不是作者考虑的范围，作者希望一个软件开发出来，必须要有“杀手级”特性，比如文中提到的Lotus 1-2-3，这样便是软件开发中目标变更的源泉。软件必须是有区别其他软件的特性，而不是简单的仿照，我们不希望做出复制品。我觉得Chandler开发过程中的主角卡普尔坚信“Agenda之魂”便是一个似乎不可完成的特性，他希望PIM能够任意的整合个人数据，这个“任意”就让人摸不到边了。不过正是卡普尔坚信这样的信仰，才是他能够在OSAF看着Changler举步维艰的前行了6年（今年初卡普尔貌似从OSAF撤资了，不过Chandler似乎还在继续前行）。
2、一个接一个的问题
很多问题看似简单，实际上却很难解决。比如“代码复用”问题，是重用他人的成果，还是另起炉灶，从头开始，这有点像哈姆雷特的抉择。文中提到了，“代码复用”实际上非常困难，因为没有两片相同的树叶，任何功能都不是完全相同；即使有适用的代码，如何在浩如烟海的代码库中找到也是个问题。实际上“代码复用”和软件的信仰有点相悖，重复他人的成果还是自我创新，不过文中还是给出了答案，“拿来的代码所不能做到的部分，恰是项目与众不同的创新之处”。
软件开发过程中遇到的最多的问题是“项目的进度远远落后于计划”。Chandler计划是3~4个月发布一个版本，但是每个版本都花了6个月以上的时间，这里面有诸多的原因。首先合理的衡量开发进度本身就是一件非常难的事情，也就是说计划本身太苛刻了。即使是检测软件开发的进度也是一件很痛苦的事情，用代码数量或者缺陷减少数目来衡量有过偏颇，文中提到了MBWA的方法，但是这个方法很难得到一个总体的开发进度。其次是软件开发的计划往往超出了能预见的范围，致使软件开发一只停留在设计阶段，引用文中的一句话,“用今天的工具和过程，加上昨天的内存限制，我们真的能做的更好”。另外就是软件的缺陷，Chandler在开发过程似乎中似乎掉进了缺陷的泥潭中，他们花了大量的时间用于修复软件的缺陷，如何减少软件开发过程的缺陷也是个头大的事情。
还有就是开发者的心态也是需要注意的，如果软件长时间停留在设计阶段，没有任何的程序甚至是代码，那么很容易让人悲观，会影响生产力的发展。文中记叙了一件很有趣但是也很无奈的事情，Chandler 0.2发布的时候，发布者在Blog中恳求大家不要下载，甚至不要去宣传，原因是Chandler 0.2是一个几乎不能用的版本。但为什么要发布呢？“如果没有中间版本期限的话，就会导致在充满各种编码可能性的土地上漫无目的地四处游荡”。
3. 我们要迎难而上
当然，作者不是简单罗列Chandler开发中的问题，他还是提出了许多开发过程中的一些方法和注意事项。作者很看重方法的选择，对于不通的情况，应该采用不同的方法，他说“决定采用何种工具和方法有可能成就或毁掉项目”。
首先是如何设计项目的目标。这个和项目的信仰很矛盾，理想是做一个很出色很优秀的软件，但是很多情况下是力不从心的，项目过大很容易埋葬自己。文中有一段很有意思的对话：“你对那些刚开始做大型开源项目的人有何建议？”“别做大项目”。卡普尔在Chandler的设计过程中一直想坚持“Agenda之魂”，现实却一次次的消磨这种想法。后来他只期望做出一个“狗食版”，但是“狗食版”都是一件多么奢侈的愿望。实际上大家都希望看到自己的努力有实质性的成果，做出一个“狗食版”有利于较大目标的实现。“尽快的做出可用的软件”（原文中“狗食版”是指给自己用的版本，来源于一个美国卖狗食公司的广告，该公司的老板用自己生产的狗食喂自己的狗）
其次是进度管理，这在软件工程中是不可预知的。首先是进度的衡量难，不能单一的用代码数量和缺陷减少数量。在软件过程中有很多很顽固的缺陷，在当前很难快速的解决。还有就是人与人之间是很难协调的，比如新加了个成员，需要新成员培训；比如更换了项目经理等等。文中提到“特性驱动”“进度驱动”等，在实际的管理过程中两者兼有，只是侧重点不通罢了。对于是否需要用强制进度纪律来管理，作者谨慎的给出了说明：这要看情况来定。有些程序员不喜欢被强制管理，那么强制纪律最好不要用。如果进行强制进度管理，那么在评估进度的时候要符合现实，采用“自底向上”的方法评估。比如文中的CMM管理。
还有缺陷管理。现在的编程模式基本上都是先编些代码，然后修正缺陷，实际上很难写出没有缺陷的代码来。直觉上，文中也是这么说的，在开发过程中越晚修正缺陷，代价就会越高。所以要尽早的发现缺陷。如何减少缺陷，文中给出了一些方法，比如“螺旋模型”、“极限编程”、“祖尔测试”等等。作者还提到了OOD的思想，要合理的抽象和模块化，同时鼓励使用代码注释。（实际上代码注释可以很好的发泄自己的情绪~~）
当然，一个项目的成员自然需要交流，交流的方法有很多，可以用Blog、wiki等等，但是不要忘了一些非正式的交流方法，比如在“冷水机”旁边交流。
-------by Hu Wei
from http://springgreen9527.spaces.live.com/default.aspx?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&sa=43775437
 项目总结)
 电梯调度程序)
