《神话故事》读书笔记(精选多篇)

第一篇:希腊神话故事读书笔记

《神话故事》读书笔记(精选多篇)

希腊神话故事读书笔记

袁栎晴

书是人们生活中不可缺少的一部分。就像小鱼离不开水的滋养,小狗离不开骨头一样。当我们寂寞时,它将为我们赶走寂寞;当我们有困惑时,它将指引我们正确的方向。书还会给我们一把智慧大门的钥匙。

而今天,我将来给大家推荐一本好书《希腊神话故事》,这本书是一位德国名叫:古斯塔夫·施瓦布的着作这本书主要讲了:希腊神话主要由诸神传说和英雄故事两大部分组成。在神的传说中,诸神都具有超越自然的力量,但他们也于普通人类一样,有着平凡的喜悦、悲伤、嫉妒等各种各样的感情(也就是喜怒哀乐)。英雄故事则起源于古希腊人们对祖先的崇拜,敬仰。书中的英雄们无不智慧过人、力大无穷,体现了人类征服自然的自信和顽强。

这本智慧的“领跑者”将带给我们无限的乐趣。大家觉得怎么样,快来走进这本书里吧。

第二篇:人月神话读书笔记

人月神话这本书几年前就听别人说是本很经典的软件开发方面的书,这本书的成功之处在于他思想的前卫性,以至于不只是软件行业的人在读。现在终于找到读他的理由了,可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程,为什么留到最后读人月神话呢?主要是因为我觉得一本能够流传30年还被人们津津乐道的书,肯定是本学要好好细读的书,所以留到了最后。按照前两篇读书笔记的惯例,前面几段是一些我读书时的感受和收获,还有一些对内容的评价。

从这本书的内容来看,对于一个项目经理来说肯定会有更大的收获,这本书主要是针对软件开发管理方面的内容,这主要原因可能是因为作者以前就是项目的管理者,他是站在管理者的角度写的。即便这样,对于一个从来没有参与过真实项目开发,更没有领导过团队的我还是有一定的吸引力,这本书中我最喜欢的就是前四章(焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计)和没有银弹这章。这本书里面为了论证某一观点,会举出许多实际的项目作为证据,这一点非常好,事实胜于雄辩嘛!这些例子也许对于作者那个年代的人来说很好理解,但是放在30年后来看这些例子又有些陈旧和难懂了。另外,从文中我发现作者非常注重文档,一个优质的文档就是项目成功的保证,这一点与传统的软件工程很相似,但是却与极限编程的观点相悖。下面就是一些读书的总结了。

焦油坑 1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。

2. 编程行业的一些内在固有苦恼:

l 将做事方式调整到追求完美,是学习编程的最困难部分。

l 由其他人来设定目标,并且必须依靠自己无法控制的事物。

l 真正的权威来自于每次任务的完成。

l 任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外

l 人们通常期望项目在接近结束时(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢。

l 产品在即将完成时总面临着陈旧过时的威胁。 人月神话 1. 缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来影响还大。

2. 良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。

3. 我们的构思是有缺陷的,因此总会有bug。

4. 我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。

5. 在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。

6. 关于进度安排,作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7. 因为我们对自己的估计技术不确定,所以在管理和客户的压力下,我们常常缺乏坚持的勇气。

8. brook法则:向进度落后的项目中增加人手,只会使进度更加落后。

9. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量:任务重新分配本身和所造成的工作中断;培训新人员;额外的相互沟通。 外科手术队伍 1. 同样有两年经验而且在受到同样的培训的情况下,优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到,sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。

2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。

3. 两个人的团队,其中一个项目经理,常常是最佳的人员使用方法。

4. 对于真正意义上的大型系统,小型精干的队伍太慢了。

5. 实际上,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是高成本、速度缓慢、不充分的,开发出的产品无法进行概念上的集成。

6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法,既能获得由少数头脑产生的产品完整性,又能得到多位协助人员的总体生产率,还彻底地减少了沟通的工作量。图1是10人的程序开发队伍沟通模式。 图1 10人程序开发队伍沟通模式