读人月神话有感

在焦油坑中，一开始借巨兽的例子说明了一个问题那就是在各种团队中遇到的每个问题在我们看起来任何一个单独的问题都是可以解决的，但是当他们互相纠缠、累积在一起的时候，团队的行动就会变得缓慢受到了阻滞。除此之外，程序类比为产品，将程序如何更好的转化为成本更高的产物需要对其进行加工、修复以及扩展等一系列操作。在此篇章中谈到了编程的快乐以及苦恼，在编程中通过沉浸其中我们能不断发现快乐并且享受这种快乐，但是由于繁复的代码工作以及琐碎的bug使得这项工作并不像想象中的那么美好，由此不免产生出一些苦恼，这都是不可避免的，我们能做的就是如何更好的享受快乐，并让快乐大于苦恼。

在人月神话篇章中人数和时间之间的互换的情况是很少的，仅仅适用于人员之间不需要互相交流。在此篇章中，阐述了Brooks准则，有一句话令我印象深刻，向进度落后的项目中增加人手，只会是进度越来越慢，所以增加人数不一定是好的，也可能会对工作造成反作用。

外科手术队伍章节中说到人数多而平庸与人数少而精干这两种团队适合什么样的工作，对于效率和概念的完整性来说，最好由少数干练的人员来设计开发，而对于大型系统，则需要大量的人手，以此使得产品满足在时间上的需要。

贵族专制、民主政治和系统设计篇章中说明了产品的成本性能比在很大程度上依靠实现人员，就如同易用性在很大程度上依赖结构师一样。概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。同工作广泛的水平分割相比，垂直划分从根本上大大减少了劳动量，使交流彻底地被简化，概念完整性得到了大幅提高。

为什么巴比伦塔会失败从此章中了解到目标、人力、材料、时间、技术对一个工程或者项目的影响，除此之外，交流和组织也是至关重要的。正如书中所说巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。

对于这本书，这几章给我的感受最深，同时这也让我对人月这个话题去除了神话的意向，人数与时间的关系要以具体工作来定，人数不是越多越好，但也不是越少越好，人与月是不能相互换算的。