人月神话读书笔记（一）

人月神话读书笔记（一）

第一次听说人月这个概念是从操作系统老师口中得知的。不太记得清他到底说了啥了，但提到了man month和人月神话这本书，也提到了一些关于项目开发的一些东西（年代久远了真的不记得了）

但直到现在我才翻起人月神话这本书，下面谈一下我自己的感受，尤其是在结对作业完成之后的感受。没有看得太多，因为书的确讲得有意思所以我看得比较慢和细。

书里说得一点儿都没错，第一章焦油坑就提到了，编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。这次的结对作业代码量也就这么样，但和队友细细一算，林林总总散落在各个角落中我们一起花的时间可真是一个很可观的数字了。虽然结对编程还比不上编程系统产品开发这种东西，但至少也涉及到了交流和维护，构思与时间进度等东西。

• 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。

  这点一点儿都不假，一开始我们十分乐观，觉得很容易就能完成编码这个任务，但实际上操作起来却碰到了各种各样的问题，以至于后期所花的时间密度比前期不知道多了多少（还好有ddl这条线233）

  因此计划十分必要。在我看来，对于项目的开展，必要的“功利性”是必须的，这是促使项目朝着某个具体成果前进的动力，否则，进展、质量都会成为问题。作者认为安排给计划的时间应为整个项目时间的三分之一，这也许能给我点团队项目作一些参考

• 我们的构思是有缺陷的，因此总会有bug。

  这也不假，很多bug我自己根本无法察觉到，只有到了UI组同学的手中，一经他们测试，才能显露出来。在此也得感谢一开始和我们对接的UI组同学耐心而又细致而又不厌其烦的测试。

• 结构师

  在结对作业里其实我也多多少少扮演了一下结构师的角色，但好像并没有像书中所讲的那样有效。

  在这里稍微提一下书中描述的结构师究竟是个什么角色。结构师的角色类似专制的贵族：“一位或少数杰出的结构设计师来设计体系结构，这样就能帮助很好的控制整体完整性。”这看似是一种专横压制其他成员创造性的做法，但事实上，具体实现也是一项创造性活动，具体实现中创造和发明的机会，并不会因为指定了外部体系结构规定而大为减少，相反创造性活动会因为规范化而得到增强。

  可能是因为结对的两人扮演的角色有点多（我瞎说的），而且我给队友提供的思路并不总是正确，我自己也经常改变主意，一改主意队友又不知道我到底是怎么想的了，因此我提供的所谓的软件框架相当不靠谱，这大概是我们结对编程效率有点低下的原因吧。

• 团队沟通

  这一点我们可以说做得很不好了。我自己的代码写完后并没有足够的文档给队友参考，同理队友的也是。

  但作者主要介绍的项目工作手册，包含了项目所有的文档，主要有目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。使用工作手册可供技术工作者查看硬件或软件的设计实现思路和相关细节，这些都将对产品提出建议或解释设计，另外工作手册可控制信息发布，即确保信息能到达需要它的人手中。

  但时间上并不允许我们做如此详尽的准备，在团队作业中也许值得尝试把书中的这些规范一一落实。

  ​

  ​