《人月神话》摘录

胸有成竹

1. 对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括编程中需要注释，并可能存在错误的情况。

2. 使用适当的高级编程语言，编程的生产率可以提高5倍。

削足适履

1. 为了满足目标，每个人都在局部优化自己的程序，很少会有人停下来，考虑一下对客户的整体影响。对大型项目而言，这种导向和缺乏沟通是最大的危险。

    培养开发人员从系统整体出发、面向用户的态度是软件编程管理职员最重要的职能。

2. 项目经理可以做两件事来帮助他的团队取得良好的空间 - 时间折中。一是确保他们在编程技能上得到培训，而不仅仅是依靠他们自己掌握的知识和先前的经验。另外一种方法是认识到编程需要技术积累，需要开发许多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或者宏库。

3. 数据的表现形式是编程的根本。

提纲挈领

1. 注意这些文档的组成与计算机项目非常相似：目标、产品说明、时间安排、资金分配、空间分派和人员的划分。这种相似性不是偶然的——任何管理任务的焦点都是时间、地点、人物、做什么、资金。

2. 软件项目的文档

   做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。

   做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。

   时间：进度表

   资金：预算

   地点：工作空间分配

   人员：组织图

未雨绸缪（plan to throw one away）

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

2. 前进两步，后退一步。显然，使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大的回报。同样，实现设计的人员越少、接口越少，产生的错误也就越少。

3. 前进一步，后退一步。系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即时是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的过程。

干将莫邪（sharp tools）

1. 毫无疑问，开发和维护公共的通用编程工具的效率更高。不过，仅有通用工具是不够的。专业需要和个人偏好同样需要很多专业工具。所以在前面关于软件开发队伍的讨论中，我建议为每个团队配备一名工具管理人员。这个角色管理所有通用工具，能知道他的客户--老板使用工具。同时，他还能编制老板需要的专业工具。

整体部分

1. 如何将经过测试的一系列构建集成到已测试过、可以依赖的系统？

2. 系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配，是大多数致命和难以察觉的bug的主要来源。

3. 简言之，产品的概念完整性在使它易于使用的同时，也使开发更容易进行以及bug更不容易产生。

4. 细致的功能定义、详细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量。

5. 关键的地方和构建无bug程序的核心，是把系统的结构作为控制结构来考虑，而不是独立的跳转语句。

6. 使用完好的、经过调试的构件，能比搭建测试平台和进行全面的构件单元测试节省更多的时间。

7. 上述技巧的关键因素是对变更和差异的记载，即在一个日志中记录所有的变更，而在原代码中显著标记快速补丁和正式修改之间的区别，正式修改是完备并经过测试的，而且需要文档化。

8. 因为那些原来可以在子系统上成功运行的用例，必须在现有系统上重新运行，对系统进行回归测试。

祸起萧墙/

1. How does a project get to be a year late ? ... One day at a time .

2. 好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出合理要求的一项服务，而不确切的里程碑是难以处理的负担。当里程碑没有正确反映损失的时间，并对人们形成误导，以致事态无法挽回的时候，它会彻底碾碎小组的士气。慢性进度偏离同样也是士气杀手。