《人月神话》读书笔记

1.焦油坑
对于成年人来说，编程是一种极为纯粹的快乐，通过编程，人类可以体验类似于上帝创造世界的快感。同时在编程过程中，人们必须持续的进行学习，并将学习的内容实时地应用于实践中，并产生可见的结果（打印结果，绘制图形等）。正是这种对于学习成果的可见性和发自内心的创造事物的快感，构建了编程的快乐。
但是，在编程过程中也存在很多苦恼的事。由于每个程序不是一个完全独立于其他资源的个体，因此通常编程过程需要依赖一些其他人提供的资源，但是这些资源往往是不完美的，会存在很多未知的错误，编程人员需要消耗大量的时间去研究依赖的资源，并修改其中的错误。同时，编程人员自己创造的程序时常也是存在诸多bug的，相对于创造的快感，由于完成目标的压力与编程人员与生俱来的完美主义的双重压迫，寻找并改正差错的过程有时会显得些许无趣，甚至有些令人苦恼。
编程就是这样，犹如一个焦油坑，编程人员深陷于创造事物的快乐，却也被其中的苦恼所包围。
2.人月神话
在编程时，即编程人员将脑中的构思转换为程序的过程中，错误往往是无法避免的，因为人的思路中会隐藏着一些不完善的地方，这些不完善的地方只有在具体实现过程中才暴露出来，与此同时，由于编程人员都是乐观主义者，对于自己的思路的期待超出了其本身的完善度，编程人员通常以为“一切可以很好的运行”，造成了程序的实现过程具有很多预料之外的困难。
在软件完成过程中，项目管理人员在进度估算上也存在谬误，比如将人月作为工作量的单位，这种认知方式使得很多项目管理人员误以为人月是可以互换的，但在实际情况中，很多程序开发任务是不可分解的，人员的增加对于加快项目进度毫无益处。即使对于某些需要沟通的可分解任务，增加人员后也会带来一些额外的培训及沟通成本，由于软件开发是一种具有错综复杂关系的系统工作，随着人员的增加，这种沟通带来的额外增加的时间成本可能大于未进行分解前的时间成本消耗，反而造成开发时间的延长。同时由于过度的乐观主义，对于整个项目的系统测试时间往往分配的过少，而实际情况是在系统测试阶段会出现大量的未知的错误，在项目即将发布的时候，这些问题对于整个团队将会产生巨大的压力和高昂的代价。
在软件开发的项目进度估算过程，大多数时候仅仅凭借项目经理的直觉进行判断，当客户给予的压力过大时，项目经理极其容易做出不合理的项目进度安排。
在项目进行过程中，如果发生进度落后的情况，项目经理难免会下意识的增加项目人手，但是，增加项目人数会带来培训，交流的额外时间消耗，进而很可能造成“Adding manpower to a late software project make it later”的可怕状态，抑或是项目经理只能临时减少项目中的任务，已完成项目进度。
综上，项目开发过程中，缺乏合理的项目进度安排极可能造成项目的滞后，因此在项目开始前，就要对项目进度，项目工作量进行合理的计算，并未项目最终的系统测试留下充裕的时间，保证项目的容错性。
3.外科手术队伍
对于小型的开发项目来说，小型、精干的队伍的生产效率显然是更为高效的，但是，随着项目规模的扩大，小型的队伍即使具备极高的开发效率也无法及时完成项目的开发工作，因此，必须适量的扩大队伍规模。当队伍规模扩大后，就必须对开发队伍进行合理的职能分配，以确保将交流成本降至最低。Harlan Mills认为，大型项目应该分为若干部分，每个部分，又一个外科手术式的团队完成开发，在每个团队中，只有一两个人主要负责开发设计工作，其他人负责“外科医生”的协助工作，所有不一致的观点由“外科医生”负责统一，通过这种人员的专业化分工实现高效开发。
4.贵族专制、民主政治和系统设计
在系统的设计规划过程中，系统的结构师必须注意平衡复杂的功能与简洁的使用方式之间的矛盾。同时，系统的结构师也要像贵族专制制度中的专制贵族一样，实现整个系统的设计，而不是像民主政治一样由所有实现人员参与技术说明的开发。而且现实证明，这种“专制”不仅不会扼杀实现人员的创造力，反而使技术人员在可掌控的范围内实现了虽大程度的创造性发挥。而系统实现人员子啊等待系统的结构师进行技术说明开发的时候，可以预先进行选择系统实现需要的算法、库等工作。
5.画蛇添足
对于项目来说，作为系统结构师开发的第二个系统时是最危险的时候。由于系统结构师在开发第一个系统时，潜意识的会搁置一些对系统过度修饰的功能，以保证项目进度；但系统结构师在开发第二个系统时，之前隐藏的所有过度装饰和润色功能会全部加入设计方案。这些过度的装饰功能会造成系统变得过度复杂，这不仅为开发过程带来了很多不必要的成本开销，也可能会使系统功能变得过度繁杂，进而影响基础功能的使用。
6.贯彻执行
系统的结构师在完成系统设计后需要将自己的设计思想完整无误的传达给每一个编程实现人员，并且保证每个编程实现人员能够理解自己的设计思想。因此结构师需要撰写文档化的规格说明——手册。在手册中，结构师需要清晰、完整、准确的描述产品的外部规格，也需要定义兼容性等目标，但是应当注意的是，手册中不应对产品的内部实现做过多的规定，从而保证由编程实现人员决定具体的实现过程。