具体描述
本书内容源于作者Brooks在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验。在本书中，Brooks为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管理者给出了自己的真知灼见。
大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。本书探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。本书适合任何软件开发行业的从业人员阅读，对软件开发人员、软件项目经理、系统分析师更是必读之作。
作者简介
Frederick P. Brooks, Jr. 1931年4月19日出生于美国北卡罗来纳州Durham，1953年毕业于杜克大学，1956年获得哈佛大学应用数学博士学位，同年加入IBM公司。他领导了IBM System/360及其操作系统OS/360的开发，被誉为“IBM 360系统之父”，“计算机体系结构”一词即由他首先提出。1964年他离开IBM，创建了北卡罗来纳大学计算机科学系，担任系主任长达20年。1975年，他出版了著名的《人月神话》，探讨软件工程的管理问题。1986年，他发表了经典论文《没有银弹》（本书已收录）。1994年被选为ACM院士。
目录信息
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
Chapter 6 Passing the Word 61
Chapter 7 Why Did the Tower of Babel Fail? 73
Chapter 8 Calling the Shot 87
Chapter 9 Ten Pounds in a Five-Pound Sack 97
Chapter 10 The Documentary Hypothesis 107
Chapter 11 Plan to Throw One Away 115
Chapter 12 Sharp Tools 127
Chapter 13 The Whole and the Parts 141
Chapter 14 Hatching a Catastrophe 153
Chapter 15 The Other Face 163
Chapter 16 No Silver Bullet—Essence and Accident 177
Chapter 17 "No Silver Bullet" Retired 205
Chapter 18 Propositions of The Mythical Man-Month: True or False? 227
Chapter 19 The Mythical Man-Month after 20 Years 251
Epilogue 291
.Notes and References 293
Index 309
· · · · · · (收起)
读后感
2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图灵奖得主为时年69岁的布鲁克斯（Frederick P. Brooks, Jr.）。评选委员会主席在致辞中提到，“今天我们所看到的计算机体系结构、软件工程，以及三维计算机图形，均受惠于布鲁克斯的开创性工作，是他改变了这些领域的面...
评分 评分本评论转自我的Blog 转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址： http://program-think.blogspot.com/2009/03/book-review-mythical-man-month.html 对于软件工程而言，我个人认为到目前为止，尚未有哪本书的影响力和深刻程度能够超越《...
评分···军训中的 “时间-人”问题··· 对于军训来说时间是需要很好控制好的一个因素。 一天的军训排得很满，对于个人，怎样安排好自己的行程来最有效率就显得十分重要。 比如，什么时候洗澡，什么时候吃饭...什么时候该干什么，起码比较理智的分析各个安排的利弊，然后判断...
评分1.如果你刚开始学习编程，建议你别看这本书，因为太多过去的历史，你根本没有兴趣。有这个时间不如看看如何写出漂亮的程序。 2.如果你只喜欢编程，建议你也别看这本书，因为书中介绍得更多是项目的内容，其实你根本用不到。
用户评价
这本书对于项目估算和规划的章节，简直是程序员的“祛魅剂”。在我职业生涯的早期，我们总是倾向于过度乐观地估计工期，认为只要加班就能弥补初期的失误。然而，阅读此书后，我才明白，**估算本质上是一种不确定性的量化过程，而非精确的预测**。作者用翔实的论据展示了，软件项目估算失败的根本原因，往往不是技术难题本身，而是对“人”的因素——例如学习曲线、中断、返工——估计不足。尤其是关于“布鲁克斯法则”的阐述，它像一把冰冷的尺子，衡量着管理层对项目复杂度的盲目自信。我特别欣赏作者在提出问题之后，并没有提供一个一蹴而就的解决方案，而是提供了一套系统的、权衡利弊的思考框架。这使得书中的智慧能够适应不同组织、不同规模的项目。对我个人而言，它教会了我如何在面对不切实际的截止日期时，有理有据地进行技术和管理的沟通，而不是简单地抱怨。
评分这本关于软件工程的经典著作，虽然我手里拿的可能不是英文原版，但其核心思想的普适性是毋庸置疑的。初次捧读，我立刻被作者那种近乎冷静甚至带着一丝苦涩的现实主义态度所吸引。它不像许多新潮的技术书籍那样，一味地鼓吹某种“银弹”式的解决方案，而是深刻地剖析了项目管理中那些令人头疼的“人”和“时间”的矛盾。我印象最深的是关于项目规模与复杂性之间非线性增长的论述，这完全颠覆了我过去那种“人多力量大，时间拉长就能搞定”的简单线性思维。书中那些关于沟通开销、心智模型一致性、以及如何衡量项目进度的讨论，即便放在今天这个敏捷和DevOps盛行的年代，依然具有强大的指导意义。特别是关于“增加人手反而会拖慢进度”的论断，简直是无数失败项目血泪史的精炼总结。阅读过程中，我时常会停下来，对照自己过去或正在参与的项目，那种“原来如此”的顿悟感，是阅读许多技术文档都无法给予的。它更像是一部社会学著作，描绘了工程师群体在面对复杂系统构建时，在认知局限与现实约束下挣扎的群像。
评分我对这本书的结构安排非常赞赏，它不是简单地堆砌经验教训，而是构建了一个从概念到实践，再到管理哲学层层递进的知识体系。开篇对概念的厘清，比如什么是“系统”，“抽象”的意义，为后续关于大型系统设计的讨论奠定了坚实的理论基础。然后，作者巧妙地将焦点从纯粹的技术转移到组织和人员的管理上，这正是很多技术人员容易忽略的关键点。我发现，很多现代软件工程的实践，比如结对编程、持续集成，其深层动机都可以追溯到本书对“心智模型一致性”的强调。这本书的伟大之处在于其**穿透性**，它能够穿透技术表象，直达管理和协作的本质。它让我意识到，软件开发不仅仅是编译代码，更是一项复杂的社会工程。读完它，我感觉自己不再是一个孤立的编码者，而是一个身处复杂系统中的沟通者和协调者。这种视角的拓宽，是任何一本专注于工具或框架的书籍都无法比拟的。
评分总的来说，这是一本值得反复阅读，并且每次阅读都会有新收获的著作。它的内容经得起时间的考验，因为它讨论的不是暂时的技术潮流，而是**人与复杂性共存的永恒难题**。我尤其喜欢作者在行文中流露出的那种对卓越工程的追求和对平庸实践的深刻批判。虽然书中的案例可能带有一定的时代背景，但它们所揭示的工程学原理，如模块化设计、接口的清晰定义、以及避免过度设计的重要性，是永恒的真理。阅读此书，就像获得了一副能够看穿项目迷雾的“X光眼镜”。它让我明白了，一个优秀的软件项目，其成功更多依赖于清晰的沟通和严谨的抽象能力，而非仅仅是依靠最新的编译器或最快的处理器。对于任何一个有志于构建大型、健壮系统的工程师或项目经理来说，这本书不应该只是书架上的装饰品，而应该是一本常备的、随时可以翻阅的“工程宪法”。
评分从阅读体验上来说，这本书的语言风格是一种成熟的、经过时间检验的散文体，它不像某些技术手册那样晦涩难懂，但其信息的密度却极其高。我发现自己需要反复咀嚼那些关键的比喻和类比，才能真正领会其背后的深层含义。举个例子，作者引入的“外科手术团队”与“面包房生产线”的比喻，清晰地勾勒出了软件开发中不同层次的协作模式和瓶颈所在。那种行云流水的叙事中，蕴含着对无数失败案例的深刻反思和提炼。这本书的价值不在于教你具体使用哪种编程语言或框架，而是在于塑造一种**正确的、批判性的工程思维模式**。它迫使读者去思考那些隐藏在代码之下的组织结构、沟通机制以及时间估算的本质困境。读完之后，我明显感觉到自己看项目报告时的视角变了，我不再只关注技术栈的更新，而是更加关注文档的清晰度、设计决策的透明度，以及团队成员之间知识共享的效率。这是一种从“做”到“思考如何做得更好”的质的飞跃。
评分我觉得可以从16章开始看...
评分软件确实是工程
评分2008
评分经典
评分本质问题, 与非本质问题, 只有大师级人物才能如此简单而又深刻的阐述软件开发的问题. 好书应该读很多遍.
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有