人月神话读后感2000字

人月神话读后感2000字（精选10篇）

人月神话读后感2000字 第1篇

读《人与神话》有感

翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。书开始就形象有有趣的把软件危机比作：焦油坑。史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。

看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书 已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有 很多发人深省的观点，也有大量的软件工程实践。大型编程项目深受由于人力划 分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。

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

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

开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

一个软件的好坏不是说是由一个程序员决定的，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。一个小小的bug，也许就需要好几个部门的分工协作。原著中说，软件系统也是人类创造的错综复杂的事物。所以只有在一个团队的沟通了解，通力协作和努力之下，才能做出更加完善的软件作品！

人月神话读后感2000字 第2篇

～-6-23　字数：1345当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）如果不想加班，不想削减功能，不想推迟发布日期，那么。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。

《人月神话》读后感 第3篇

《人月神话》读后感

在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….通过阅读《人月神话》，我从中学到了一些东西：

首先，开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。调试、测试的次序特性，许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

对于编程，有其乐趣和苦恼。创建事物的快乐，开发对其他人有用的东西的乐趣，将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力，面对不重复的任务，不间断学习的乐趣，工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美，是学习编程的最困难部分；由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任实际情况看起来要比这一点好一些；真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。

开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。

同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。

良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规

定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。它可以很容易地表达异常和强调对比的关系，最重要的是，它可以解释原因。在表达的精确和简明性上，目前所提出的形式化定义，具有了令人惊异的效果，增强了我们进行准确表达的信心。

通常，开发一个软件我们还会设立规模目标，控制规模，发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的一样。规模预算必须与分配的功能相关联； 在指明模块大小的同时，确切定义模块的功能。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

调试，是一种检验程序中的方法。然而调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。它可以持续一个很长的时间，从而可能影响项目的交付日期。

为了更好的控制进度，我们需要制定一个严格的进度表来控制项目的进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。进度表有时可以根据进展情况进行适度的修改。

产品测试时每个产品在提交给用户的一道程序。而这项工作主要由产品测试机构/小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。产品－测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。

一个已开发的项目，我们需要对它进行后期维护。其维护基本上不同于硬件的维护，它主要由各种变更组成，如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整而且维护总成本通常是开发成本的40％或更多。维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。其实，对于一个项目，我们要尽量做到完美，减少以后的维护困难和成本。

人月神话读后感 第4篇

二十九年前(1975)﹐IBM大型电脑之父──Fred Brooks 出版一本书﹕“The Mythical Man-Month”。收集了他在1960年代领导1000多人共同发展OS/360大型软件系统的心得和经验。该书是论文集﹐其中有一篇文章叫“The Mythical Man-Month”﹐他就以此作为书名。在1956~1965 之间﹐Brooks实际领导IBM 360 大型电脑的开发计划﹐包括硬体结构及庞大的OS/360作业系统在内﹐因之他具有IBM 大型电脑之父的尊称。由于OS/360是多达1000位程式师共同合作的大型软件开发工作﹐让他深刻了解到大型软件开发的技术和管理上所面临的种种困难和挑战。于是﹐他就将其领导开发OS/360软件系统的经验心得收集在这本书里。人们常拿Man-Month（多少人﹐做多少个月）来计算软件的工作量﹐但是Brooks发现软件的开发工作是需要人与人之间密切沟通的﹐使得设计工作不易分割﹐所以Man-Month 为单位的计算方法是有问题的(mythical)。也就得出著名的Brooks法则── 「对于进度已落后的软件开发计划而言﹐若再增加人力﹐只会让其更加落后。」(Adding manpower to a late software project makes it later)这是该书名称的涵义。

看完此书后，我发现人月神话无处不在，其实在我们做

软件工程来说，此书已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。本书对我触动最大的，一是保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。

二是“一个拿2倍工资的人，生产率可能是其他人的10倍。”不知道其他公司的程序员们如何看。我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队。微软就是这

种思路吧，把最聪明的人集中在一起，想不成功都难。

三是进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？如果不想加班，不想削减功能，不想推迟发布日期，那么。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。

不同的社会经验，不同的思想状态，对读本书的心得也不一样。在此我说说书中许多非常好的观点。

1.外科手术队伍The Surgical Team

项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。

2.贵族专制，民主政治Aristocracy,Democracy,System

要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。

3.画蛇添足The Second-System Effect

讲述的基本都是基于IBM 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的,因此要求他们自律。

4.贯彻执行Passing the word

印象比较深刻的是“体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。”

5.巴比伦塔会失败Why did the Tower of Babel Fail?讲述巴比伦塔会失败的原因是缺乏交流。

6.胸有成竹Calling the Shot

主要讲述如何计算编程时间，以及提出几个人的经验算法。讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。

7.削足适履Ten Pounds in a Five-Pound Sack

主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。

8.提纲擎领The Documentary Hypothesis

说明文档的作用

9.未雨绸缪Plan to Throw One Away

唯一不变的是变化本身。在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。

10.干将莫邪Sharp Tools

主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。

11.整体部分The Whole and the Parts

特别是这句话"BELL实验室监控系统项目的V.A.Vyssotsky提出,“关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方”,细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。

12.祸起萧墙Hatching a Catastrophe

这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。

13.另外一面The other face

本章说明程序的另一面——文档。

不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：

1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图

2.自动文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。

14.没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Essence and Accident in software Engineering)

人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。

15.再论《没有银弹》No Silver Bullet Refired

《人月神话》读后感 第5篇

1不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。

1.外科手术队伍TheSurgicalTeam

项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。

2.贵族～，民主政治Aristocracy，Democracy，System

要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。

有四个问题：

1。如何得到概念的完整性

2。是否要有一位杰出的精英，或者说是结构设计师的贵族～.....3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。

4。如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。

对1。2。4的回答基本上都可以找到，但第3个似乎找不到。

3.画蛇添足TheSecond-SystemEffect

讲述的基本都是基于IBM360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的，因此要求他们自律。

4.贯彻执行passingtheword

印象比较深刻的是＂体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。＂

5.为什么巴比伦塔会失败WhydidtheTowerofBabelFail？

讲述巴比伦塔会失败的原因是缺乏交流。

6.胸有成竹CallingtheShot

主要讲述如何计算编程时间，以及提出几个人的经验算法。

讲述的各种算法可能都不太适合与现在的高级语言，但portman的观点仍然适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。

7.削足适履TenpoundsinaFive-poundSack

主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。

8.提纲擎领TheDocumentaryHypothesis

说明文档的作用

9.未雨绸缪plantoThrowOneAway

唯一不变的是变化本身。

在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。讲述技术人员与项目人员的互换是，对我有一定的提示，但图中IBM的两条职位晋升线，不太理解。

10.干将莫邪SharpTools

主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。

11.整体部分TheWholeandtheparts

一读这一章，就让我感触颇深，特别是这句话＂BELL实验室监控系统项目的V.A.Vyssotsky提出，＇关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方＇，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量＂。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。

这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。

12.祸起萧墙HatchingaCatastrophe

这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。

项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。这部分描写项目经理以及小组主管的一些心理，值得一看。

13.另外一面Theotherface

本章说明程序的另一面——文档。

不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。

想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：

&n

bsp;1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图

2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。2002年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。

14.没有银弹-软件工程中的根本和次要问题(NoSilverBullet-EssenceandAccidentinsoftwareEngineering)

这是一篇论文，发表于1986年，我自认为我的理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。

人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。

作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应

进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。

余下的作者把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是作者的思考方式以及处理方法，这是非常重要的。

「转」人月神话读后感 第6篇

「转」人月神话读后感

堵哥哥要我写人月神话的读后感，先找一篇膜拜一下~~~ ――――――――――――――――――――我是分割线―――――――――――――――――――――――― 《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读。今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。 我今天只看了两章，即焦油坑和人月神话。人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。 虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。 二是作者对软件项目失败的.总结，每一个问题我们依旧再犯，特别读到“是当意识到进度的偏移时，下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。“，我对这句话简直是太有感触了，因为我身边这样的悲剧整天都在上演，公司对所有的项目搞得都是人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员就像割韭菜，旧人一一辞职，新人天天引进，公司何谈发展和积累，做了n年，涛声依旧，做法没有改变，情况没有改观，公司没有发展，好在中国人多地大，呼悠完一个行业，再呼悠另一个行业。 三是作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试，所有的构件已完成 我们公司是通过cmm3认证的，理论不用我说，大家好像都明白，实际情况呢，有谁真的拿出那么多时间作计划，又有谁拿出那么多时间作测试，不过令人欣慰的是，大家确实在向这方面改变，比如我们公司测试部现在就是一个很大很关键的部门，所有的程序发布都需要测试人员的签字。 当然，也许可以找点客观原因，比如现在国内多数客户不成熟，签单子靠关系，一旦签了又恨不得明天就正式运行，但是本着“没有任何借口”的观点，我们该怎样改进呢，我决定读下去，看看能否找到作者所说的银弹呢。

《人月神话》读后感2 第7篇

姓名：张立敬班级：电子商务1班学号：100607020101

初读这部书就深深的震撼了我，不仅仅是作者对程序的观点和思想还有就是这些观点和思想在现实生活中也非常实用。我不得不说这部书是一部很值得多次阅读的好书，每次阅读可能都能从中得到一些提示与感悟。

第一、是什么让那么多爱好编程的人对自己的工作孜孜不倦

爱好，对编程的乐趣，当别人使用你做的系统或软件时那种成就感。这就是如书中所言：职业的乐趣所在:创建事物的快乐，开发对他人有用的东西，将零散的文字组装成一个有用的东西，不断学习的乐趣，创造性的工作。这些也是促使我一直对生活充满希望，并热爱生活的原因。生活就像程序，错综复杂，但在这错综复杂的生活中也有许多乐趣等待我们去采撷，这就需要乐趣。

第二、是什么导致很多项目失败

彼此之间缺乏沟通以及交流的结果。客户的前期需求有很大的不确定

性，可能在开始时大家都以为说的是同一个事儿，但当做出来之后客户发现与自己想像的相差太远。同时，用户在操纵上的习惯题目也会成为一个不能忽视的因素，这也应该算作是需求的一部分吧。用户与开发项目组假如不在需求上认真“较真”，那以后的题目就会不断涌来了。这些需要靠什么往约束呢？靠文档，靠白字黑字的文档。那么对于 生活呢？我认为要想在社会生活的更好，良好的沟通与交流是必不可少的。世上有太多的不确定事情，而个人了力量毕竟有限，这就需要借助朋友的力量。在借助朋友力量时，沟通和交流则是首先必须做到的。怎样沟通，如何沟通，这都是我们应该考虑的。

第三、是什么造成项目滞后

缺乏合理的时间进度。有些时候过于乐观，有些时候过于妥协，经常缺

乏坚持。首先乐观一点固然比较好但要是没有理智的乐观就成了自大，这样往往会影响我们本应该做的事情。因此我们要学会根据具体情况看待事情，从全局出发，掌握一定的基础，再加上我们乐观的心态，这样才能更好的做好一件事情。其次，妥协也是有原则的，该妥协的时候就妥协，毕竟事情不可能完全按照我们的思想进行，适当的妥协也许会让我们彼此都开心。最后就是坚持。无论做什么事情，都要坚持。没有一定的毅力，半途而废是不可能有所成就的。这就是生活真理。

第四、软件系统可能是人类创造中最错综复杂的事物

往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对

其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。

第五、岸上的船儿，如同海上的灯塔，无法移动。

这是焦油坑里的一句名言。也是我难忘的一句名言。过去几十年的大型

系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理解它。这就是生活真理。要想解决一件事，首先要了解事情的始末。提出问题就是解决问题的答案。

《人月神话》，创造了编程世界的神话，也创造了人生历史的神话，更创

人月神话观后感 第8篇

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。读完本书后，感触颇深，书中通过介绍在软件项目开发过程中遇到的一系列问题，以及解决的方法，向IT从业者讲述软件开发过程中需要注意的问题，以下将按照本书的顺序一一总结。

第一章 焦油坑

史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。

第二章 人月神话

软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓。自本书第一版以来，这一法则在软件业广为传诵。

第三章 外科手术队伍

虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。

第四章 贵族专制、民主制和系统设计

概念完整性是系统设计中最重要的因素，尤其对于大型软件系统，概念完整性是项目顺利完成的必要保障，为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开，架构设计和具体实现既相分离，又相辅相成。以建筑工程为类比，概念完整性也是软件项目通往成功的保证。

第五章 画蛇添足

人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。

第六章 贯彻执行

架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。

第七章 巴比伦塔为何失败

如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。

第八章 胸有成竹

对大型软件系统产品的开发所需的时间和资源进行准确的估测，能让我们在项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间，单纯地增加人手并不能有助于开发效率的提高。

第九章 削足适履

最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。

第十章 提纲挈领

在软件项目开发过程中，文档是不可或缺的，文档为整个团队规范了概念，以便团队中的沟通协作，以及进度校验。本章阐述了软件系统项目中至关重要的几类文档。这些关键文档应及时地更新，始终作为

项目进展的有效指南。

第十一章 未雨绸缪

变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。

第十二章 干将莫邪

软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果，切于项目实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。

第十三章 整体部分

大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。及早在软件项目中引入测试，错误发现得越早，修复错误的代价越小。

第十四章 祸起萧墙

项目进度的滞后经常来自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。

第十五章 另外一面

虽然用户直接使用软件系统，但在许多应用领域中，用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。

第十六章 没有银弹――软件工程的根本和次要问题

本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。

第十七章 再论“没有银弹”

相比《人月神话》初版而言，1986年发表的“没有银弹”（第十六章）发表后引发了热烈的争论，本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等等新技术的发展状况，回应了对《没有银弹》一文各种主要异议，认为由于《没有银弹》一文归纳的软件的几大特性，人们期待中的重大突破不可能在近期内到来。

第十八章 人月神话的观点：是或非？

在撰写《人月神话》的回顾和更新过程中，作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪，因此在本章中作者提炼了初版中十五个章节中的概要，结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。

第十九章 二十年后的人月神话

在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开放人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性，结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。

《人月神话》读书笔记 第9篇

这一章分成两个部分：

 程序（Program）、程序产品（Programming Product）、编程系统（Programming System）、编程系统产品（Programming Product System）的概念

 程序员的工作性质

比较有意思的是第一部分的四个概念。

在作者的眼中，程序就是一堆代码，任何人可以宣称自己会编程，但是编程得到的只是程序，而不是产品。程序要成为程序产品，需要有明确的输入、功能和输出，经过完备的测试，具备合格的文档，使之功能可靠，维护易行。

编程系统是从系统的角度来看待功能完整的程序模块，要求程序要具备语法和语义精确的接口，能够与其他的程序进行流畅的交互。相比程序产品来说，不仅仅要严格测试程序自身的输入、处理、输出，还要测试与不同程序之间的交互，因为很多bug其实是隐含在不同功能模块的交互过程中。另外编程系统还要考虑程序之外的软硬件运行环境。呵呵，只有经过了集成测试之后才能称之为编程系统。

最高级的形式是编程系统产品，从书中的表述来看，就是编程系统+各类文档，文档是为了后续维护和升级方便而准备的。智力产品如果没有说明书真是一场噩梦啊，之前我们经历过的不少系统到了后续维护的时候发现文档补齐，维护人员真是伤透脑筋，最后问题太多了索性就提议推倒重做。可以说如果是文档齐备一点，我们公司很多系统的寿命是可以更长的。

人月神话笔记 第10篇

第一章 焦油坑

表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被

解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变

得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很

难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理

解它。--清楚地解释系统开发的困难所在。

这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共

存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。而本书的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。

--本书的目的第二章 人月神话

1.在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致灾难的原因是：

首先，我们对估算技术缺乏有效的研究。

第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆

第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。第四，对进度缺少跟踪和监督。

第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。

2.系统开发过程中，乐观主义并不应该是理所应当的。

在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。

3.成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。

因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

4.在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。

对于任务的进度安排，以下是作者使用了很多年的经验法则：

1/3 计划

1/6 编码

1/4 构件测试和早期系统测试（单元测试）

1/4 系统测试

5.如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。

6.项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加

起来的影响还要大。

第三章 外科手术队伍

1.对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型 系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？--本章要解决的问题

2.Mills的建议：

外科医生（首席程序员）：定义功能和性能技术说明书，设计程序，编制源代码，测试 以及书写技术文档。

副手：主要作用是作为设计的思考者、讨论者和评估人员。

管理员：控制财务、人员、工作地点安排和机器，充当组织中其他管理机构的接口。编辑：根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息 和书目，对多个版本进行维护以及监督文档生成的机制。

两个秘书

程序职员：维护编程产品库中所有团队的技术记录。

工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特 别是交互式计算机服务）的构建、维护和升级责任。

测试人员：各个功能设计系统测试用例的对头，同时也是日常调试设计测试数据的助手。负责计划测试的步骤和为测试搭建测试平台。

语言专家：寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。

3.当进行大系统开发时：

要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体

系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。

第四章 贵族专制、民主政治和系统设计

1.概念一致性

在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列 连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合 的系统，哪怕它们其实包含着许多很好的设计。

2.功能与理解上复杂程度的比值才是系统设计的最终测试标准。但是功能本身 或者易于使用都无法成为一个好的设计评判标准。

3.简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致 的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的 相似性。因此，易用性实际上需要设计的一致性和概念上的完整性。

4.概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。

5.系统的体系结构(architecture)指的是完整和详细的用户接口说明。体系结 构必须同实现仔细地区分开来。

6.作者不认为只有结构师才有好的创意。新的概念经常来自实现者或者用户。然而系统的概念完整性决定了使用的容易程度。不能与系统基本概念进行整合的 良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容 的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上 重新开始。

7.概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来 自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不 意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系

统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划 分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅 提高。

第五章 画蛇添足

1.本章的目标：结构设计师要避免向系统中添加很多不实际的功能（避免

画蛇添足）。

2.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获

得对设计的信心，并且不会混淆各自的责任分工。

3.面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法--挑战估算的结果。后者是固有的主观感性反应。此时，结构师 是在向开发人员的做事方式提出挑战。想要成功，结构师必须

牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而 不能支配；

时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能 达到目标的方法；

对上述的建议保持低调和平静；

准备放弃坚持所作的改进建议。

4.一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 x 不超过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导，在物理实现期间指南和对所有人的警示。

5.项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和 目标在详细设计中得到完整的体现。

第六章 贯彻执行

1.问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师的小组如何保持系统概念上的完整性。

2.手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它

描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。

手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。

后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构

设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实

现过程。

规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都

必须重复所有的基本要素，所以所有文字都要相互一致。

3.规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更

快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描

述阶段上或层次上的结构，以及提供例子。应同时包括形式化和记叙性定义两种方式。

4.通过会议的方式，开发人员进行沟通和讨论问题。

5.不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现，那么定义会更加

整洁和规范。

6.对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜

测一边工作。

一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很

不正式，但非常快捷和易于理解。

7.在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷

都将无从遁形。产品测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测

试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方

面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实现的重要环节。

第七章 为什么巴比伦塔会失败

1.项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。

2.缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。

团队如何进行相互之间的交流沟通：

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

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

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

3.项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。

项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

4.使用项目工作手册的原因：

技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。

正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。

控制信息发布，确保信息能到达所有需要它的人的手中。

5.团队组织的目的是减少不必要的交流和合作的数量。减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。

第八章 胸有成竹

1.问题：系统编程需要花费多长时间？需要多少工作量？如何进行估计？

2.工作量是规模的幂函数。

Portman的数据：工作花费的时间大约是估计的两倍。

Aron、Harr、OS/360的数据：生产率会根据任务本身的复杂度和困难程度表现出显著差异。

Carbato的数据：对常用的编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。使用适当的高级语言，编程的 生产率可以提高5倍。

第九章 削足适履

1.系统的空间规模：规模是软件系统产品用户成本中如此大的一个组成部分，开发 人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模 本身不是坏事，但不必要的规模是不可取的。

2.对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必 须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干 部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内 变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。

仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。

在指明模块有多大的同时，确切定义模块的功能。

培养开发人员从系统整体出发，面对用户的态度。

3.在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功 能交换尺寸。设计人员必须决定用户可选项目的精细程度。

4.考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。

项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在 编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使 用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累，需要开发很多公共单元构件。

5.战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形 式时编程的根本。

第十章 提纲挈领

1.文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查

列表、状态控制，也可以作为汇报的数据基础。

2.软件项目文档的内容：

目标。待完成的目标、迫切需要的资源、约束和优先级。软件开发网

产品技术说明。

进度表。

资金预算。

工作空间分配。

人员组织。

3.为什么要有正式的文档

首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确

定的决策。

第二，文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人

都向着相同的方向前进，所以他的工作主要是沟通，而不是做出决定。文

档能极大地减轻他的负担。

最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚

项目所处的状态，以及哪些需要重点进行更改和调整。

项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可

以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。

第十一章 未雨绸缪

1.对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以 使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的 办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。--构建一个试验性的系统，然后抛弃它。

2.一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可 避免。

3.为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接 口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。

最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准说明，在很大程度上帮助了变化的调整。

变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应 该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。

4.为变更计划组织架构和团队。

5.程序维护中的一个基本问题是--缺陷修复总会以(20%--50%)的机率引入新 的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条 语句的维护需要的系统测试比其他编程要多，成本非常高。

缺陷不能被彻底修复的原因：

首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级 别的问题。其次，维护人员通常不是编写代码的开发人员。

5.使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大 的回报。设计实现的人员越少、接口越少，产生的错误也就越少。

6.维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统 变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是 必要的。