《人月神话》阅读笔记

1.为什么中国的程序员总是在不断学习新的开发工具、钻研程序代码，而不呢逐步提升自己的视野、思维和经验？

2.从众多面向对象建模的描述中，你可以横清楚地看到这些恶果，而且它们还经常伴随着有关现实世界建模的非常美好的词汇。然而，仔细看看，你就好发现它们其实是彻头彻尾的编程对象！

3.如果说有任何和现实世界相似的地方，不管是死是活，纯属巧合。。。。。。

4.手中有个锤子，看到什么都是钉子。

5.我相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；我相信关键需要的是维持产品自身和概念完整性。

6.学习编程最困难的部分，是将做事的方式向追求完美的方向调整。

7.大型的或小型的，庞杂的或精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去了解问题。

8.不真实的假设——一切都将运作良好。

9.所以系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所应该花费的时间。

10.是开发人员承担创造性好发明性的实现责任，所以结构师只能建议，而不能支配。

11.有意识关注这个系统（第二个）的特殊危险；运用特别的自我约束准则，来避免那些功能上的过于修饰；根据系统基本理念及目的变更，舍弃一些功能。

12.保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

13.绝不要携带两个时钟出海，带一个或三个。

14.手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而这里他的设计和创造自由是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该视图支配具体的实现过程。

15.形式化定义仅仅用于外部功能，说明它们是什么。

16.所有定义的问题可以通过测试来解决。

17.作为一种定义，实现体现了过多的内容：它不但描述了系统必须做什么，同时还声明了自己到底做了什么。

18.当实现充当标准时，还必须防止对实现的任何修改。

19.正式的书面建议集中了注意力，强制了决策的制定。避免了会议草稿纪要方式的不一致。

20.同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。

21.任何在规模上碰到问题的程序员，会检查自己的代码，看是否能将其中一部分扔给其他人。

22.为了满足目标，每个人都在局部优化自己的程序，很少会有人停下了，考虑一下对客户的整体影响，对大型项目而言，这种导向和缺乏沟通是最大的危险。在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。在这种监督机制之外，是实现人员自身的态度问题。培养开发人员从系统整体出发、面向用户的态度是软件编程管理员最重要的职能。

23.只有记录下来，分歧才会明朗，矛盾才会突出。

24.不变只是愿望，变化才是永恒。

25.为舍弃而计划，无论如何，你一定要这样做。

26.变化是与生俱来的，不是不合时宜和令人生厌的异常情况。

27.开发人员交付的是用户满意程度，而不仅仅是有形的产品，用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

28.软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。

29.抛弃原型概念本身就是对事实的接受——随着学习的过程更改设计。

30.高强度的考验查出了新功能中很多不易察觉的问题。

31.产品的概念完整性在使它易于使用的同时，也使开发更容易进行，而且Bug更不容易产生。

32.开发人员自己无法完成这项工作，他们不会告诉你他们不懂。相反，他们乐于自己摸索出解决问题和澄清疑惑的办法。

33.一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了各种表面装饰般的补丁。

34.计划日期是项目经理的工作产物，代表了经协商后的项目整体工作计划，它是合理计划之前的判断。

35.估计日期代表了再现有资源和已得到了作为先决条件的必要输入的情况下，基层经理对实际实现日期的最佳判断。

36.在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分。

37.软件的特性本身也导致不大可能有任何的发明创新。

38.软件开发人员为客户承担的最重要的职能不断重复地抽取和细化产品的需求。

39.我的从业背景是程序员，乐观主义是这个行业的职业病。

40.复杂性是我们这个行业的属性，而且复杂性是我们主要的限制。

41.只有实际需要时，才会用到最新的设想。

42.我们的构思本身是有缺陷的，因此总会有Bug。

43.我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。

44.正如我们前面所看到的，实现同样是一项高级的创造性活动。具体实现中创造和发明的机会，并不会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也一样。

45.在说明完成的时候，才雇佣编程实现人员。这也正是在搭建一座建筑时所采用的方法。

46.整个创造性活动包括了三个独立的阶段：体系结构、设计实现和物理实现。

47.概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。

48.外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。一旦他们将注意力集中在没有人解决过的问题上，创意就开始奔涌而出。在毫无限制的实现小组中，在进行结构上的决策时，会出现大量的想法和争议，对具体实现的关注反而会比较少。

49.实际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。

50.系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。

51.结构师一直处在解决用户问题，实现用户利益的核心地位。如果要得到系统概念上的完整性，那么必须有人控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。

52.系统的结构师，如同建筑的结构师一样，是用户的代言人。结构师的工作，是运用专业技术知识来支持用户的真正利益，而不是维护销售人员、制作者所鼓吹的利益。

53.对于给定级别的功能，能用最简洁和直接的方式来指明事情的系统是最好的。

54.简洁和直白来自概念的完整性。每个部分必须反映相同的原理需求的一致平衡。

55.由于目标是易用性，功能与理解上复杂程度的比值才是系统设计的最终测试标准。单是功能本身或者简洁都无法成为一个好的设计评判标准。

56.用户发现寻找一个特定功能是很容易的，但相应却有太多的选择，要记住太多的选项和格式。

57.我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。

58.他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。

59.整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。

60.系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。

61.对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。

62.由一个人完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力、

63.这就是小型、精干队伍概念上的问题：对于真正意义上的大型系统，它太慢了。

64.我常常重复这样的一个观点，需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点，也暗示系统应该由尽可能少的人员来开发。实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度慢的、低效率的，开发出的是无法再概念上进行集成的产品。

65.项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。

66.向进度落后的项目中增加人手，只会使进度落后。

67.某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。

68.软件开发本质上是一项系统工作——错综复杂关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗新任务分解所节省下来 个人时间。从而，添加更多的人手，实际上是延长了而不是缩短了时间进度。