中国神话故事读书笔记

中国神话故事读书笔记第一篇：希腊神话故事读书笔记希腊神话故事读书笔记袁栋晴书是人们生活中不可缺少的一部分。就像小鱼离不开水 的滋养，小狗离不开骨头一样。当我们寂寞时，它将为我们 赶走寂寞；当我们有困惑时，它将指引我们正确的方向。书 还会给我们一把智慧大门的钥匙。而今天，我将来给大家推荐一本好书 希腊神话故事 这本书是一位德国名叫：古斯塔夫施瓦布的着作这本书主 要讲了：希腊神话主要由诸神传说和英雄故事两大部分组 成。在神的传说中，诸神都具有超越自然的力量，但他们也 于普通人类一样，有着平凡的喜悦、悲伤、嫉妒等各种各样 的感情。英雄故事则起源于古希腊人们对祖先的崇拜，敬仰书中的英雄们无不智慧过人、力大无穷，体现了人类征服自 然的自信和顽强。这本智慧的“领跑者”将带给我们无限的乐趣。大家觉得怎么样，快来走进这本书里吧。第二篇：人月神话读书笔记人月神话这本书几年前就听别人说是本很经典的软件 开发方面的书，这本书的成功之处在于他思想的前卫性，以 至于不只是软件行业的人在读。现在终于找到读他的理由 了，可以感受一下大师的杰作。在读之前我已经读过了软件 工艺和极限编程，为什么留到最后读人月神话呢？主要是因 为我觉得一本能够流传 30年还被人们津津乐道的书，肯定 是本学要好好细读的书，所以留到了最后。按照前两篇读书 笔记的惯例，前面几段是一些我读书时的感受和收获，还有 一些对内容的评价。从这本书的内容来看，对于一个项目经理来说肯定会有 更大的收获，这本书主要是针对软件开发管理方面的内容， 这主要原因可能是因为作者以前就是项目的管理者，他是站 在管理者的角度写的。即便这样，对于一个从来没有参与过 真实项目开发，更没有领导过团队的我还是有一定的吸引 力，这本书中我最喜欢的就是前四章和没有银弹这章。这本 书里面为了论证某一观点，会举出许多实际的项目作为证 据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作 者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注 重文档，一个优质的文档就是项目成功的保证，这一点与传 统的软件工程很相似，但是却与极限编程的观点相悖。下面 就是一些读书的总结了。焦油坑1.编程系统产品开发的工作量是供个人使用 的、独立开发的构件程序的九倍。2. 编程行业的一些内在固有苦恼：I将做事方式调整到追求完美，是学习编程的最困难部 分。I由其他人来设定目标，并且必须依靠自己无法控制的 事物。I真正的权威来自于每次任务的完成。I任何创造性活动都伴随着枯燥艰苦的劳动，编程也不 例外I人们通常期望项目在接近结束时能收敛得快一些，然 而软件项目的情况却是越接近完成，收敛得越慢。人月I产品在即将完成时总面临着陈旧过时的威胁。神话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人程序开发队伍沟通模式贵族专制、民主政治和系统设计1.概念完整性是系统设计中最重要的考虑因素。2. 为了获得概念完整性，设计必须由一个人或者具有 共识的小型团队来完成。3. 对于非常大型的项目，将设计方法、体系结构方面 的工作与具体实现相分离是获得概念完整性的强有力方法。4. 纪律、规则对行业是有益的。外部的体系结构规定 实际上是增强，而不是限制实现小组的创造性。5. 体系结构、设计实现、物理实现的许多工作可以并 发进行。画蛇添足1.尽早交流和持续沟通能使结构师有 较好的成本意识，以及使开发人员获得对设计的信心，并且 不会混淆各自的责任分工。2. 结构师如何成功地影响实现：i. 牢记是开发人员承担创造性的实现责任；结构师只 能提出建议。ii. 听取开发人员在体系结构上改进的建议。3. 第二个系统是人们所设计的最危险的系统，通常的 倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。贯彻执行1.即使是大型的设计团队，设计结果也必须由一个或两个人来 完成，以确保这些决定是一致的。2. 必须明确定义体系结构中与先前定义不同的地方， 重新定义的详细程度应该与原先的说明一致。3. 出于精确性的考虑，我们需要形式化的设计定义， 同样，我们需要记叙性定义来加深理解。4. 允许体系结构师对实现人员的询问做出电话应答解 释是非常重要的，并且必须进行日志记录和整理发布。5. 项目经理最好的朋友就是他每天要面对的敌人 -独 立的产品测试机构/小组。 为什么巴比伦塔会失败？ 1.巴 比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。2. 因为左手不知道右手在做什么，从而进度灾难、功 能的不合理和系统缺陷纷纷出现。由于对其他人的各种假 设，团队成员之间的理解开始出现偏差。3. 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的 正式项目工作手册。胸有成竹1.仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。2. 构建独立小型程序的数据不适用于编程系统项目。3. 程序开发与程序规模成指数增长趋势。4. 当使用适当的高级语言时，程序编制的生产率可以 提高5倍。削足适履这一章主要是要解决项目投资与磁盘空间和内存之间 的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可 以忽略掉了。提纲挈领1.软件项目的要求：目标、用户手册、内部 文档、进度、预算、组织机构图和工作空间分配。2. 即使是小型项目，项目经理也应该在项目早期规范 化上述的一系列文档。这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目 经理给出了实实在在的操作步骤。未雨绸缪1.对于大多数项目，第一个开发的系统并不 合用。它可能太慢、太大，而且难以使用，或者三者兼而有 之。系统的丢弃和重新设计可以一步完成，也可以一块块地 实现。这是个必须完成的步骤，如果将开发的第一个系统丢 弃原型发布给用户，可以获得时间，但是它的代价很高。对 于用户，使用极度痛苦；对于重新开发的人员， 分散了精力; 对于产品，影响了声誉，即使最好的再设计也难以挽回名声。2. 用户的实际需要和用户感觉会随着程序的构建、测 试和使用而变化。3. 软件产品易于掌握的特性和不可见性，导致了它的 构建人员面临着永恒的需求变更。4. 目标和开发策略上的一些正常变化无可避免，事先 为它们做准备总比假设它们不会出现要好得多。5. 对于一个广泛使用的程序，其维护总成本通常是开 发成本的40 %或更多。6. 维护成本受用户数目的严重影响。用户越多，所发 现的错误也越多。7. campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。8. 缺陷修复总会以的机率引入新的bug。9. 在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。10. 同样，设计实现的人员越少、接口越少，产生的错 误也就越少。11. 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系 统退化到不可修复混乱的进程。干将莫邪项目经理应该制订一套策略，以及为通用工具的开发分 配资源，与此同时，他还必须意识到专业工具的需求。祸起萧墙1. 一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补2. 根据一个严格的进度表来控制项目的第一个步骤是 制订进度表，进度表由里程碑和日期组成。3. 里程碑必须是具体的、特定的、可度量的事件，能 进行清晰能定义。4. 如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。另外一面1.对于软件编程产品来说，程序向用户所呈现的面貌与提供给 机器识别的内容同样重要。2. 即使对于完全开发给自己使用的程序，描述性文字 也是必须的，因为它们会被用户和作者所遗忘。3. 文档能在整个软件开发的生命周期对程序员克服懒 惰和进度的压力起促进激励作用，但向编程人员成功地灌输 对待文档的积极态度是一件困难的事情。4. 为了使文档易于维护，将它们合并至源程序是至关重要的，而不是作为独立文档进行保存。没有银弹人狼的传说可能有人听过也可能没听过，人狼是一种具 有人和狼两种特征的恐怖生物，而银弹是消灭它的一种最有 效的子弹，如果看过吸血鬼传说也许就能和容易的理解 这一点。作者将软件开发比作人狼，而将提高软件开发效率 的方法比作银弹。作者预言未来十年，想要试图通过寻找一 种有效地银弹将软件开发效率提高一个甚至几个数量级，这 种银弹不可能出现。没有银弹这篇文章里作者列举出了当时一些非常先进 的技术或思想理念，例如 ada和其他高级编程语言、面向对 象编程、人工智能、专家系统、”自动"编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一 定程度上提高了软件开发的效率，但是始终没有达到银弹的 效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银 弹能够让软件开发产生一次革命。焦油坑依然存在软件工程的焦油坑在将来很长一段时间内会继续困扰 着人们。由于软件系统多变性和错综复杂性，这个行业只能 是一步一个台阶的往上爬，而出现银弹的希望在我们可以想 象的时间范围内是非常渺茫的。我们将长期与焦油作斗争。第三篇：人月神话读书笔记第1章焦油坑这一章分成两个部分：?程序、程序产品、编程系统、编程系统产品的概念?程序员的工作性质比较有意思的是第一部分的四个概念。在作者的眼中，程序就是一堆代码，任何人可以宣称自 己会编程，但是编程得到的只是程序，而不是产品。程序要 成为程序产品，需要有明确的输入、功能和输出，经过完备 的测试，具备合格的文档，使之功能可靠，维护易行编程系统是从系统的角度来看待功能完整的程序模块， 要求程序要具备语法和语义精确的接口，能够与其他的程序 进行流畅的交互。相比程序产品来说，不仅仅要严格测试程 序自身的输入、处理、输出，还要测试与不同程序之间的交 互，因为很多bug其实是隐含在不同功能模块的交互过程中 另外编程系统还要考虑程序之外的软硬件运行环境。呵呵， 只有经过了集成测试之后才能称之为编程系统。最高级的形式是编程系统产品，从书中的表述来看，就 是编程系统+各类文档，文档是为了后续维护和升级方便而 准备的。智力产品如果没有说明书真是一场噩梦啊，之前我 们经历过的不少系统到了后续维护的时候发现文档补齐，维 护人员真是伤透脑筋，最后问题太多了索性就提议推倒重 做。可以说如果是文档齐备一点，我们公司很多系统的寿命 是可以更长的。第2章人月神话