印刷做网站网上接单,百度app下载安装官方免费下载,wordpress 建站完整视频教程,备案 网站语言“拿来的代码所不能做到的部分#xff0c;恰是项目与众不同的创新之处”。 《梦断代码》 终于看完了《梦段代码》。其实整本书就是讲图灵机的不可判定性————软件开发过程中#xff0c;很多过程都不知道什么时候能不能结束#xff0c;甚至说能不能做出来#xff0c;这导… “拿来的代码所不能做到的部分恰是项目与众不同的创新之处”。 《梦断代码》 终于看完了《梦段代码》。 其实整本书就是讲图灵机的不可判定性————软件开发过程中很多过程都不知道什么时候能不能结束甚至说能不能做出来这导致整个软件工程不能够停止这不是暗合了“停机问题”纯属玩笑问题并没有这么简单否则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_BlogPartblogview_cBlogPartsa43775437
