最新消息:发现真没时间折腾VPS,最近又换了个空间。呵呵

《人月神话》读书笔记1

  不知道是因为自己水平差还是因为什么,《人月神话》快读完了(18章是作者自己的总结,我想放到最后读),但是我却没有什么大的体会,虽然很多人都说这是神话级别的书。可能是我水平太浅,没有太多的项目管理经验。觉得软件行业其实和其它行业一样,设计,制造。不过我的理解是,编码和测试的过程应该也算是设计。比如汽车,不是设计出来就可以用的,先做一个样板,经过大量的测试才成投产。相对其它行业,软件产品的大批量制造几乎不用花时间,还有软件的定制想对其它产品要多得多(定制时就没有大批量制造了),所以很多人把编写代码看成是制造了。软件系统的设计、实现都是人为的,所以人在软件过程中的作用尤其重要。人月神话说的大多是人与软件的关系。大体看完,只是想把自己的理解先记下来,然后再去看看作者的总结,了解一下自己的不足。

第1章 焦油坑:程序变为产品,需要花去原来时间的3倍,因为文档,系统集成都需要时间。

第2章 人月神话:正因为软件过程是一个设计的过程,所以在软件过程中,盲目添加人手,只会让项目进度变慢,而不是加快。因为人员的培训、交流是需要花大概时间的。一般系统而言,三分之一人月计划;六分之一编码;四分之一单体测试,四分之一系统测试。

第3章 外科手术队伍:人员的分工要明确,安排好各自的工作,使得在顺利完成工作的同时,尽可能减少交流和培训时间。

第4章 贵族专制、民主政治和系统设计:系统设计应该和连贯性;系统在满足功能时,应该简洁和直白(苹果的成功,就在于其简洁和直白);系统设计前期,程序实现人员就应该了解系统,对系统要用到的技术进行调查。

第5章 画蛇添足:系统的设计应该简洁高效,而不是添加很多几乎不可能用上的功能。功能不是用户喜欢的全部,易操作和理解才是用户最喜欢的。

第6章 贯彻执行:实现人员应该以文档为准,如果觉得有其它想法,应该在会议提出,而不应该随便修改文档,因为文档的接口定义等可能是其它小组的基础。

参考资料:《人月神话》清华大学出版社 2002年11月版

转载请注明:宇托的狗窝 » 《人月神话》读书笔记1

发表我的评论
取消评论

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址