神话

第2章-人月神话 2.1为什么项目会滞后 缺乏合理的时间进度是造成项目滞后的最主要原因 实际上这是一句矛盾又合理的话：矛盾的点在于，我们总是已经估算了项目的时间，对于项目需要的功能和模块都进行了划分。每一个部分我们都给了必要的时间安排。按道理来说，其实不应该出现时间上的问题而导致项目滞后但是这句话却 ......

第4章：贵族专制、民主政治和系统设计概念的完整性是系统设计中最重要的考虑因素 第5章：画蛇添足在开发第1个系统时，结构师倾向于简洁，之后不断产生装饰和润色。第二个系统是最“危险”的，往往会过度设计。而随后的系统由于之前的经验会相互验证，因此能识别出不够通用的部分。 第6章：贯彻执行设计结果必须由一个 ......

第十三章—整体部分。防范bug的定义。系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配，是大多数致命和难以察觉的bug的主要来源。 好的自顶向下设计从几个方面避免了bug： 首先，清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。 其次，模块分割和模块独立性避免了系统级的bu ......

第七章—为什么巴比伦会失败？巴比伦的失败是因为缺乏交流。他们无法交谈，从而无法合作，以至于工作陷入停顿。因为不知道对方在做什么，许多小组修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。团队组织的目的是 ......

第一章—焦油坑。焦油坑是作者用来形容大型系统开发的一个概念。在史前时代，恐龙、猛犸象、剑齿虎这些大型食肉动物碰到焦油坑也是没有办法挣脱的，而且越用力就越容易被沉入坑底。这就像我们大型系统开发的工作。我们认识到真正的大型编程系统产品并不是简单程序的简单堆叠。这也就是所谓的“焦油坑”。既然是明知是焦油坑 ......

第一章-焦油坑。焦油坑是作者用来形容大型系统开发的一个概念。史前时代，恐龙、猛犸象、剑齿虎这些大型食肉动物碰到焦油坑也是没有办法挣脱的，而且越用力就越容易被沉入坑底。这种场景就像极了大型系统开发的工作。基本上一个大型的编程系统产品的开发成本会是单个的简单程序的9倍。这里的编程系统产品是指的由很多编程 ......

《人月神话》是软件工程大师弗雷德里克·布鲁克斯所著，是一本经典的软件开发管理书籍。书中讲述了在软件开发过程中的种种问题和挑战，并给出了一些解决问题的建议和方法。 首先，布鲁克斯指出，没有任何一种单一的方法或工具可以解决软件开发中所有的问题，这也被称为“没有银弹”原则。因此，我们需要不断尝试和实验，以 ......

首先，布鲁克斯提出了“没有银弹”的原则：没有任何一种单一的方法或工具可以解决软件开发中所有的问题。因此，我们需要不断尝试和实验，以找到最适合我们项目的方法。 其次，布鲁克斯强调了“延迟演示效应”的问题。他认为，开发人员往往会将演示功能的时间推迟到最后，这可能会导致无法及时发现和解决问题。相反，应该尽 ......

画蛇添足这一章主要是告诫系统设计师们，不要过度设计，尤其是在第二个系统(第一个系统完成后开发的第二个系统)中，不要过度自信，保持警觉，避免初始的概念和目标得到充分的体现，而不让一些次要的功能喧宾夺主。(是不是可以说是保持初心？) 贯彻执行概念的完整性不仅仅要在专制的贵族和系统设计师这一层面上充分传达 ......

第8章：胸有成竹软件工作量是根据规模成指数型增长的，指数大约是1.5，即：工 作 量 = 常 数 × 指 令 的 数 量 1.5 工作量 = 常数 \times 指令的数量^{1.5}工作量=常数×指令的数量 1.5 实践是最好地老师实践是最好地老师，但智者还能从其他地方有收获。 第9章 削足适履这 ......

对于工作量和工作时间的估算，对于所有的设计者来说都是一个难题。因此我们也在思考一个问题，对于产品的设计，第一次可能因为经验不足出现各类问题和各种错误，第二次会不会比第一次好一些。毕竟我们默认一个人在某个领域的深耕会获得大量的经验，从而有助于他将工作做好。然而《人月神话》的结论却兜头给我们浇了一盆冷水 ......

“人月”难道真的无法换算吗？添加人手对于项目的进展难道一点作用都没有吗？对此，书中也是予以了解答“人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。”上述的条件在编程领域几乎是不可能的，可以想见，在实际的工作中也极少存在有这些既可以分解，又不需要交流的工作 ......

第七章的主题是为什么巴比伦塔会失败？书中写道巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。在日常编码中我们要明白团队的重要性，团队在一个完美的项目中是不可缺少的存在，在团队中要学会交流，不要“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假 ......

为什么“人月”是“神话”。小学的时候我们都做过这样的应用题：“工厂需要加工一批零件，安排5名工人的话需要10小时完成，那么安排25名工人加工，多少小时可以完成”之类的。对于这类题目，小学一二年级的学生都可以轻松得到答案。也正是如此，如今的工作中，仍有不少同仁秉持这样的小学生思维来衡量工作量，跟进工作 ......

人月神话的观点：是与非这一章，也是20周年版本新增的内容，20年的发展让初版的一些观点变得过时，但是仍然有不少观点仍然适用，因而作者在这一章里把之前的每一章的主要观点都抽离出来，并对已经过时了的观点做了说明，可以说这一章是整本书的精华了吧。 20年后的人月神话这一章很长很长，算是一篇单独的文章，讨论 ......

《人月神话》是一本软件工程领域的经典著作，作者是著名的计算机科学家弗雷德里克·布鲁克斯。这本书主要讲述了软件开发过程中的一些问题和解决方法，以及如何管理一个软件项目。以下是我对这本书的一些阅读笔记。 首先，布鲁克斯在书中提到了一个非常重要的概念，即“人月”。他指出，软件开发的进度不仅仅取决于时间，还 ......

听到名字，如果不观看内容的话，我还以为是一本关于神话的小说，在读了《人月神话》这本书之后才知道《人月神话》这本书主要讲的是软件工程中人于团队关系的。 第一章的主题是焦油坑。主要讲的是编程系统产品开发的工作量是供个人使用的、独立开发的构建程序的九倍，我估计软件构建产品化引起了三倍工作量，将软件构件整合 ......

最近读了一本叫做《人月神话》的书，这本书是由软件工程大师Fred Brooks所著，是一本关于软件开发的经典之作。在这本书中，作者通过自己多年的实践经验，深入浅出地阐述了软件开发中的一些基本原则和方法，对于我们软件开发人员来说，是一本非常有价值的参考书。在这本书中，作者提出了一个非常有名的观点，就是 ......

第一章作者将软件系统开发比作吞噬了恐龙、剑齿虎等史前巨兽的焦油坑，许多大大小小的团队被软件开发的焦油坑所吞噬。 作者首先介绍了变成系统产品的演进，指出程序、编程系统、编程产品、编程系统产品几个概念间的区别，其中只有编程系统产品才是真正可用的面向用户的产物。 然后作者分别介绍了编程的乐趣和苦恼，当然这 ......

《人月神话》讲了什么一开始我觉得这本书重点是在软件工程，但后来我觉得更准确的说法是，《人月神话》是讲软件工程中人与团队关系的。一个由个人完成的“小”程序，和一个由团队完成的“大”程序，有根本性的不同，《人月神话》将讨论的是那些由团队进行开发的大型程序。另外，软件工程的项目管理也和其他类型的项目管理有 ......

作为一个学科需要更广泛的信息理论，它能够量化静态结构的信息内容，就像针对交互流的香农信息论一样。这已经超越了能力。系统复杂性是无数细节的函数，这些细 节必须精确而且详细地说明或者是借助某种通用规则，或者是逐一阐述，但决不仅仅是 统计说明。仅靠若干人不相干的工作，是不大可能产生足够的一致性，能用通用规 ......

书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流 ......

这两天把人月神话的每一个章节都读了一下，可能是因为没有做过大项目的原因吧，有很多地方都不是很懂，所以也谈不上是读后感，只能说是阅读笔记吧。 人月神话这一章，作者主要介绍了软件开发项目在进度安排上经常出现的问题。首先，由于我们对项目开发的进度估计过于乐观，我们估计出来的工作量通常会低于实际需要的工作量 ......

过去是怎么做的： 我只经历过两人组队和三人组队，我无法分辨当时的组队情况分工什么的是好是坏。 为什么这样不好： 所以，这个问题我无法回答。我只能说，我们将各个题目分开成细化的部分，然后分成员去解决。 解决办法： 还是要多学习基础知识，在组队交流编程中，可以明显的感受到自己与其他人的差距，从而更加激励 ......

在刚刚进入软件工程学习时，老师总会时不时向我们提起一些关于“软件项目开发的完成与增加人员的问题”这句话听起来通俗易懂，但实现起来却遇到了相当大的困难，这是我在阅读完成《人月神话》时最大的感受，我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到 ......

第1章：焦油坑大型系统开发就像一个焦油坑，很多强壮的动物都在其中挣扎。 如果将一个 “程序” 提升为 “产品”（意味着：通用化、测试、文档、维护）需要3倍的时间；如果将一个 “程序” 提升为 “系统”（意味着：接口、系统集成），需要3倍时间；而如果将一个 “程序” 提升为 “系统产品”，就需要9倍了 ......

这本书虽然有做过一些细小的修订，用更新的思想进行扩充，但我还是认真阅读了这本书的第一版序言。其中，作者提到在很多方面，管理一个大型的计算机编程项目和其他行业的大型工程很相似，这一点虽然我没有亲身经历过，却能感同身受作者的思想和态度，我想，任何一件或大或小的完整工程都是有相通之处的，甚至是每一件事情。 ......

过去是怎么做的： 我总是写完全部的代码再进行测试。 为什么这样不好： 如果bug很多，就会导致最后的提交时刻，要一次次的重复查找bug并解决，甚至推翻重写代码，这是致命且让人感到十分枯燥的。 解决办法： 最好按照书中的编程习惯，制定一个恰当的解决测试办法和时间进度安排，避免出现最后时刻才测试的状况， ......

过去是怎么做的： 我认为编程的乐趣小于苦恼，似乎痛苦的事情更多。而且编程中找bug是更令人烦恼的事情。 为什么这样不好： 会使我丧失掉编程的兴趣，让我失去动力。 解决办法： 更仔细写代码，不要写太多bug，并且一开始就注重代码的规范性，避免日后看不懂，从而丧失编程动力与乐趣。 具体读后感： 焦油坑： ......

焦油坑： 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题 ......