《人月神话》读后感

Posted 2020-07-25

　　《人月神话》是软件工程领域的一本经典著作，其内容源于作者布鲁克斯在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验。以高屋建瓴的态势，介绍了自己的作为项目经理的经验，为后来的编程人员提供极好的指导建议。

　　在此书开篇先是介绍了作为一个程序员的职业乐趣所在，包括了创造事物的纯粹快乐，开发了对他人有用的东西时的满足感，在创造过程中的强大魅力，持续学习的快乐以及在易于驾驭的介质上工作的快乐，这大大激发了我对这一职业的向往。

　　软件工程初始诞生时的意义在于解决软件危机，并且也能减少程序员编程时的痛苦，比如说为了追求完美，这是工程上与理论上的差距，软件的可用性与可靠性的量度；痛苦也来自自己的工作是由他人（项目经理）设定的，还有就是当投入大量辛苦的劳动，产品在即将完成却已显得过时。

　　在编写系统时，进行不合理的进度安排会造成项目滞后，这是因为在安排时我们进行了一个错误的假设，那就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。还有一个错误的假设是使用的工作量单位：人月，有问题。只有在某个任务可以分解给参与人员，并且他们之间不需要相互交流的情况下，人月这一单位才是正确的。这为我们以后编写可进行研究文档时有重要的指导意义。

　　在软件工程中，为系统测试安排足够的时间是十分有必要的，因为缺陷的数量比我们的预想要高得多。

　　本书提出了一个很有意思的团队组成方案，也就是——外科手术队伍。首席程序员类似外科医生，他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。

　　副手能完成任何一部分工作，但是经验相对较少，他的主要作用是作为设计的思考者、讨论者和评估人员。

　　管理者即是老板，在人员、薪酬、办公室间等方面具有决定权。

　　编辑负责创建各种文档，包括对内描述或者外部描述。

　　为管理员和编辑个配置一个文秘，负责非产品文件和使项目协作一致。

　　程序职员，负责维护编程产品库中所有团队的技术记录。

　　在计算机的设计中，一旦设计实现人员有了对手册的模糊设想，对技术有了相对清晰的构思以及拥有了适当地成本和目标时，工作就可以开始了。就可以开始设计数据流、控制序列、进行总体概念包装等。

　　我还学到对于项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和用户需求，以设置待开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。仅对核心程序设定规模目标是不够的，必须把所有方面的规模都编入预算。

　　在这个学期的编写文档过程中，初期会觉得枯燥，感觉没什么意义，但是当我看完这本书后我意识到了自己的错误。不论项目的规模有多小，项目经理都应该首先立刻正式生成若干正式的小文档，以作为自己打的数据基础，然后再要求提供和其他经理类似的文档。文档十分的重要，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。文档能够作为同其他人的沟通渠道。项目经理会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知。项目经理的文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重要进行更改和调整。

　　我认识到构件单元调试时应遵循四步，本机调试，内存转储，快照，交互式协调。还需要测试用例。系统集成调试是出乎意料的困难的，我们应该使用经过调试的构件单元以及搭建充分的测试平台。

　　这本书介绍了许多新颖的软件工程技术，现在还未能完全理解，在以后的工作学习中，可以在有空时再回头看看这本书，起到温故而知新的作用。