精华内容
下载资源
问答
  • 对《人月神话》初次读后的感悟,1000字左右~~~~~~~~~~~~~~~~ 专业内容不是特别多,总体对书中的观点进行了归纳
  • 人月神话读后感

    2014-02-13 16:53:36
    人月神话》是一本对于软件开发和项目经理职业有着启发式的重要作用,这是本人的一些读后感
  • 人月神话读后感

    万次阅读 多人点赞 2014-11-11 13:34:50
    人月神话读后感  中国科学技术大学软件杨旋原创  人月神话这个名字对我来说很有吸引力,我以为它会是一本讲述计算机历史神话的故事。当我看到第二章我才知

    人月神话读后感

     中国科学技术大学软件杨旋原创

           人月神话这个名字对我来说很有吸引力,我以为它会是一本讲述计算机历史神话的故事。当我看到第二章我才知道原来这个“人月“是我们项目工程中估计和进度安排中使用的工作量单位:人月。读完这本书我还是没有明白很多东西,因为得项目经验不足,不能站在巨人的肩膀上看懂这本书。但是看完之后还是有一些小小的感悟。

       《人月神话》是一本经典的软件工程的巨作,作者布鲁克斯(FrederickP.Brooks)被誉为“IBM System/360之父“,他曾是这一项目的项目经理,后来在设计期担任360操作系统的项目经理。由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士曾经早期担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年,他还荣获美国计算机领域最高奖图灵奖。

        所有的编程人员都有乐观主义,总是相信自己的代码是肯定能运行的。所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。而现实往往不是乐观,在项目的进展过程中会存在各种不可预知的问题。在这个时候项目经理就会为项目增加人员,然而增加人员反而导致项目进度越来越慢。因为新增加的人员还需要培训,需要时间去了解项目的内容和进展情况。在投入了更多的人力的时候,经理发现项目进度反而更慢他就会投入更多的人力,这种恶行循环导致项目的失败。

        虽然0S/360失败了,但是它在开发的过程中解决了很多技术难题。它的开发过程成就了这本“人月神话“。这也让我想明白为什么大家都会觉得在项目实践中我们才可以学到更多。没有项目,你不会去想有什么问题。但是在项目中遇到问题的话,你最好的求助方式是网络和书籍,而且如果在遇到问题的时候能深入研究书籍的话你才会进步的比较快。

        让我印象最深的是巴比伦塔的管理教训里面的一句总结为什么巴比伦塔为什么是一个失败的工程:那为什么项目还会失败呢?他们还缺乏些什么?
        两个方面——交流, 以及交流的结果——组织。 他们无法相互交谈, 从而无法合作。 当合作无法进行时, 工作陷入了停顿。在这次高软的工程实践中我就深刻体会到这句话的重要性。我们组的项目所有代码都是我一个人写的,我的队友负责帮我优化UI。我告诉他我需要哪些东西,但是他完全按照他的理解做了一个完全不是我想要的东西。我以为我和他讲的很清楚,可是还是导致我们的项目在这里浪费了一些时间。最后总结,我和他交流有问题,还有就是他本身对于我们的项目是不理解的,所以导致他按照他的想法去做的时候就会和我的想法产生误差。

    团队如何进行相互之间的交流沟通呢?通过所有可能的途径。

    一.非正式途径

       清晰定义小组内部的相互关系和充分利用电话,能鼓励大量的电话沟通从而达到对所书写文档的共同理解。

    二.会议

       常规项目会议。会议中,团队一个接一个地进行简要的技术陈述。 这种方式非常有用,能澄清成百上千的细小误解。

    三.工作手册

    在项目的开始阶段,应该准备正式的项目工作手册。

    巴比伦塔可能是第一个工程上的彻底失败,但它不是最后一个。交流和交流的结果—组织, 是成功的关键。 交流和组织的技能需要管理者仔细考虑, 相关经验的积累和能力的提高同软件技术本身一样重要。

    文档

        看完整本书我看到作者一直再强调文档的重要性,他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座。但是效果都非常的的不好,他们知道如何来写出优秀的文档,但是他们缺乏热情。所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作。结果显示这种方法的效果还是挺好的。那我们在开发的过程中需要什么样的文档呢?

       不同用户需要不同级别的文档。 某些用户仅仅偶尔使用程序, 有些用户必须依赖程序,还有一些用户必须根据环境和目的的变动对程序进行修改。使用程序。 每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很
    少的总结性内容,无法达到用户要求,验证程序。 除了程序的使用方法, 还必须附带一些程序正确运行的证明, 即测试用例。修改程序。 调整程序或者修复程序需要更多的信息。显然,这要求了解全部的细节,并且这些细节已经记录在注释良好的列表中。 和一般用户一样, 修改者迫切需要一份清晰明了的概述。

        另外一个让我印象深刻的观点是:要保证一个项目的进度被大幅度推迟,制定进度表很重要。进度表由里程碑和完成时间组成。里程碑必须具体,明确,可界定。某一里程碑要么到达,要么没有到达,不应该是80%到达的。而我的经验是,制定进度表非常重要,而且要求制定者有很强的技术背景,这样才能对碰到的问题和可能花掉的时间做出更准确的估计。

     

    整体部分(部分如何高质量的集成为一个整体)  

    转载http://blog.sina.com.cn/s/blog_493a84550100bh0b.html

    根据英文内容这里最好应该翻译为整体和部分。为了得到整体的可运行和高质量的软件,我们需要在哪些方面进行改进和下功夫。这章主要从消除Bug的设计,构件单元测试和系统集成调试三个方面来谈。
        之所以谈消除Bug的设计,就让我们更加意识到质量是设计出来的,而不是测试出来的。V.A.Vyssotsky提出许许多多的失败完全源于那些产品未精确定义的地方。这要求我们在需求和设计阶段要保持高质量,减少缺陷泄漏。对于需求要有详细的需求规格说明书,对于设计我们提倡的是从顶向下逐步求精的设计,而这里面最重要的就是结构化的设计方法和思路,不论是面向结构和面向对象其实都要遵守结构化的设计方法。在需求规格说明书完成后要尽快提交给测试小组编写测试用例,测试小组需要Review需求以确认需求完整,无歧义和可测试。
        在构件单元测试中讲的很多内容暂时无法和我们现在实际软件开发所对应,但是现在的敏捷开发方法论仍然强调测试驱动,先编写单元测试用例再开发代码,足见单元测试在敏捷软件开发中的重要地位,它不仅仅起到了测试的作用,更重要的是通过测试用例的编写喜欢需求和完善设计思路。
        对于大型软件系统,产品集成和集成测试具有重要的地位,为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试,否则单元测试的问题将遗留到集成测试阶段导致问题复杂化;其次是搭建充分的测试平台,测试平台往往需要编写测试代码,特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更,最好是阶段化的定期变更。

    祸起萧墙(进度管理和监控的方法)
    慢性的进度偏离是士气杀手,这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付,最重要的就是要防微杜渐。重大灾害是比较容易处理的,它往往和重大的压力、彻底的重组、新技术的出现有关,整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
        进取对于杰出的软件开发团队,同优秀的棒球队伍一样,是不可缺少的必要品德。 为了加强我们对进度的监控,里程碑的定义就至关重要了。里程碑的选择只有一个原则,那就是,里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。以下是一些反面的例子,例如编码,在代码编写时间达到一半的时候就已经“90%完成”了;调试在大多时候都是“99%完成”的;“计划完毕”是任何人只要愿意,就可以声明的事件。
        里程碑有明显边界和没有歧义,比它容易被老板核实更为重要。如果里程碑定义得非常明确,以致于无法自欺欺人时,很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊,老板就常常会得到一份与实际情况不符的报告。毕竟,没有人愿意承受坏消息。这种做法只是为了起到缓和的作用,并没有任何蓄意的欺骗。
        在进度跟踪和管理上,必须要在整个团队中树立这种观念,就是要尽可能早的完成相关的任务,而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
        当进度出现偏差后,项目经理往往把问题掩盖起来,而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失,但是往往情况并不是这么简单。因为很多时候 引起进度的偏差往往存在一些问题的根源,而这些根源往往是需要老板提前介入并采取一些行动,因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越 俎代庖,将能鼓励诚实的汇报。

    没有银弹:没有任何技术或管理上的进展, 能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。现代软件系统中这些无法规避的内在特性:复杂度、一致性、可变性和不可见性。那么软件开发总是非常困难的。天生就没有银弹。没有神话般的解决方案, 以及将来也不会有。

    复杂性: 软件系统与计算机、建筑或者汽车大不相同,后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难,带来了软件产品的进度,质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难,还引发了很多管理上的问题。它使全面理解问题变得困难,从而妨碍了概念上的完整性。(在软件产品开发工厂化的过程中,我们要注意到仍然解决的是次要因素,比如加大公用组件开发,加大平台和框架的建设,而业务功能本身导致的复杂性是无法避免的。)

    一致性:在某些情况下,因为是开发最新的软件,所以它必须遵循各种接口。另外一些情况下,软件的开发目标就是兼容性。在上述的所有情况中,很多复杂 性来自保持与其他接口的一致,对软件的任何再设计,都无法简化这些复杂的特性。

    可变性:系统中的软件包含了很多功能,而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中,经常发生两种情况。当人们发现软件很有用时,会在原有应用范围的边界,或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能,又对软件提出了很多新用法的用户们。简言之,软件产品扎根于文化的母体中,如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着,这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化,在需求,设计和编码过程中都需要考虑如何快速响应变化,如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路,强调测试驱动的思路其根本目的就是为了快速响应变化,降低变化带来的风险。)
        不可见性:除去软件结构上的限制和简化方面的进展,软件仍然保持着无法可视化的固有特性,从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程,也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。

    对没有银弹的感触转载http://blog.sina.com.cn/s/blog_493a84550100bhp9.html

        1.现在有很多快速开发平台,但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的,特别是在业务场景比较复杂情况下,编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设,在原有的框架基础上我们来构建一个产品开发平台,将跟业务关系不大的权限模型,工作流引擎等集成进去,将常用的可复用组件集成进去,加快开发速度。
        2.不要在追求自动编程平台上下功夫,可以在加强组件复用和技术平台建设上下功夫。
        3.要多从开发模式的改进上来解决没有银弹所提出的各种实际问题,虽然不能够彻底解决,但是可以通过努力来改进。比如增量迭代的开发模型,快速原型法,测试驱动,高级语言和图形化编程等。


    二十年后再续人月神话

        人月神话书如其名一样震撼人心,它引起了许多别的领域的读者对此进行评价。律师,医生,社会学家,心里学家,和软件人员一样对此书提出评论和建议。人们经常通过比较计算机软件开发生产率和硬件制造生产率来支持这个观点,后者在 20 年内至少翻了 1000 倍。正像第 16
    章所解释的,反常的并不是软件发展得太慢,而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。很多年后作者还是会被道“你现在认为哪些在当时就是错误的?哪些是现在才过时的?哪些是软件工程领域中新近出现的?”很多年来人们对软件生产率和影响它的因素进行了大量的研究,特别是在项目的人员配备和进度之间的平衡。最充分的一项研究是:Barry Boehm 对 63 个项目 的调查,其中大多数是航空项目和 25个 TRW 公司的项目。他的《软件工程经济学》(Software Engineering Economics)不但包括了很多结果, 而且还有一系列逐步推广的成本模型。 尽管一般商业软件的成本模型和根据政府标准开发的航空软件成本模型中的系数肯定不同, 不过他的模型使用了大量的数据来支撑。我想从现在起,这本书将作为一代经典。他的结果充分地吻合了《人月神话》的结论,即人力(人)和时间(月)之间的平衡远不是线性关系,使用人月作为生产率的衡量标准实际是一个神话。

        昨天我又把书翻了一遍,发现大部分内容都是涉及到团队,人和沟通。对于大型软件工程项目 强调人的重要性。在开篇讲开发人员的职业乐趣,后面又通过巴比塔的沟通重要性,在外科手术队伍中的组件和分工。这些都是涉及到团队中人和交互,只有一个有了积极心态和热情的沟通团队,才可能成就一个伟大的团队。从最后的没有银弹,再次肯定开发工作是一种高智力的脑力工作。

    展开全文
  • 起初看到人月神话这个名字让我很意外,就像看到没有银弹这个书名一样,我原以为是一本讲述了计算机发展历史中如同神话般的历史事件的书,但是在阅读完这本书发现并不是这样,或者说绝大部分不是这样的。...

    写在前面的话

    平时上课后,老师布置了不少经典的软件开发的书让我们阅读并写一篇阅读笔记作为课程笔记,因此有了这个系列。由于有时候为了赶作业有的文章写的不是很全面,希望大家见谅。


    正文

    起初看到人月神话这个名字让我很意外,就像看到没有银弹这个书名一样,我原以为是一本讲述了计算机发展历史中如同神话般的历史事件的书,但是在阅读完这本书后发现并不是这样,或者说绝大部分不是这样的。

    直到看了一会才知道“人月”说的不是人和月亮moon,而是月份month,主题是人数与工作所需要的时间月份之间的关系。这本书由被誉为“IBM System/360之父”的布鲁克斯所写,主要收录了人月神话、没有银弹以及近年来对这两部作品的重新回顾,虽然我犹豫能力有限,不能全部都懂,但是站在巨人的肩膀上还是有诸多的感触。

    在第一章的焦油坑中,作者就用一个形象的例子向我描述了一个可怕的场景,让我了解到软件开发其实也是一个痛苦挣扎的行业。起初我对这个观点很是疑惑,与我之前的认知有悖,但是很快从作者的解释中我明白了一切:个人的开发是快乐的,因为这是一种自由的创作,可以获得帮助他人或是不断学习的快乐。但是真正的大型软件的开发却有着许多我不曾了解的困难,一切事情在追求完美的时候都会变得困难而令人痛苦,在项目接近完成时却逐渐变慢的进程对人也是一个巨大的打击,让人无法从阶段获得快乐,最终无法给我带来快乐。带着这些忧虑我也开始了接下来的阅读。

    第二节也是与书标题相同的人月神话,他向我们阐述了一个简单但是缺被许多人忽视的道理:一味的堆人并不能如预期地加快项目进度,正如Brook所说的那样,向进度落后的项目中增加人手只会导致项目进度进一步地落后,臃肿的团队缺乏合适的结构,只会导致浪费更多的时间在沟通上,从而导致了效率的显著降低。

    接下来的几节描述了各种规模下推荐的团队组织结构,以及一些提高协作效率的方法,但给我印象最深的是外科手术团队的形式进行工作,因为这也是与我们目前学习过程中能接触到的团队规模。程序的开发是一种很主观的过程,多人合作的工作往往很难获得统一,而文中提到的外科手术团队却可以完美解决这种问题。团队由一个核心主持编程,一个副手帮忙把关代码质量,剩余团队负责专门的工作为核心减少别的事情的打扰,可以最大程度上减少因团队交流带来的困难和效率降低。

    后文看到的种种团队结构也正如我的猜想,围绕了团队交流这一方向展开,各种不同结构的团队,各种需求文档的规范和写作,或许会使整个团队显得机械化,但是会极大的提高精确度,减少交流成本,提高工作效率。

    其中给我印象比较深刻的还有文中提到的周会和年会,我此前对这种会议都是只有一个大概的印象,但是不大明白具体有什么意义,而作者的直观表述为我解答了这个疑惑。会议的形式可以降低交流成本,让团队成员始终对于项目有着足够的认识,而持续两周的年会能为整个项目带来足够的总结机会和更多创意,对于一个规模较大的团队来说作用极大。

    正如作者在巴别塔那章所描绘的那样,交流和交流的结果——组织正是成功的关键,而人们这些年来发明并实践出的各种规范标准也都是为了提高交流沟通的效率而制定的。

    而在另外一面这一节中提到,维护各个文件的同步关系是一种吃力不讨好的行为,因此在编程的过程就完成详细规范的注释,或许在编程过程中会有些繁琐,但是带来的自文档化的好处,才是一个比较好的解决方案。

    没有银弹更是阐述了复杂性、一致性、可变性以及不可变性这四个根本特性决定了软件开发中很难出现银弹,人们对于这种“银弹”的盲目追求甚至优点类似于古人对炼金术的追求。但是虽然没有银弹,但是强制的模块化和规范清晰的接口等等都可以有效提高效率。

    而在后续对人月神话的回顾中也提到,即便是过去了那么多年,当年文章中提到的大部分内容确实一点都没有过时,不得不让我佩服作者的高瞻远瞩。

    展开全文
  • 人月神话读后感(一)

    千次阅读 2017-09-13 14:59:24
    “史前史中,没有别的场景比巨兽...”------《人月神话》  在软件开发项目中,似乎也像是这样,每个问题单个看起来都可以得到完美的解决,但是当这些问题纠缠在一起的时候,就会变得像焦油坑一样,让停滞不前。 那

     “史前史中,没有别的场景比巨兽门在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越猛烈,焦油纠缠得就越紧,没有哪种猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。”------《人月神话》

     在软件开发项目中,似乎也像是这样,每个问题单个看起来都可以得到完美的解决,但是当这些问题纠缠在一起的时候,就会变得像焦油坑一样,让人停滞不前。 那么,为什么我们还要热衷于开发软件项目?最重要的是创造事物的成就感,把一个东西从无变有,这会让我们对自己增加自信,这是我们一直喜欢这个领域的内在源泉。第二,我们快乐于开发对其他人有帮助的东西,我们总希望用自己的能力帮助到其他人,而软件开发可以让人们的行为变得方便。第三,我们能够把自己想象的东西以可视化的方式展现出来,这满足了我们内心对创造事物的渴望。但是软件项目也会让人很头疼,机器是死的,它只会按照既定的规则行事,不容任何情面,这就导致我们也要一丝不苟,当你犯了一丝错的时候,你就会得到一个错误的结果,最让人觉得枯燥的是一遍又一遍的检查程序的bug。然而万事万物都有代价。当你能够得到快乐的时候必然是需要付出一些东西。

     在软件开发中,人月是个工作量的单位,在大多数人的眼中,增加人,那么月数就会减少。确实,在某些繁重的体力劳动中,人数越多,意味着完工时间越短。可是,软件开发是个脑力劳动,而且软件开发是连续性的、交互性的,每个阶段、每个部分都是要沟通、要交互的。人数越多,意味着沟通的过程是原来的很多倍,这会导致项目延期,协调是个大问题。这时候就有人说,我只需要一个小型团队,里面的都是精英人才,这样就行了。这样真的可以吗?也许开发小型的项目是可以的,但是对于开发像系统那样的大型项目,即使你1个人能顶7个人,那么也需要至少10年的时间才能够开发出来。一个产品在提出来之后10年才真正上市,这还不算维护,在现在这种信息快速发展的时代,这款产品还有人要吗?是不是过时了呢?

     《人月神话》中提到了外科手术团队,即一个团队拥有一名外科医生(首席程序员),一名副手(能完成一部分工作,但经验少),一个管理员(boss),一个编辑(负责对文档进行分析和重新组织并提供信息),两个文秘(管理员和编辑各一个),程序职员,工具维护人员,测试人员,语言专家(寻求一种简洁的语言来解决复杂的问题)。这就是10人的一个团队。如果要完成更大的项目,那么就需要扩建,扩建成功依赖这样一个事实。决定设计的人员是原来的1/7甚至更少。据书本所说,在实际操作中,这样的分工具有非常高的效率。

    展开全文
  • 这是我自己看完人月神话之后的感想和借鉴网友的评论自己写的,希望帮助大家理解人月神话
  • 人月神话读完了,不长,很精悍。这个是精悍之精悍。符合快餐文化的口味,但不一定符合所有的口味。记得大学的时候有一本书,连我认为最老实的导师都认为其很好,但是一直看不懂,直到研究生快毕业的时候才明白,...
  • 概念上统一的系统能更快地开发和测试,为了实现这个目标,设计必须由一个或者具有共识的小型团队来完成。 一个团队必须保持概念的完整性,才能使团队高效的运作,方向一致。 感受二,交流对项目开发起着至关重要...

    感受一,一个项目概念的完整性非常重要

     概念上统一的系统能更快地开发和测试,为了实现这个目标,设计必须由一个人或者具有共识的小型团队来完成。

    一个团队必须保持概念的完整性,才能使团队高效的运作,方向一致。

    感受二,交流对项目开发起着至关重要的作用

     巴比伦塔项目的失败是因为缺乏交流,以及交流的结果——组织

    在本书中,多次提到了要非常多的进行交流,在他开发的System360中,有很多交流的方式,有每周一次的汇报会议,到每月一次的大会,还有不断修订的项目工作手册

    ,以及实现人员随时可以像结构设计人员询问。这些交流方式,可以说对整个项目的进度和方向正确是起到了很重要的作用,这会消除很多开发人员的顾虑和猜忌,让他

    们更多的把重心放到自己的开发上去,每个人都能随时了解到变更的项目工作手册和变更的重要性,这就很大程度可以帮助所有人调整方向,做出修改。

     

    转载于:https://www.cnblogs.com/xcl666/p/10425409.html

    展开全文
  • 就是Android Studio从一开始的下载不了,下载错误,连项目都不会建,到现在的模仿,做一个超简单的app,弱大烦躁被这小小满足顶替,这也许就是编程中学习的乐趣,这也是编程人员都是乐观主义者的原因吧。...
  • 人月神话》讲了什么一开始我觉得这本书重点是在软件工程,但后来我觉得更准确的说法是,《人月神话》是讲软件工程中人与团队关系的。一个由个人完成的“小”程序,和一个由团队完成的“大”程序,有根本性的不同,...
  • 人月神话读书笔记

    千次阅读 2018-12-22 10:56:54
    第8章 胸有成竹第9章 削足适履第10章 提纲挈领第11章 未雨绸缪第12章 干将莫邪第13章 整体部分第14章 祸起萧墙第15章 另外一面第十六章 没有银弹第十七章 再论“没有银弹”第十九章 20年的《人月神话》 ...
  • 作为软件工程的经典著作,《人月神话》的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解。 其中内容就是: (1)提倡外科手术式的团队组织: 在软件开发组织上的过份民主,往往带来的是没有效率和责任...
  • 人月神话读后感(1)

    2019-01-24 19:08:00
    作为学生假期当然不能荒废,作为软件,自学,阅读更是必不可少的,根据老师的推荐,我开始阅读人月神话这本书,第一章让我感到说的很对,编程让开心也苦恼,“编程行业“满足我们内心深处的创造渴望和愉悦所有...
  • 人月神话读后感01

    2019-09-22 02:56:39
    寒假本来想多读两本书,写写规划极限编程和梦断代码的读后感,然而实在读不下去,只读了一本人月神话,所以就写写人月神话读后感吧。  人月神话在焦油坑一章指出了编程的乐趣与苦恼。编程就像史前动物们身陷焦油...
  • 人月神话读后感1

    2018-02-10 17:46:00
    人月神话读后感1 职业的烦恼 必须追求完美,由他人来设定目标,供给资源,提供信息。个人的权威和他所承担的责任是不相配的。 对于创造者,只有在实现的过程中,才能发现我们构思的不完整性和不一致性。因此,...
  • 人月神话读后感2

    2018-02-13 18:16:00
    那种认为大项目只是增加足够的程序员就能顺利完成,已经对于已经推迟的项目,只要增加手就能按期完成的看法是错误和危险的,因为它假定人和是可互换的,而其实将工作分割给许多、培训和程序员之间...
  • 人月神话》读书笔记

    千次阅读 2018-10-04 16:06:29
    人月神话》是大学刚开始就很熟悉的一本书,当时被奉为软件工程的圣书,似乎都要在书架上摆上它才能表明软件工程学生的身份。时至今日我再它,因为有了之前参与系统的开发的经验,很多的内容都通过记忆得到了验证...
  • 对软件工程犀利的认识:一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,524
精华内容 3,009
关键字:

人月神话读后感1000字