神话

《人月神话》读后感2

岸上的船儿,如同海上的灯塔,无法移动。 首先应用这句话是因为我觉得这句话写的特别美,特别形象。 史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈,焦油纠缠得越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后 ......
读后 读后感 神话

人月神话阅读笔记1

《人月神话》是一本经典的软件工程书籍,作者弗雷德里克·布鲁克斯在书中提出了许多关于软件开发过程的思考和经验,对软件开发领域产生了很大的影响。下面分两个部分记录我的阅读笔记: 部分一:我过去是怎么做的、为什么这样不好 在我以前的软件开发项目中,我通常会认为如果向团队增加更多的人力,就可以更快地完成任务 ......
神话 笔记

人月神话阅读笔记2

在读完《人月神话》后,我反思了自己在软件开发过程中的做法,并认识到以前采用的一些方式并不是最好的选择,下面是我的阅读笔记: 过去的做法:以人数为目标,尽快完成项目 在我以前的软件开发项目中,我通常会将项目进度视为一个目标,并以人数来实现这个目标。我的想法是招募更多的工程师,以期望可以更快地完成项目任 ......
神话 笔记

《人月神话》读书笔记1

第一、二章读书笔记: 《人月神话》的前两章主要对软件工程中的问题和挑战进行了阐述。作者指出,软件开发是一项复杂的过程,需要系统性和规范性的方法来管理和解决各种问题。然而,软件工程师却面临着很多困难。第一个挑战在于“复杂性”,即使一个看似简单的项目,也有很多的细节和因素需要考虑。第二个挑战是“可变性” ......
神话 笔记

《人月神话》读书笔记2

第三章读书笔记: 第三章主要讲了如何在项目管理中处理现实和时间的矛盾。作者认为,对于大型软件项目,为了避免时间延误和成本增加,需要将项目拆分为更小的模块,并且允许扩展和变更。同时,要保证各个模块之间的协调和集成。 作者提出了三种独立的应对时间危机的方法:第一种方法是“移动人力”,在不影响时间安排的情 ......
神话 笔记

《人月神话》读书笔记3

第四章读书笔记: 第四章围绕着软件开发过程中的文档、开发和测试的问题进行了探讨。作者提出了在开发和测试中“少写文档”的思想,认为写作精简的文档能帮助开发人员更快地投入到程序开发和测试工作中去。作者讲述了他在实践中贯彻的“原型方法”、“视觉化方法”和“前置设计”的具体实现,倡导将文档尽可能地简化和分解 ......
神话 笔记

人月神话读后感

《人月神话》是一本由弗雷德里克·P·布鲁克斯所著的软件工程经典之作。这本书对于软件开发领域有着深远的影响,它揭示了许多项目管理和软件开发过程中的常见问题,并提出了一些宝贵的经验和教训。在读完《人月神话》后,我对软件开发的理解有了一些新的认识和思考。 首先,我深刻认识到软件开发是一个复杂的过程。作者通 ......
读后 读后感 神话

《人月神话》阅读笔记

这学期老师给我们推荐了一本在软件领域拥有深远影响力和畅销不衰的著作——人月神话。布鲁克斯博士为为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验,该项目堪称软件工程项 ......
神话 笔记

《人月神话》阅读笔记2

今天这篇阅读笔记主要讨论一下《人月神话》中巴比伦塔失败的原因,以及如何组织一个队伍才能保证一个项目或系统能够正常的运行。 古巴比伦塔是《创世纪》中记载的一个建筑。他是人类继诺亚方舟之后的第二大工程壮举,但是它失败了。那么他为什么会失败呢?在这项工程中,它具有所有资源:清晰的目标、人力、材料、足够的时 ......
神话 笔记

《人月神话》阅读笔记3

今天这篇阅读笔记主要讨论《人月神话》中的“人月神话”以及组建“外科手术队伍”。 首先介绍一下什么是人月神话。我以前听人月神话的时候总是觉得很玄幻,以为这是一个神话故事之类的。我相信很多刚刚听到这个词汇的人都会这么认为,但是经过阅读发现,人月神话并不是神话故事。这是一种软件开发过程中的度量单位。估计完 ......
神话 笔记

《人月神话》读后感6

回想起过去的软件开发经验,我也曾犯过“人月神话”的错误。在项目进度拖延的情况下,我的第一反应就是增加更多的开发人员,希望能以此来弥补进度上的不足。但是,我们团队中并没有好的沟通和协作机制,导致新成员加入后会产生大量的重复工作以及低效的沟通与协作,反而导致了进度的继续拖延。 通过阅读《人月神话》,我领 ......
读后 读后感 神话

《人月神话》读后感5

作为一名大学生,我认为《人月神话》对于我的职业规划和成长非常有启发作用。 在大学学习中,我们经常会接触到各种课程和项目,那么如何在项目中更好地发挥个人能力并协调团队呢?《人月神话》为我们提供了宝贵的思路。 首先,我们要认真分析项目的需求,并制定详细的计划和工作任务。同时,我们需要建立高效的沟通和协作 ......
读后 读后感 神话

《人月神话》读后感4

作为一名计算机专业的大学生,我深知软件开发项目中团队协作的重要性。《人月神话》这本经典著作为我们提供了很多关于如何协调和管理团队的宝贵经验。 在软件开发项目中,我们需要建立高效的沟通和协作机制,确保每个成员理解自己的工作任务和其他成员的工作内容,以避免出现重复或者遗漏的情况。同时,要强化团队合作意识 ......
读后 读后感 神话

读书笔记——人月神话2

“人月”指项目预估和进度安排中使用的工作量单位,比如一个项目需要3个人耗费四个月的时间,衡量这个项目的工作量就用12人月表示。在本文中,作者认为“用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话,它暗示着人员数量和时间是可以相互 替换的。”人数和时间可以互换的情况仅限于任务完全可分解且人员不 ......
神话 笔记

读书笔记——人月神话3

在写项目申请书时,经常会遇到两个问题。其一,不同的人负责项目申请书的不同部分,最后在整合到一起时往往会让人产生项目需求和功能不完全对应的感觉,整个项目明显有拼凑的痕迹,显得不伦不类;其二,在决定产品实现什么功能时,往往会很贪心的把所有功能都往上加,最后产品没有针对性,更没有特色。在一个项目不可避免的 ......
神话 笔记

人月神话4

它们挣扎得越猛烈,焦油就纠缠得越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。 表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。对问题的麻烦程度,每个人似乎都会感到惊讶,并且很难 ......
神话

人月神话5

1.开发一个项目,我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同,有着很大的变化,进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况:某个任务可 ......
神话

人月神话6

通过看人月神话的阅读,明白了《人月神话》探索了达成一致性的困难和解决的方法,并探讨了软件工程管理的其他方面。既有很多发人深省的观点,又有大量软件工程的实践,为每个复杂项目的管理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰,保持产品本身的概念完整性是一个至关重要的需求。而我们 ......
神话

读后感——人月神话

《人月神话:软件项目管理之道》(英语:The Mythical Man-Month: Essays on Software Engineering)是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集,全书讲解软件工程、项目管理相关课题,被誉为软件领域的圣经,内容源于作者布鲁克斯在I ......
读后 读后感 神话

《人月神话》读后感终

今天复习完所学的知识后,在看了一下这本书,也算是读完了,下面是剩下的内容概要 "No Silver Bullet Refired"(重新点燃的没有银弹):这一章重新讨论了软件开发中是否存在所谓的“银弹”,即单一技术或方法能够解决所有软件开发难题的观点。 "Propositions of The My ......
读后 读后感 神话

人月神话读书笔记之二

上次阅读的主题是团队,这次依然如此,上次提及的是对于我们做项目,团队的重要性,而这次我们则要说交流在团队中都发挥着深刻的作用。 每个团队之间都应该拥有多种方式来进行相互之间的交流,可以是相对休闲的茶话会,也可以是正式项目工作手册(共享资源)。为了方便团队间的交流,我们就可以看出交流对于团队的重要性, ......
神话 笔记

人月神话读书笔记之三

通过一段时间的阅读,人月神话终于进入尾声,即将结束本书的阅读,同时,我也了解到了不少关于程序员的信息,越是了解,就越觉得自己和理想之间差距很大。 以前,我觉得,程序员嘛,想怎么编就怎么编咯,反正最后能够交差就行,自己看得过去就OK啦,后来我才发现,我的想法是错误的,自我满足本身就是一件错误的事情,而 ......
神话 笔记

《人月神话》 ——十三、十四、十五章

今天闲来无事,又抽出了一些时间时间来读这一本书,快要读完了也,一天一天一点点的摩,居然不知不觉读了这么多,十分惊讶,下面和往常一样,是我对书的内容的概述。 第13章: "The Whole and the Parts"(整体与部分) 这一章讨论了软件系统中整体与部分之间的关系。布鲁克斯强调了模块化和 ......
神话

《人月神话》 ——十、十一、十二章

第十章: "The Documentary Hypothesis"(文献假说) 这一章讨论了软件文档的重要性和挑战。布鲁克斯提出了文献假说,即软件开发中的文档是一种重要的沟通工具,但在实践中往往存在问题。他探讨了文档编写的难点、文档的价值以及文档的管理和维护策略。 第十一章: "Plan to Th ......
神话

《人月神话》 ——七、八、九章

以下是我读的这本书的第七、八、九章的内容。 第七章: "Why Did the Tower of Babel Fail?"(巴别塔为何失败?) 这一章主要探讨了软件开发中的沟通问题。布鲁克斯以巴别塔的故事为比喻,讲述了不同团队成员之间语言、文化和沟通障碍的影响。他强调了软件开发中沟通的重要性,并讨论 ......
神话

《人月神话》 ——五、六章

今天又抽出了一点时间来读了一下《人月神话》这一本书,临近考试周,时间也比较忙,但还是抽出了一些时间来读了一下这本书。 第五章的《第二系统效应》讲的是指人们在进行开发时,出现由于过度思考、过度分析或过度关注细节而导致程序设计错误或性能的折扣。通俗的讲,就是程序开发后能跑起来时候,要减少所谓的“二度设计 ......
神话

6.3《人月神话》阅读笔记

第十四章-祸起萧墙。当人们听到某个项目的进度发生了灾难性的偏离时,可能会认为项目一定遭受了一系列重大灾难。然而,灾祸来自白蚁的肆虐,而不是龙卷风的侵袭。同样,项目进度经常以一种难以察觉,但是残酷无情的方式慢慢落后。这个真的深有感触,一般都是很小的地方跟自己说,这个地方有特殊处理先放一下,那个地方回头 ......
神话 笔记 6.3

人月神话4

阅读完第四章后,我认为其中最重要的观点是:软件开发过程需要建立一个可靠的、可重用的、具有稳定接口的抽象模型。这个模型可以让开发者更容易地理解和处理业务需求,同时也能够提高代码的可维护性和可重用性。 此外,作者还提到了概念模型的重要性,即在软件开发过程中明确业务逻辑和数据结构的概念模型。通过建立一个准 ......
神话

人月神话3

第三章 外科手术队伍 Harlan Mills 对于小型团队的分工建议: 外科医生,即首席程序员或技术 leader,负责定义功能性能说明书、设计程序、编码、测试、书写文档。需要极高的天分、丰富的经验以及大量的系统知识。 副手,外科医生的后备,主要作为设计的思考者,沟通讨论方案。 管理员,也就是老板 ......
神话

人月神话阅读笔记3

在之前我的阅读笔记(读后感)更新到2就没有更新了,大概是忘记继续读这本书,转身去读构建之法了。 今天来写一篇人月神话的阅读笔记。 简单杂碎的记一些重点 之前读到了第五章的画蛇添足 第六章是贯彻执行 设计结果必须由一个人或两个人完成,以确保这些决定是一致的。 手册 形式化定义 直接整合到代码 会议 多 ......
神话 笔记