《人月神话》读后感
发布时间：2024-08-29 04:04:03
～-7-6 字数：4071
不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。 这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
1.外科手术队伍the surgical team
项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族～，民主zzaristocracy，democracy，system
要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
有四个问题：
1。如何得到概念的完整性
2。是否要有一位杰出的精英，或者说是结构设计师的贵族～.....
3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。
4。如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
对1。2。4的回答基本上都可以找到，但第3个似乎找不到。
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
唯一不变的是变化本身。
在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。 讲述技术人员与项目人员的互换是，对我有一定的提示，但图中ibm的两条职位晋升线，不太理解。共3页，当前第1页123
10.干将莫邪sharp tools
主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。
11.整体部分the whole and the parts
一读这一章，就让我感触颇深，特别是这句话＂bell实验室监控系统项目的提出，＇关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方＇，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量＂。虽然这句话的意思只是说明精确定义产品将减少bug的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多 开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。
这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除bug的设计以及部分测试/调试方法仍值得一看。
12.祸起萧墙hatching a catastrophe
这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。
项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。这部分描写项目经理以及小组主管的一些心理，值得一看。
13.另外一面the other face
本章说明程序的另一面——文档。
不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。
想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：
&n
不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。 这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
1.外科手术队伍the surgical team
项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族～，民主zzaristocracy，democracy，system
要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
有四个问题：
1。如何得到概念的完整性
2。是否要有一位杰出的精英，或者说是结构设计师的贵族～.....
3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。
4。如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
对1。2。4的回答基本上都可以找到，但第3个似乎找不到。
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
唯一不变的是变化本身。
在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。 讲述技术人员与项目人员的互换是，对我有一定的提示，但图中ibm的两条职位晋升线，不太理解。共3页，当前第1页123
10.干将莫邪sharp tools
主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。
11.整体部分the whole and the parts
一读这一章，就让我感触颇深，特别是这句话＂bell实验室监控系统项目的提出，＇关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方＇，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量＂。虽然这句话的意思只是说明精确定义产品将减少bug的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多 开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。
这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除bug的设计以及部分测试/调试方法仍值得一看。
12.祸起萧墙hatching a catastrophe
这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。
项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。这部分描写项目经理以及小组主管的一些心理，值得一看。
13.另外一面the other face
本章说明程序的另一面——文档。
不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。
想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：
&n
bsp;1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图
2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。XX年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。
14.没有银弹-软件工程中的根本和次要问题(no silver bullet-essence and accident in software engineering)共3页，当前第2页123