《人月神话》学习指南

Posted 2023-04-05 努力推石头的西西弗斯

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了《人月神话》学习指南相关的知识，希望对你有一定的参考价值。

文章目录

《人月神话》学习指南

《人月神话》学习指南

书籍介绍

豆瓣链接

秒懂百科: 一分钟了解人月神话

关于书名

《人月神话》的英文名称是《The Mythical Man-Month》，直译应为不真实的人月。人月（Man-Month）是指一种衡量软件开发工作量的单位，即一个人一个月的工作量。不真实（Mythical）是想表达出人月这种度量的不切实际，即一个人可以十月完成的工作，十个人不一定可以在一个月完成。

内容介绍

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的项目管理经验，该项目堪称软件开发项目管理的典范。该书英文原版一经面世，即引起业内人士的强烈反响，后又译为德、法、日、俄、中、韩等多种文字，全球销售数百万册。确立了其在行业内的经典地位。

在本书第一次出版40年后的今天，我们重新整理了Brooks博士的经典内容，并将国内软件开发领域先行者们对《人月神话》中的实践及系统理论的使用经验和心得集结成册免费赠与大家共享，更使本书成为国内从业者的必读经典之一。

本书读者包括：软件开发人员、软件项目经理、系统分析师等IT从业者。

作者简介

小弗雷德里克•布鲁克斯曾获得美国计算机领域最具声望的图灵奖(A. M. Turing Award)。美国计算机协会(ACM)称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献”。

布鲁克斯博士1956年开始任职于IBM公司，早期担任Stretch 和Harvest计算机的体系建构师。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理。凭借在此项目中的杰出贡献，他与Bob Evans和Erich Bloch在1985年获得了美国国家技术奖(National Medal of Technology)。

布鲁克斯博士创立了北卡罗来纳大学的计算机科学系，并于1965-1985年担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。目前其仍活跃于从事虚拟环境和科学可视化等方面的研究工作，2010年获得虚拟现实事业奖(IEEE Virtual Reality Career Award)。

阅读指南

我阅读的版本是《人月神话(40周年中文纪念版)》。这节是我阅读后的一些想法和认知，希望能帮到他人。

正文之前有三篇序，阅读正文前需要先仔细阅读。

软件研发是一个解决复杂问题的系统性过程，其本身也是一个复杂工程。第一章焦油坑就抛出工程复杂度上升后，难以维护的问题。想要解决这个问题，需要程序员对编程本身抱有极大热情，所以第一章最后两节介绍了编程工作的乐趣和痛苦。

在第一版序言中有提到，第2~7章特别包含了本书的中心论点。作者相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；关键需要的是维持产品自身的概念完整性。这几章探讨了其中的困难和解决的方法。而后续的章节则探讨了软件工程管理的其他方面。

.第二章人月神话，和书名相同的名字足以显示出这章的重要性。本章讨论了缺乏合理的进度安排造成项目滞后产生的诸多派生问题。

.第三章外科手术队伍和第四章贵族专制、民主政治和系统设计的名字都较为抽象，初学者看到后会摸不着头脑，这两章分别介绍了小团队与大团队的建设。

.第五章画蛇添足的英文原名是The Second-System Effect,本章主要提出了一个观点：第二个系统是人们所设计的最危险的系统，通常的倾向是过分的进行设计。

.第六章贯彻执行介绍了架构师如何将自己的设计确保每个人理解。

我们都知道巴比伦塔的失败是因为上帝给了人类不同的语言导致的沟通失效。那么在大型项目中如何保证沟通的顺畅呢？在第七章为什么巴比伦塔会失败中，作者讨论了如何使得团队之间进行有效沟通。

第八章和第九章的内容放在今天已经过时了。作者在第八章胸有成竹中介绍了一种以代码行数进行工作量量化的方案。由于年代久远，这种方式显然不适合现在基于高级语言的研发工作。第九章削足适履谈论了磁盘空间，内存空间受限情况下，如何控制程序规模。

.第十章提纲挈领再次强调了文档的重要性。文档包含了项目目标、产品的技术说明、时间、资金预算、工作空间的分配和组织结构。对于项目经理来说，文档降低了沟通的负担、让分歧更明朗、便于跟踪项目的进度状态。

唯一不变的是变化本身，第十一章未雨绸缪再次强调了这条朴素真理。软件必然会在修修补补中变得面目全非，最初的设计必须在各种妥协中打上各种丑陋的补丁。无论是多么良好设计的系统，都会走向混乱。因此，好的设计会让这个过程尽可能地慢，让代码尽可能地易于维护。而且，在面对不得不进行的重构时，做好心理准备。

编程需要好的工具，这点毋庸置疑。作者在第十二章干将莫邪中介绍了具体的方法和工具，由于案例年代久远，这章不要看了。

.第十三章整体部分讨论了如何去解决系统论中“1+1>2”的难题。

项目的延期通常是日积月累造成的，第十四章祸起萧墙介绍了“项目里程碑”方法。

.第十八章《人月神话》的观点：是与非，这章整理出了作者的核心概念，方便大家进行思考、判断和讨论。

学习资料

TestOps云层

此处警告：不能因为听了视频，就不看原书。推荐看完一个章节之后，带着问题再听。

知乎

《人月神话》就没有一家公司实践过么？

人月神话反过来成立吗？

读《人月神话》——写在华为实习之后

掘金

《人月神话》— 洪荒时代的软件工程

寒假学习12《人月神话》读后感

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

在过去，大型系统开发就如同一个焦油坑，很多大型强壮的动物在其中剧烈地挣扎，他们中大多数开发出了可运行的系统，但是只有非常少数的项目满足了目标、时间进度和预算的要求。各种各样的团队，大型的、小型的、庞杂的、精干的，一个接一个淹没在了这个焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，就变成了巨大的、令人难以寸进的麻烦。

解决这类麻烦，需要诸多的要求和准备。首先，要有合理的时间进度，不合理的时间进度是造成项目滞后的最主要原因。其次，还需要一个外科手术队伍，这种团队满足了迫切性的需求，能使团队达到客观的一致性，并能使成员之间的简单交流成为可能。

根据巴比伦塔的故事，能得出一些重要的关于工程项目的教训。它拥有清晰的目标、充足的人力、丰富的材料、足够的时间、足够的技术，但是，它缺少交流以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。

就工具而言，即使是现在，很多软件项目仍然像一家五金店。每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集，这些工具成为个人技能的直观证明。正是如此，每个编程人员也保留着编辑器、排序、内存信息转储、磁盘实用程序等工具。这种方法对软件项目来说是愚蠢的。首先，项目的关键问题是沟通，个性化的工具妨碍——而不是促进沟通。其次，当机器和语言发生变化时，技术也会随之变化，有工具的生命周期是很短的。毫无疑问，开发和维护公共的通用编程工具的效率更高。

核心观点：概念完整性和结构师概念完整性。

概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。用户所感受到的产品概念完整性是易用性中最重要的因素。不过，很多产业的产品开发过程无法负担这种获取概念完整性的直接方法。竞争带来了压力，很多现代工艺的最终产品是非常复杂的，它们的设计需要很多人月的工作量。软件产品十分复杂，在进度上的竞争也异常激烈。任何规模很大或者非常紧急，并需要很多人力的项目，都会碰到一个特别的困难：必须由很多人来设计，但与此同时，还需要在概念上保持与单个使用人员的一致。如何组织设计队伍来获得上述的概念一致性？这是《人月神话》关注的主要问题。其中一点：由于参与人数的不同，大型编程项目的管理与小型项目在性质上都不同。为了获得一致性，经过深思熟虑的，有时甚至是英勇的管理活动是完全必要的。

结构师。委派一名产品结构师是最重要的行动。结构师负责产品所有方面的概念完整性，这些是用户能实际感受到的。结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益。这个角色是全职工作，只有在最小的团队中，才能和团队经理的角色合并。

以上是关于《人月神话》学习指南的主要内容，如果未能解决你的问题，请参考以下文章

好书推荐学习软件工程的必经之路 | 《人月神话》