粗读《人月神话》，感觉这本书篇幅不大，但内容丰富，虽然对我来说好多东西都看不懂，但有些东西还是留下了印象。本来我以为这本书真的是神话故事书呢，看了之后才知道这是一本关于软件工程管理以及规划方面的书籍，正适合我的专业。读了一遍，可能是才疏学浅，有好多地方都看不透彻，体会也并不是特别多，只看到了项目管理和团队合作并不是像最初想象的那样简单。人月也不是人和月亮，而是一个单位，这是我以前从未听说过的。。。反正看了之后，觉得自己连菜鸟都算不上，简直有种门外汉的感觉啊，很愁苦啊。
这本书的评价很高，作者也很厉害，这个专业或有些方面兴趣的大神们可以读一下，收获肯定不小。下面我就阐述下我的一些小收获，不喜勿喷哈。
一、对于编程，喜欢的理由
首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花上的喜悦.其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为“爸爸办公室”捏制铅笔盒没有本质的区别。
第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的计算机毫不逊色。
第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。
最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。
二、关于开发语言很真实
当意识到进度的偏移时，下意识的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。
向进度落后的项目中增加人手，只会使进度更加落后。
绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、不充分的。
概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节中所讨论的、一种崭新的组建编程开发团队的方法。
不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。
三、关于分工
产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中，可能是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。 第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。
普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。
大多数有丰富经验的程序员拥有自己的私人开发库，可以使他们使用大约30％的重用代码来开发软件。
以上只是给我留有印象的部分，这只是这本书的一小部分。这本书讲的主要是工程管理方面的问题，有人说只喜欢编程的人不适合看这本书。这我是不同意的，就算再厉害的人，一个人也不可能单挑起一个项目，这是毋庸置疑的。团队合作无论在什么行业都是必须的，我觉得任何专业的人都能从这本书中或多或少的得到一些收获。可能是我接触专业方面的知识还很少，所以还看不懂一些深刻的东西，但这本书就
像古人说的，开卷有益，温故知新，相信这本书无论什么时候读都会再有新的心境，新的收获。