《人月神话》读后感

《人月神话》是一本IT行业的经典著作，书名《人月神话》中的“人”指的是人力，“月”指的是工作的时间，主要的意思是人月作为一种衡量软件开发工作量的单位有其误导性。本书的主要内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的各种项目管理经验，诞生于1975年的此书算得上是计算机领域的洪荒时期的作品，而时至今日，在互联网时代与传统IT行业区别十分之大的软件技术领域，它依然是最为值得一读的经典作品，仍旧被无数相关从业者奉为圭臬。

我们接下来就来看看这本书中所表达的主要思想，结合这些内容，我在谈谈我自己的理解。

一、两条法则

众所周知，《人月神话》提出过两条十分著名的法则：

1、人月神话：向一个已经延后的项目中投入更多的人力资源，只会让它更延后。

作者阐述的主要观点是在软件开发项目上项目进度和增加人员数量这两个概念不能互换。让我惊讶的是，我们现在的项目开发依然如此，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。当读到“是当意识到进度的偏移时，下意识的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟，越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环”，这让我明白了一个重要的道理：项目的进度是不能够光靠人力的增加来推进的，简单的增加人员只会让项目的开发进程变得更慢，项目的开发变得更加的糟糕，多个人员参与项目就意味着，在项目的开发中增加了额外的工作量，这些工作量基本包括但不限于是

任务重新分配本身和所造成的工作中断；
培训新人员；
额外的相互沟通

人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。

在过去几十年的项目开发的系统开发的过程中，各种团队都会被巨大的焦油坑淹没，表面上来说，看似好像没有什么巨大的BUG是会直接阻停项目的开发工作的，但是在项目开发过程中，往往会积攒一些因为多方面原因而导致的的小错误，当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质，在这个时候，盲目的增加人手来解决问题往往会导致更加严重的问题，当任务由于次序上的限制不能分解时，人员的添加对系统开发的进度没有任何的帮助；调试、测试的次序特性，许多软件都具有这种特征，因为软件开发本质上是错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快就会消耗任务分解所节省下来的个人时间，添加更多的人手，实际上并不是缩短了时间进度。

2、没有银弹：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。

对于软件工程的开发工作来说，软件的并不仅仅只是程序、程序相关的工程性的文档设计，并实现把它们出来，最核心的是软件在研发的概念上的结构，而不只是有血有肉的填充进行逼真性的验证概念的正确与否以及其价值。

作者做出这一论断的前提是：所有软件包括根本任务和次要任务，根本任务是打造构成抽象软件实体的复杂概念结构，次要任务是用编程语言表达这些抽象实体。

很多技术或管理上的进展在解决次要任务上发挥了巨大作用，但是在主要任务上却进展寥寥，作者进而分析了造成这种境况的原因，分别从复杂度、一致性、可变性、不可见性论述了他的观点。就我个人的理解而言，软件本质上需要完成客户需求，而需求则来源于商业决策、社会、文化等的各个方面，这个需求的来源过于繁杂，以至于任何一种架构设计都不可能囊括所有的可能性。所以这些业务的需求必然会变更，没有一发银弹可以应对所有的需求。软件开发的难度不在于开发，而在于设计一个完美的软件架构，而这个架构依赖于对业务的熟悉和前瞻性的展望。

没有银弹，也可以理解为是技术帮不了维度上面的东西，技术随着生产使用的研究，会逐渐的变得先进，但同时，需求也在变得苛刻，可以这么认为，技术在满足当前需求的情况下，也在促使未来甚至是当前需求的规模和复杂性的指数提升，技术的本身并不能带来解决技术本身的问题。所以不存在一个“银弹”，只有无尽的焦油坑，但大概率的是，当前产生的技术脱节于现如今的需求，如果把技术看成永远革新，那么不断进步就是解决问题的银弹。

二、感触章节

在这本书中，给我印象最深的章节是“提纲挈领”这个章节，我觉得它给我印象最深是因为他在这里提到一个很关键的东西——产品文档。

以前我自己写代码的时候不加注释不说明，但时常会出现忘记自己的分管内容是什么这一问题，经常自己的代码别人也看不懂，而同样的情况下，我也不知道该如何去解读他人的代码，这就是开发过程中的问题，简单的可以概括为是沟通的问题。

要进行软件开发，要进行项目管理，难道就凭几行代码的注释就能完成？难道就凭自己脑子里设计的构想？亦或者是几张不完全的流程图和UML？显然，这是不可能的，产品文档的出现就是为了系统的记录修正、记录整个开发过程中技术人员和项目经理对软件产品在各个方面进行的改动，无所谓大小，在软件开发的过程中，书面记录决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。

项目经理常常会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知，此时，产品文档就形成了关键的沟通枢纽，每个项目管理的工作都围绕着它们运转。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库，定义目标和需要、定义迫切需要的资源、约束和优先级。

项目经理的基本职责是使每个人都向着相同的方向前进，文档使各项计划和决策在整个团队范围内得到交流，通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整，即使它可以使得一个团队在开发的过程中逐步通过清晰地产品生命线进行开发的工作，这对团队的开发是十分的有力的、解决团队成员沟通问题的利器。

三、实践体会

本次软件项目设计实践周，我们小组的项目是网络商城管理系统的开发，也是一次完整的前后端分离的开发项目，从需求分析到设计，再到代码编写、功能实现，每个关卡都需要小组成员一起合作，而作为组长，我的工作就是分配任务设计流程，在这个过程中，就像是本书中所提到的那要，在进行决策的时候，不加入过多的人是最好的选择，多个人员的机械的加入不仅不会提高决策和设计的效率，反而会因为意见的冲突而滞留项目的工作。

项目开发用到数据库的数据调用与数据的增删改查、前台-后端-数据库的整体工作流、后端开发中的po-controller-service-mapper-xml代码流程设计与数据调用都是在开发过程中需要注意的地方，因为MYSQL中表的相关联性不一致，所以我们还要在数据库拉取结束后检查每个表里的数据，与另外表是否相关联；一开始，我也设计过由两个人一组进行结对编程是不是效率会更加的高，但是时间上来说，因为一个人住在工作过程中进行开发，另一个人是无法知道这个人的一些开发数据、参数的，所以这段时间无法进行统筹安排，会造成开发之间的冲突，特别是多人依赖在一个项目中，将会成为彻彻底底的流水线，前一个人工作卡住，后面的人都无法进行工作，所以我们在设计完基础需求之后，为大家设立了不同的开发工作。

前后端分离的开发，就要求前后端人员在设计工程中频繁的进行交流，需要及时协同人员的开发进度，对变量进行统一的设计与实现，否则会出现断联的现象，导致我们的项目无法正常的进行设计与实现，这里我们只需要在开发重合的时候及时交流，讨论自己的数据和代码，剩下的时间开发自己的工作即可，最后再统一整合，比起单线程的开发工作，效率会更加的高。

机械的协同并不会带来高效率，反而会要求开发人员考虑进度的变现问题。