读后感一人月

本次阅读《人月神话》可谓收获不少 焦油坑 人月神话  外科手术队伍    贵族专制、民主政治和系统设计  画蛇添足  贯彻执行 胸有成竹  削足适履  提纲挈领  未雨绸缪   祸起萧墙  另外一面

文章开篇以焦油坑（The Tar Pit）引出，焦油坑，让陷入其中的猛兽月石挣扎，越是难以挣脱束缚，最终陷入坑底。而大型的系统开发就是这样的焦油坑，各种问题纠结在一起，让人越陷越深，没有办法看清事情的本质。在其中，不要做一个纯粹的乐观者。

《人月神话》，那什么是人月？是在估计和进度安排中使用的工作量单位。Brooks认为，用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之 间不需要相互的交流。

 

编程的乐趣：

 

1创建事物的纯粹快乐。

 

2快乐来自于开发对其他人有用的东西。

 

3整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行， 得到预先所希望的结果。

 

4学习的乐趣，来自于这项工作的非重复特性。

 

5来自于工作在如此易于驾驭的介质上

保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东西（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。这就是外科手术式的开发队伍。

下面是网上对人月神话的每部分的一个简要概括，也很是到位。

1. 编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。

2. 编程行业的一些内在固有苦恼：

● 将做事方式调整到追求完美，是学习编程的最困难部分。

● 由其他人来设定目标，并且必须依靠自己无法控制的事物。

● 真正的权威来自于每次任务的完成。

● 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外

● 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。

● 产品在即将完成时总面临着陈旧过时的威胁。

 

1. 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

2. 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

3. 我们的构思是有缺陷的，因此总会有bug。

4. 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

5. 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。

6. 关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

7. 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。

8. Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。

9. 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。