梦断代码读后感2

我在课下看了《梦断代码》，整本书以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的思想，要合理的抽象和模块化，同时鼓励使用代码注释。