《人月神话》摘录
《人月神话》读书笔记
《⼈⽉神话》读书笔记Photo by Janik Butz from Pexels前⾔：我很庆幸读到了这本书，这本神作。
或许它不能帮我解决我⽬前遇到的任何问题，但是可以帮助我拓宽思维，从前⼈⼤师的视⾓看待软件开发。
⽆需更多的⾔语表达对于这本书的赞美与推崇，这是⼀本软件开发⼈员必须多读的书籍。
摘⾃维基百科介绍：《⼈⽉神话：软件项⽬管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM 系统之⽗所著经典⽂集，全书讲解、相关课题，被誉为软件领域的圣经。
对于⼈⽉的解释：⼈⽉（英语：man-month）指的是“⼀个⼈要花⼏个⽉”才能完成软件开发的单位，⽐如⼀个项⽬ 5个⼈合作开发需要 2个⽉的时间，那么总⼯作量就是 10⼈⽉。
另外，⼈⽉神话这本书的英⽂名是The Mythical Man-Month，有些⼈简称为 MMM注：笔者注记将以这种下划线引⽤添加到正⽂部分，因为本⽂是读书笔记加⼀些反思，⼀些章节只会挑选⼀些重要的、启发性的⽂本加上笔者的概括描述。
原⽂中⽐较重要的段落将以加粗等形式标注。
1. 焦油坑图⽚来源：史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
过去⼏⼗年的⼤型系统开发就犹如这样⼀个焦油坑，很多⼤型和强壮的动物在其中剧烈地挣扎。
各种团队，⼤型的和⼩型的，庞杂的和精⼲的，⼀个接⼀个淹没在了焦油坑中。
表⾯上看起来好像没有任何⼀个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在⼀起的时候，团队的⾏动就会变得越来越慢。
软件开发的另⼀个难题，是从单⼀程序到软件系统过程中，所造成复杂度的快速上升，期间并需要包含不同的活动与技能，使得软件开发必须⾯对多样性的挑战。
《人月神话》三十五年
即将 推 出 平 板 电 脑 。 平 板 电 脑 要 是 真
的流 行 起 来 ，对 建 模 意 味 着 什 么 ？ 也 许 是 手 绘 建 模 。 以前 Ｉｅ ｇａ ｃ 经 ｄ ｏ ｍｉ曾 ｒ
Hale Waihona Puke ２ Ｆ ｅ ｅ ｉ ｒ ｏ ｓ 书 “ ｈ ｅ ｉｎ ｒｄ ｒ ｋＢｏ ｋ 新 ｃ Ｔ ｅＤ ｓ ｇ
Ｗ ｉ ” ， 回 顾 了这 个 １ ５ 年 代 末 期 的 ｎ ９０ 项 目的 历 史地 位 。Ｓｒｔｈ ＩＭ的计 算 ｔ ｃ使 Ｂ ｅ 机 从 真 空 管 转 向 了 晶 体 管 ， 并 为 后 来
Ｓ ｓｅ ３ ０ 列 的 成 功 奠定 了 许 多架 ｙ ｔ ｍ／６ 系 构 和 技术 基 础 ，如 分 支 预 测 、 多线 程 、
完 整性 的 演 讲 。
ｈｔｐ：／ ｔ ／ｗｗ ｗ． ｏｏｐｓｉ ｏｒ ｐ ａ． ｇ／ ｏｄｃ ａｓｔ ／ ｓ
ｅ ｅｒ ｃ ｏ ｓｍ ３ Ｋｅ ｎ ｔ Ｆｒｄ ｉｋＢｒｏｋ ． ｐ ｙ ｏｅ
＿
Ｐ Ｃ等平板电脑没有流行起来 ，从２ ０ ０３
年 以 后 ， 该 工 具 没 有 再 更 新 。希 望 平
２ １ 发 布 ， 新 版 本 增 加 了 更 多 的 报 表 ００ 格式和模板。
Ｓ ｌｃ ｕ ｉｅ ｓ Ｓ ｌｔ ｎ 发布 ｅｅ ｔＢ ｓｎ ｓ ｏｕｉ ｓ ｏ
Ｓｅｌ ｔＢｕｓｎ ｓ ｄｅｅ ｅｃ ｉｅ ｓ Ｍｏ ｌｒ
内存保护、８ 位字节等等 。
在 ３月 底 的 Ｅｃｉ ｓ Ｃｏｎ ２ ｌＰ ｅ ０１ Ｏ 上 ， ｉ ｍｉ 司 的 Ｈ ｉ ｅ ｒｎ 做 了 ｔ ｓ ｅ 公 ｅｋ Ｂ ｈｅ ｓ ｏ “ Ｓ ｎｉｈ ｎ ”的 演讲 ，展 示如 何 ＭＤ Ｄｏ ｏ ｅ Ｐ
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在IBM的项目经验，对软件开发过程中的一些问题进行了深入的思考和总结。
这本书虽然是在20世纪70年代写的，但其中的观点和原则在今天依然有着很大的启示意义。
其中最重要的观点之一是布鲁克斯提出了“带来人越多，项目越慢”的概念，即在一个软件项目中，添加更多的人力并不能加速项目的进展，反而可能会拖慢整个团队的工作。
这是因为在软件开发中，人力并不是可以无限量放大的资源，每一个新成员要花费一定的时间来适应项目的环境和沟通协调，而且不同成员之间的协作也可能会带来额外的沟通成本。
因此，布鲁克斯提倡在开发中尽量保持稳定的团队规模，并且强调进行好的项目规划和任务分配，以确保开发进展的高效和质量。
此外，布鲁克斯还讨论了关于项目中进度和质量的问题，他指出时间、人员、功能三者之间是有着天然的矛盾的，在面对这种矛盾时，项目管理者需要进行适当的取舍和折中。
他还提倡采取模块化的开发方式，将复杂的软件系统划分为较小的、可独立开发的模块，这样不仅能够更好地管理和控制开发过程，还能够提高开发的灵活性和可维护性。
总的来说，读完《人月神话》我深感布鲁克斯在软件开发管理方面的经验和思考是非常宝贵的。
他对项目管理、团队协作和开发流程的一些观点仍然非常适用，可以帮助我们更加有效地管理和组织软件开发项目。
这本书对于任何从事软件开发和项目管理的人士都是一本必读之作，我相信它会给读者带来很多启发和思考。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
《人月神话》读后感----一到三章
《⼈⽉神话》读后感----⼀到三章《⼈⽉神话》这本书是我们⽼师推荐给我们的，同时⽼师还推荐给我们另⼀本书《梦断代码》。
由于时间的原因，我只能先选⼀本书来读。
这本书⾥⾯的好多观点，对于今天的软件⼯程依然适⽤。
如“没有银弹”这个观点，说明了作者对于软件⼯程独到的见解。
⾝为⼀名软件⼯程的学⽣，我应当仔细读完关于软件⼯程的任何⼀本书。
并将观点与想法运⽤到实际之中。
作者在第⼀章中说到，过去⼏⼗年⼤型系统的开发就像焦油坑⼀样，虽然各种各样的团队通过努⼒开发出可运⾏的系统，但是只有少数的项⽬可以开发出满⾜⽬标、时间进度和预算的要求。
作者还谈到编程的乐趣和烦恼。
编程的乐趣主要是能够⾃⼰创造⾃⼰想要的项⽬。
⽽烦恼是总是难以达到完美。
我在读到这本书的第⼆章的时候，就感到作者的见解独到。
Brooks先⽣对⼈⽉转换的观点进⾏了详细的分析，他还指出⾼层次、尖端的⼈才和低⽔平、平庸的⼯作⼈员的⼯作效率⽐会是⼗倍不⽌，所以说⼀个⼩规模的精锐的团队往往要⽐⼤规模的但是有很多平庸的程序员的团队要好得多。
前苹果公司CEO乔布斯先⽣也提出过类似的观点：“在我关注的研发领域，我发现，通常50到100个平均⽔平的⼈才，其贡献才抵得上⼀个最⾼⽔平的⼈才。
”⾼层次的⼈员效率⾼，⼈少带来的交流就少，节省交流时间，进⽽缩短⼯期。
我感觉这道理说的⼗分正确。
⼈⽉神话这⼀章表达的是对⽤⼈⽉这个单位来计量项⽬的价值本⾝是⾮常不正确的。
它看上去好像是⼈⼒和时间是可以交换的，就好⽐远古时期的部落交换东西时的想法⼀样，这种价值观是不正确的。
有时候我觉得盲⽬的增加⼈员数量只会让项⽬落后。
所以我们不要相信⼈⽉神话，⽽是通过合理的分析来制定整个项⽬的进度。
人月神话每一章的读书笔记
人月神话每一章的读书笔记
读第一遍的时候，里面很多的内容我觉得非常晦涩难懂，但还是坚持读了下来。
第一遍读完之后，就开始看书后的读者感言，也在网上找其他人的读后感来看，才真正加深了理解。
如果有跟我一样，在第一次读这本书觉得很难读的，我还是建议您坚持读完，然后去参考其他人的读后感，你也能领会到这本书的精华所在。
“这个领域的知识在于累积”。
这句话是我在读第二遍的时候才从序言里注意到的，我这段时间开始读书，也不断地在寻找着读书的理由，当我再次翻开第一章开头，“前车之履，后车之鉴”瞬间给我空空的脑袋灌了一壶开水：读书的理由，是在于“积累”，“总结”，用前人的知识，来铺设自己的路。
因此我也萌生了写读书笔记的想法，把自己的路真正地铺设起来。
《人月神话》是一本论文集，每一章都可以单独做为一篇论文去阅读和理解，部分章节之间也存在着统一的中心论点，所以在阅读的时候，可以不按顺序选择自己感兴趣的章节进行阅读。
我的笔记是准备读完一章写一篇，希望自己有一个好的开头也能收获一个完美的结尾。
下面就正式开始我对第一章的读书理解吧。
《人月神话》读书笔记1
《⼈⽉神话》读书笔记1
《⼈⽉神话》这个名字，初听不像是⼀本关于软件的著作，但是看下去就会发现，整本书使⽤了⼤量像“⼈⽉神话”这样的⽐喻，形象地解释了⼀些⽣晦难懂的东西。
“史前史中，没有别的场景⽐巨兽在焦油坑中垂死挣扎的场⾯更令⼈震撼。
上帝见证着
恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛
兽⾜够强壮或具有⾜够的技巧，能够挣脱束缚，它们最后都沉到了坑底。
”这是作者对于过去⼏⼗年的⼤型系统开发的看法。
仅极少数项⽬满⾜了⽬标、预算和进度的要求。
问题纠缠在⼀起，其⿇烦程度让⼈惊讶，很难看清问题的本质。
⽽之后的部分，就像是对“焦油坑”做出的说明。
“良好的烹饪需要时间，某些任务⽆法在不损害结果的情况下加快速度。
”⼈⽉指⼯作量单位，即⼈⼒(⼈)和时间(⽉)。
⼈⽉是危险和带有欺骗性的神话，因为它暗⽰⼈员数量和时间是可以相互替换的。
它使得项⽬看上去好像⼈⼒和时间是可交换的。
如果时间不够，那么增加⼈⼿就可以加快进度。
但实际上⼈⽉之间的平衡不是线性关系。
这个衡量⽅式忽略了新增加⼈⼿的培训时间、队员之间的沟通时间等等因素，结果就是，盲⽬的增加⼈⼿只会导致项⽬落后。
“向进度落后的项⽬中增加⼈⼿，只会使进度更加落后。
”对此，作者写出了他的进度安排经验：1/3计划、1/6编码、1/4组件测试是和1/4系统集成测试。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1.The Tar Pit编程为什么有趣？a.首先是一种创建事物的纯粹快乐；b.其次，快乐来自于开发对其他人有用的东西；c.第三是整个过程体现出魔术般的力量——将互相耦合的零部件组装在一起，看到他们精妙的运行，得到预先所希望的结果；d.第四是学习的乐趣，来自于这项工作的非重复性；e.最后，乐趣来自于工作在如此易于驾驭的介质上。
编程固有的苦恼a.首先，必须追求完美；b.其次，是由他人来设定目标，供给资源，提供信息；c.概念设计是有趣的，但寻找琐碎的bug只是一项重复性的活动；d.当投入了大量辛苦劳动，产品在即将完成或终于完成时，却已显得陈旧过时。
2.The Mythical Man-Month沟通所增加的负担由两个部分组成，培训和相互的交流。
每个成员需要进行技术，项目目标以及总体策略上的培训。
这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化。
相互之间交流的情况更糟糕一些。
如果任务的每个部分必须分别和其他部分单独合作，则工作量按照n(n-1)/2递增。
一对一交流的情况下，三个人的工作量是两个人的三倍，四个人则是两个人的六倍。
而对于需要在三四个人之间召开会议，进行协商，一同解决问题，情况会更加恶劣。
所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。
因为软件开发本质上是一项系统工作——错综复杂关系的一种实践——沟通，交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
简单，武断地重复一下Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
（Adding manpower to a late software project makes it later）3.The Surgical Team这些研究表明，效率高和效率低的实施者之间具体差别非常大，经常达到了数量级的水平。
（These studies revealed large individual differences between high and low performers, often by an order of magnitude.）4.Aristocracy, Democracy, and System Design4.1 “概念完整性是系统设计中最重要的考虑因素”。
4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，而不仅仅是丰富的功能。
[该比值是对易用性的一种测量，由简单和复杂应用共同验证。
]4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
4.4 “对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
”[同样适用于小型项目。
]4.5 “如果要得到系统概念上的完整性，那么必须控制这些概念。
这实际上是一种无需任何歉意的贵族专制统治。
”4.6 纪律、规则对行业是有益的。
外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
4.7 概念上统一的系统能更快地开发和测试。
4.8 体系结构（architecture）、设计实现（implementation）、物理实现（realization）的许多工作可以并发进行。
[软件和硬件设计同样可以并行。
]5.The Second-System Effect5.1 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
5.2 结构师如何成功地影响实现：a. 牢记是开发人员承担创造性的实现责任；结构师只能提出建议；b.时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法；c. 对上述的建议保持低调和平静；d．准备对所建议的改进放弃坚持；e．听取开发人员在体系结构上改进的建议。
5.3 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。
6.Passing the Word体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰，完整和准确。
用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。
这往往使手册读起来枯燥乏味，但是精确比生动更加重要。
思路大约是10个人的想法，但如果想保持文字和产品之间的一致性，则必须由一个人或两个人来完成将其结论转换成书面规格说明的工作。
而且，将定义书写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。
对于在整个设计中，保证这些看似琐碎的问题处理原则上的一致性，决不是一件无关紧要的事情。
一种颇具吸引力的作法是对上述定义使用形式化标记方法。
毕竟，精确度是我们需要的东西，这也正是形式化标记方法存在的理由和原因。
一句古老的格言警告说：“决不要携带两个时钟出海，带一个或三个。
”随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。
显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。
7.Why did the Tower of Babel Fail这个项目有多好的先决条件？a.清晰的目标；b.人力？非常充足；c.材料？在美索不达米亚有丰富的泥土和柏油沥青；d.足够的时间？没有任何时间限制的迹象；e.足够的技术？f.交流；g.交流的结果——组织。
项目所有的文档都必须是该结构的一部分。
这包括目的，外部规格说明，接口说明，技术标准，内部说明和管理备忘录。
如果项目有n个工作人员，则有(n*n-n)/2个项目交流的接口，有将近2的n次方个必须合作的潜在团队。
团队组织的目的是减少不必要交流的合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。
减少交流的方法是人力划分(division of labor)和限定职责范围(specialization of function)。
当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需求会相应减少。
7.4 产品负责人的角色是什么？他组建团队，划分工作及制订进度表。
他要求，并一直要求必要的资源。
这意味着他主要的工作是与团队外部，向上和水平地沟通。
他建立团队内部的沟通和报告方式。
最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
7.5 技术主管的角色是什么？他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。
他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。
当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。
用Al Capp 所喜欢的一句谚语，他是“攻坚小组中的独行侠”（inside-man at the skunk works.）。
他的沟通交流在团队中是首要的。
他的工作几乎完全是技术性的。
7.6 技术主管作为总指挥，产品负责人充当其左右手。
这种安排对小型团队是最好的选择。
对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更适合的安排。
8. Calling the Shot8.1 实践是最好的老师。
(Practice is the best of all instructors.)8.2 实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。
(Experience isa dear teacher, but fools will learn at no other.)8.3 工作量 = （常数）×（指令的数量）5.18.4 就控制程序组的经验而言，生产率的范围大概是600到800/人年。
语言翻译小组所达到的生产率是2000到3000/人年。
8.5 编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍。
8.6 对常用编程语句而言。
生产率似乎是固定的。
这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。
8.7 使用适当的高级语言，编程的生产率可以提高5倍。
9. Ten Pounds in a Five-Pound Sack9.1 当系统设计者认为对用户而言，常驻程序内存的形式比加法器，磁盘等更加有用时，他会将硬件实现中的一部分移到内存上。
相反的，其他的做法是非常不负责任的。
9.2 在指明模块有多大的同时，确切定义模块的功能。
9.3 在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。
在这种监督机制之外，是实现人员自身的态度问题。
培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员最重要的职能。
9.4 这很像小汽车，如果把照明灯，点烟器和时钟作为整个配件来标明价格，则成本会比单独提供这些选择所需要的成本低。
所以，设计人员必须决定用户可选项目的粗细程度。
9.5 很难用小型系统的模块构造出非常高效的系统。
9.6 考虑空间——时间的折中。
对于给定的功能，空间越多，速度越快。
这一点在很大的范围内都适用。
也正是这一点使空间预算成为可能。
9.10 认识到编程需要技术积累，需要开发很多公共单元构件。
上述的公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。
9.11 数据的表现形式是编程的根本。
10. The Documentary Hypothesis10.1 在一片文件的汪洋中，少数文档形成了关键的枢纽，每件项目管理的工作都围绕着它们运转。
它们是经理们的主要个人工具。
10.2 项目经理的任务是制订计划，并根据计划实现。
但是只有书面计划是精确和可以沟通的。
计划中包括了时间，地点，人物，做什么，资金。
11. Plan to Throw One Way11.1 There is nothing in this world constant but inconstancy.11.2 It is common sense to take a method and try it. If it fails, admit it franklyand try another. But above all, try something.11.3 新的系统概念或新技术会不断出现，所以开发的系统必须被抛弃，但即使是最优秀的项目经理，也不能无所不知地在最开始解决这些问题。
11.4 开发人员交付的是用户满意程度，而不仅仅是实际的产品。
用户的实际需要和用户感觉会随着程序的构建，测试和使用而变化。
11.5 软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。
11.6 现在软件编程小组失败的主要原因是管理控制得太少，而不是太多。
11.7 通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为他的每个结果进行辩护。
如果团队架构因此受到任何形式的威胁，则没有任何东西会被文档化，除非架构是完全受到保护的。