《梦断代码》读书感悟三及对《人月神话》的读书计划

<人月神话>读书笔记 第1篇 第1章:焦油坑 第2章:人月神话 第3章:外科手术队伍 第4章:贵族专制.民主政治和系统设计 第5章:画蛇添足 第6章:贯彻执行 第7章:为什么巴比伦塔会失败 第8章:胸有成竹 继<梦断代码>之后,我又选了一本老师推荐的关于软件工程的书——<人月神话>,这本书读起来相对<梦断代码>就轻松多了,可能是翻译得较为通俗,并且每章前都有个寓言或者名句作为引子.并且举了相似的例子来说明,同样也列出了对立的情况来证实一些道理. 开篇书中提到

<人月神话>读书笔记 PB16060710 冯富禹 怎样编写程序才能尽可能的减少bug呢?这是每个程序员都最想要知道的问题,找到并修改bug是一件十分痛苦的事,它需要程序员不断地调试与细心的阅读,这会浪费巨大的时间和人力,也会让编程人员十分疲惫不堪.所以一个解决办法就是,在编写程序的时候就应该尽全力防范bug.因为系统各部分的开发者都会做出一些假设,而这些假设之间的不匹配是大多数致命的和难以察觉的bug.在编写任何代码之前,必须让测试小组的成员了解规格说明,了解检查说明的完整性和明确性,这样才

<人月神话>读书笔记 第3篇 第15章:另一面 第16章:没有银弹 第17章:再论“没有银弹” 第18章:<人月神话>:是与非? 阅读<人月神话>马上就要接近尾声了,发现后面讲的内容越来越专业,但是对于我们正在进行的团队合作启发很大.前几天老师在课堂上给他们看了他统计整理的个人与每个团队第一个冲刺阶段的进度表格,看到有些严格按照要求每天有进度,有些则相反,也可能是完成了但是没有及时汇报进程.那“项目怎么会被延迟了?……延迟的时间是一天一天积累下来的.”目前我们做的都是一

<人月神话>读书笔记 项目的延误是一件灾难性的事情,大多数人可能会认为延误的原因来自于某些灾难性因素,比如员工病倒,数据丢失等,但实际上,这些重大灾害往往是比较容易解决的,因位这些突发性事件往往与重大的压力,彻底的重组或者新技术的出现有关,这些都是项目组可以应对的.而真正可能毁灭整个项目的,大多数都是每天小小的进度延误.一天天的进度落后是难以识别,不容易防范,和难以拟补的,每一天都延误一点,在大家的严重或许没有太大的影响,因为每一天都有新的任务完成,这种成就感会让大家忽略这一点点的缺陷.然而到

看完了这最后三分之一的<梦断代码>,意味着这本软件行业的著作已经被我粗略地过了一遍. 在这最后三分之一的内容中,我深入了解了在大型软件项目的运作过程中存在的困难和艰辛.一个大型软件项目的成功代表着这团队所付出的所有心血,以及那不为 人知的无数个‘人月’.而联想自己的专业,产生了一点迷惘,这就是我今后要走的道路么,我能走得多远,我能否像书中所提到的那些人一样百折不挠,这一切我 都无从得知.但是我只能向前走,别无选择,没有人会承认自己不如别人,哪怕现在不如,但总会寄托于未来,未来是未知的,但又是现

<梦断代码>在读读停停.时快时慢中读完了.在最后我不禁想起全书开始处内容简介里的话——“本书是讲一事,也是讲百千事:是写一软件,也是写百千软件:是写一群人,也是写百千万人.任何一个在软件领域稍有经验的技术人员看完本书,必掩卷长叹:做软件难.” 诚然,我还不属于“软件领域稍有经验的技术人员”,但是我也从书中了解到了做软件之难.这里来写写最后几章的感受. 第8章中描述了即时贴的概念,依然是在漫长的Chandler开发过程中的一次会议上,杜索特提出每人在白板上贴自己的即时贴,每张纸表示大致同等的工作

梦断代码: 一群人像是守护着一个刚出生的婴儿,细心呵护,无微不至.将所有精力都投入对他的照顾,可是,到头来功亏一溃,驮着巨石上山但是却在最后阶段滚了下来.初时紧紧是一个小小的问题,但后来却逐渐扩大,成为压死骆驼的最后一根稻草!! 但是我也看到了他们的奋不顾身 ,这是一种精神,一种值得我们学习的精神! 如果我以后也从事这门工作的话,希望我也能和他们一样,拥有为之奋斗的精神!!

最近半年尝试带一个小团队,开发一款新产品.写了两年多的代码,现在突然转换了一个角色,面临更多的挑战.现在开始搜集产品用户场景,编写用户和系统需求文档,制定工作计划,安排人员工作,制定目标,跟踪项目成员工作进展. 在这个过程中遇到种种问题,如何建设团队,如何评估工作量,安排人员和时间,如何下发工作,如何跟踪进展,如何识别风险,如何推进项目等. 因为是新产品,公司从稳定安全方面考虑,开始只给了两个应届生,后面陆续给了1一个老员工和3个实习生.我们是一个全新人的团队,我担当的项目负责人和技术决策人两个

作为一个初学软件工程,并没有真正编程经验可言的的人,开始先是通读了一遍<人月神话>,只知道了“人月神话”的真正含义.人月是在估计和进度安排中使用的工作量单位,但因为它具有的危险性和欺骗性导致了它像神话一样地存在.而作者阐述的主要思想是软件编程的项目进度与增加人员之间是不能互换的. 之后再仔细地阅读一遍后有了更加深刻的体会,自进入信息时代以来,对于软件项目而言,项目工作者都挣扎在巨大的“焦油坑”里试图摆脱出来.在挣扎的同时我们也必须努力找到工作的乐趣所在尽管同时肯定会伴随着许多烦恼和痛苦.在一项

综述 这是一本值得每一位软件工程人员一读的好书.本书详细探讨了软件工程中"高效性"与"稳定性"的问题.书中的经典语录数不胜数,此处仅摘录三则,联系实际,作一些感想. v  用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话. --摘自<人月神话> 在本书中,传统的以 [人数×时间] 作为工作量的效率公式被推翻.这是一个比较新的观点,但正被越来越多的人所接受.在现代化的社会之中,"人月"的概念被逐渐淘汰,因为老的社会组织架构正在以