读《人月神话》有感

Posted 2020-07-26

最开始还在纠结选哪本书来看，后来问了问度娘和知乎，有一本书被广泛传阅了许多年而经久不衰，这本书有着一个炫酷的名字--《人月神话》，下面是我对这本书的了解和粗读的感想。

《人月神话》是软件工程方面的一本经典著作，作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。

首先，书中很雷到我的是Brooks提出的这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所以软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。　　

书中又说到，系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。我们前期的准备就发现，经过一开始的头脑风暴后，确实需要一两个强大的人来扮演架构师的角色，很幸运的是，我们拥有像夏睿和海峰这样的队友。

第七章说到了巴别塔项目失败的原因是缺乏交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。

纵览整本书的体会就是：软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。软件编码实现过程中，需要不是人多，而是少而精的优秀程序员，编码员。所以整体程序员的素质很重要，有必要培训提高他们的素质。 软件系统可能是人类创造中最错综复杂的事物，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发人员日夜奋战的结果。概念完整性将软件开发连成了一条钻石项链，每个部分都不可忽视，不可取代。整体的抽象完整时软件管理的灵魂。正因为如此，可见架构师的重要性。因此另一方面 把工作切分给更多人做将造成额外的沟通代价——训练和相互的交流。欲增加软件项目的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。

以上就是粗读《人月神话》的一点愚见，好书，以后有时间一定再读。