一开始听到《人月神话》这个书名的时候，受到“神话”二字的影响，我以为这里的“人月”是超乎正常认识的名词，没有想到，这里的“人”还是那个人，这里的“月”也还是那个月，而这本书，则是剥去神话外衣后对软件工程更深刻的解读和诠释。
读完《人月神话》后，有几个比较深的感受：
一、关于焦油坑、编程的乐趣以及乐观主义
之所以首先想谈这一点，是因为这本书在开头就用这几条戳中了我的心头。我喜欢编程，因为一台电脑就可以让我的思维无限的延伸下去，亦如作者所说，“是一种创建事物纯粹的快乐，……，整个过程体现出魔术般的力量”，同时，我也是乐观主义，每次调试程序，我总会认为程序会按照我设计的思路正常的运行下去，但是现实往往总是给我一巴掌。被作者一语点中的我，感到这本书实实在在的描述了很多我已知和未知的内容。但在本书的开头作者用史前巨兽在焦油坑中挣扎的场面来比喻过去几十年的大型系统开发，让刚接触这本书的我立即建立了一种印象——开发大型系统的困难和繁杂程度是难以想象的，他仿佛在告诉我，|“伙计，这没你想的那么简单”。
二、关于团队结构
我对团队的概念是从竞赛开始的，我参加了很多届的数学建模，数学建模三个人组队，一个编程，一个论文，一个建立模型和思考下一步的方向。这在建模的团队结构里是最合理的，但是当我真正参与其中的时候我就发现，没想象中那么简单。即便我们有了模型、有了下一步的方向，但是写论文的人和编程的人也很难将思路理解通透，换言之也就是这三方之间的交流还不够；同时，我们之间缺少统一的标准，这也导致论文和编程之间很多关系的不统一，所以在我读到关于巴比伦塔为什么会失败的时候我有很真切的感受。在团队里，交流和项目工作手册是十分重要的。而《人月神话》中，作者给出了一个合适的团队结构，名为“外科手术队伍”，他们有各自的分工，作者详细的描述了各个角色的职能，这让我想到我参加的一个相对成功的竞赛，是一个电子类的竞赛，团队总共有5个成员，我们有各自的分工，有负责各类竞赛流程关注、事物安排和答辩的人员，有负责编程和调试的软件人员、有负责硬件连接的人员、有负责带领作品设计的人员，他们的职务分工类似于作者Brooks所述的外科医生、副手、管理员、语言专家，在这样的团队中参加竞赛，结果是我们拿了这个竞赛的一等奖，同时在竞赛过后，大家普遍感觉到整个过程十分的轻松愉快，每个部分都有人按部就班的完成，但是要达到这样的结果，缺少我们中的任何一个部分都不行。
三、关于系统完整性
作者强调的贵族专制让我更加充分的认识到结构完整的重要性，在进行这一部分表述的时候，作者拿大教堂做比喻，“风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每个人牺牲了自己的一些创意，以获得纯粹的设计”，当更优的创意、想法和现行的系统基本概念发生冲突的时候，就应该抛弃这种创意，如果创意过于重要，则需要抛弃原来的设计，重新整合系统的基本概念。这让我认识到自己曾经很多想法之所以无法落地，或者无法被上级采纳，很大的原因可能是它不适用于现行的制度体制，这也可能是国内当前很多方面都在进行改革的原因，同时也包括了我国经济的结构性调整，其中或多或少都涵盖了这方面的理论。
四、关于干将莫邪
我认为工具只是工具，它只是为了帮助人完成任务和达到目的而已，但是看到作者的论述，我认识到工具在团队中通用化的重要性，“项目的关键问题是沟通，个性的工具妨碍——而不是促进沟通”。
五、前进与后退
Brooks教授强调了两种模式，一是前进两步后退一步，二是前进一步后退一步，这种动态变化的过程让我对软件维护有了全新的理解，所谓软件的bug，并不完全是软件完成就存在的那一部分，软件维护人员修复了原有的bug，就会引入新的bug，这是一种永无止尽的修补过程，bug还伴随着用户数量的增长而增长，因此前进中伴随着后退，然而这种过程并不是动态平衡下去的，在系统软件开发的过程中，熵在不断的减少，但是伴随这软件维护过程，熵是不断增加的，伴随着这种熵增加到了一定的程度，整个系统会逐渐面目全非，因此需要设计新的系统或者软件。这在我理解来看，可能就是很多系统和软件在经历过很长一段时间之后就会发生一次大更迭的原因。
六、关于里程碑
生活中我常常遭遇或者自己就成了“差不多先生”，“完成了90%？99%？，都差不多啦”，我会用这样的话来安慰自己，但是里程碑的意义，是100%，这让人无可辩解，必须仔仔细细的完成好任务，“里程碑的选择只有一个原则，那就是，里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义”，在完成任务的时候，只有设置这样的里程碑，才能让计划更切实的落地。
