人月神话读后感 二

  起初看到人月神话这个名字让我很意外，就像看到没有银弹这个书名一样，我原以为是一本讲述了计算机发展历史中如同神话般的历史事件的书，但是在阅读完这本书后发现并不是这样，或者说绝大部分不是这样的。

直到看了一会才知道“人月”说的不是人和月亮moon，而是月份month，主题是人数与工作所需要的时间月份之间的关系。这本书由被誉为“IBM System/360之父”的布鲁克斯所写，主要收录了人月神话、没有银弹以及近年来对这两部作品的重新回顾，虽然我犹豫能力有限，不能全部都懂，但是站在巨人的肩膀上还是有诸多的感触。

在第一章的焦油坑中，作者就用一个形象的例子向我描述了一个可怕的场景，让我了解到软件开发其实也是一个痛苦挣扎的行业。起初我对这个观点很是疑惑，与我之前的认知有悖，但是很快从作者的解释中我明白了一切：个人的开发是快乐的，因为这是一种自由的创作，可以获得帮助他人或是不断学习的快乐。但是真正的大型软件的开发却有着许多我不曾了解的困难，一切事情在追求完美的时候都会变得困难而令人痛苦，在项目接近完成时却逐渐变慢的进程对人也是一个巨大的打击，让人无法从阶段获得快乐，最终无法给我带来快乐。带着这些忧虑我也开始了接下来的阅读。

第二节也是与书标题相同的人月神话，他向我们阐述了一个简单但是缺被许多人忽视的道理：一味的堆人并不能如预期地加快项目进度，正如Brook所说的那样，向进度落后的项目中增加人手只会导致项目进度进一步地落后，臃肿的团队缺乏合适的结构，只会导致浪费更多的时间在沟通上，从而导致了效率的显著降低。

接下来的几节描述了各种规模下推荐的团队组织结构，以及一些提高协作效率的方法，但给我印象最深的是外科手术团队的形式进行工作，因为这也是与我们目前学习过程中能接触到的团队规模。程序的开发是一种很主观的过程，多人合作的工作往往很难获得统一，而文中提到的外科手术团队却可以完美解决这种问题。团队由一个核心主持编程，一个副手帮忙把关代码质量，剩余团队负责专门的工作为核心减少别的事情的打扰，可以最大程度上减少因团队交流带来的困难和效率降低。

后文看到的种种团队结构也正如我的猜想，围绕了团队交流这一方向展开，各种不同结构的团队，各种需求文档的规范和写作，或许会使整个团队显得机械化，但是会极大的提高精确度，减少交流成本，提高工作效率。

其中给我印象比较深刻的还有文中提到的周会和年会，我此前对这种会议都是只有一个大概的印象，但是不大明白具体有什么意义，而作者的直观表述为我解答了这个疑惑。会议的形式可以降低交流成本，让团队成员始终对于项目有着足够的认识，而持续两周的年会能为整个项目带来足够的总结机会和更多创意，对于一个规模较大的团队来说作用极大。

正如作者在巴别塔那章所描绘的那样，交流和交流的结果——组织正是成功的关键，而人们这些年来发明并实践出的各种规范标准也都是为了提高交流沟通的效率而制定的。

而在另外一面这一节中提到，维护各个文件的同步关系是一种吃力不讨好的行为，因此在编程的过程就完成详细规范的注释，或许在编程过程中会有些繁琐，但是带来的自文档化的好处，才是一个比较好的解决方案。

没有银弹更是阐述了复杂性、一致性、可变性以及不可变性这四个根本特性决定了软件开发中很难出现银弹，人们对于这种“银弹”的盲目追求甚至优点类似于古人对炼金术的追求。但是虽然没有银弹，但是强制的模块化和规范清晰的接口等等都可以有效提高效率。

而在后续对人月神话的回顾中也提到，即便是过去了那么多年，当年文章中提到的大部分内容确实一点都没有过时，不得不让我佩服作者的高瞻远瞩。