第二篇
这是《人月神话》的第二章,多巧，本章的名字也叫人月神话在本章的开头，作者提出了一个问题，即“在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致这种普遍性灾难的原因是什么呢？”在这里作者认为，在项目开发中会出现一个很重大的问题，此问题甚至会导致整个项目的停滞甚至崩溃。
这里，小白我简单的概括了一下Brooks的观点，一共是五点：即 1.对估算技术缺乏有效的研究，这里我的理解是对软件工作的程度的错误分析2.错误地将进度与工作量相互混淆。3.对自己的估算缺乏信心，信心这种东西，对于编程人员来说，十分重要的4.对进度缺少跟踪和监督。5.当意识到进度的偏移时，下意识的反应是增加人力。这点是人之常情，我们第一反应使用更大的人力物力来更正进度，而不是去优化他。
以此，作者提出了本章的几个重要知识点，呃，应该说是论点
1.乐观主义
作者说“所有的编程人员都是乐观主义者。”呃，作者是不是有些太绝对了，我就总是感觉到很悲观，我感觉这不是一个好兆头啊。不过作者的说法倒是很有趣，也很可信。“成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人”“可能是这种现代魔术特别吸引那些相信美满结局的人”以及最后作者说的，计算机还很年轻，程序员们更加年轻，乐观是年轻的一种表现不是吗？确实，我觉得，我的软件工程成绩一直都不好，我觉得我不适合编程，可能就是因为我的心态不够吧，对于一个不乐观的人而言，枯燥且没有希望的繁杂工程太容易让人挫败了。所以很多时候，我的编程效率很低，因为我看不到希望，其实我和他们的水平也差不了太多吧，只是我太悲观了吧。我有时会觉得我的心态不像是一个年轻人，太平静了没有属于年轻人的那份闯劲，反而像是一个行将就木的老人，这是不对的吧。我想我应该改变了。
不过本章作者对乐观主义不报褒义态度，作者认为这种弥漫在编程人员中的乐观主义，理应受到慎重的分析。认为这种乐观主义应该更谨慎，因为它会使我们的看法偏颇。不过我认为，乐观却也不能失去，适度的乐观态度，是最好的。
2.人月
这一部分大佬说的蛮抽象的，还借用了图。我看的有点迷糊，不过还是理解了一点，就是软件开发的过程和我们预估的过程是不一样的，就是之前提到的第二点，进度和工作量并不一样。软件开发本质上是一项系统工作，是错综复杂关系下的一种实践。他需要各个板块之间的沟通，需要板块的叠加而不是简单地进度叠加。也与我们刚刚提到的第五点相呼应。所以有时添加更多的人手，实际上是延长了，而不是缩短了时间进度
（我说的是不是有点不清晰，我也不太明白该怎么表达我的想法）
3.系统测试
这一章主要是对作者测试方法及心得的一些传授，概括出来就是一点：我们常常认为时间充足是没有吧测试系统的时间算上，这也是乐观主义的一种表现，即实际时间源源大于估计，因为调试确实很花费时间。
说实话，本章有很多很抽象的比喻，比如人月，比如把程序员比作厨师等等。不过认真看进去的话，真的非常有收获