人月神话读书笔记01

我过去是怎么做的：

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

这样为什么不好：

一、缺乏合理的时间进度是造成项目滞后的最主要原因。

二、人员和时间是不可以混淆互换的。

三、在一个时程已经落后的软件专案中增加人手，只会让它更加落后。

　　根据法则，增加人员到一个已经延误的专案里，等于是火上加油。除非你可以把工作区分，让新进人员可在不影响他人工作的状况下有所贡献。

四、优秀程序员与较差程序员之间生产率的差异可以达到非常大的程度，经实验测试，生产率平均为10：1，在运行速度和空间上平均为5：1的惊人差异。

五、团队应该采用小型精干的组成，在时间允许的范围内，不要单纯地再扩大人员范围。

 解决办法：

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

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

• 结构师

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

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

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

• 团队沟通

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

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

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