人月神话读书笔记

人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
沟通所增加的负担由两个部分组成， 培训和相互的交流。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作，则工作量按照n(n - 1) / 2递增。
因为软件开发本质上是一项系统工作----错综复杂关系下的一种实践----沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
       1/3 计划；
       1/6 编码；
       1/4 构件测试和早期系统测试；
        1/4 系统测试
向进度落后的项目中增加人手，只会使进度更加落后。
体系结构陈述的是发生了什么， 而实现描述的是如何实现。
实际上，产品的成本性能比很大程序上依靠实现人员，就如同易用性很大程序上依赖结构师一样。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有的文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。
决不要携带两个时钟出海，带一个或三个。
团队组织的目的是减少不必要交流和合作的数据。
减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
技术主管角色是什么：他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程序。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。
产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。
交流和交流的结果---组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
非常少的交互：一个一年大约能写10，000行代码。少量交互：5000行；较多交互：1500。
数据的表现形式是编程的根本。
创造出自精湛的技艺，精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。
任何管理任务的关注焦点都是：时间、地点、人物、做什么、资金。
程序维护中的一个基本问题是---缺陷修改总会以（20-50）%的机率引入新的bug。所以整个过程是前进两步，后退一步。
系统软件开发是减少混乱度的过程，所以它本身处于亚稳态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的过程。
A good workman is known by his tools.
现实在，流程图被鼓吹的程序远大于它们的实际作用。 我从来没有看到过一个有经验的编程人员，在开始编写程序之前，会例行公事地绘制详尽的流程图。
良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
所有的编程人员都是乐观主义：一切都将动作良好。
同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。
两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。
为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
团队组织的目标是为了减少必要的交流和协作量。
精炼、充分和快速的程序。往往是战略性突破的结果，而不仅仅技巧上提高。这种突破常常是一种新型算法。更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。
程序员不愿意为设计书写文档的原因，不仅仅是由于惰性。更多的是源于设计人员的踌躇----要为自己尝试性设计决策时行辩解。