人月神话笔记

书不错，翻译的太烂，有的读不通，读了一遍，笔记记在书上了，又花时间整理了一遍电子版。

人月神话

焦油坑

程序可以组成编程系统和编程产品

• 编程系统： 可以进行交互。编程系统开发成本是简单程序的9倍
• 编程产品：可以被任何人运行、测试、修复和扩展。 编程产品的开发成本是程序的3倍

人月神话

1. 对估算技术缺乏有效的研究
2. 隐含的认为人月可以互换
3. 对估算缺乏信心
4. 缺少对进度的监督和追踪
5. 进度落后时，盲目的任务增加人手可以追赶进度

人月概念

1. 如果任务是完全可分解的，人月可互换
2. 人月不可互换是因为需要交流沟通导致
3. 如果项目只存在培训等，全体都需要参加的交流，那么工作量随人员增加呈线性增加
4. 如果每个部分需要仙湖交流，则工作量按照n(n-1)/2正价

产生延期的原因

1. 程序不出错的概率为0，需要提前预估出程序出错的处理时间
2. 增加人手还要对人员进行重复的培训，对任务进行重复的划分，都是时间损失
3. 缺乏合理的进度安排是最主要原因

各部分时间占比

1. 1/3时间进行计划
2. 1/6进行编码
3. 1/4进行构建测试和早期系统测试
4. 1/4系统测试

外科手术团队

1. 好的程序员和差的程序员生产效率上相差10倍
2. 开发人员进行沟通影响项目的成本
3. 沟通成本高，所以不需要沟通的交流的高级程序员价值更高

团队建设建议

每一个部分由一个团队解决

1. 外科医生：首席程序员，定义功能和性能技术书名数、进行程序设计、编码。测试以及写技术文档
2. 副手：作为设计的思考者、讨论着和评估人员
3. 管理员：对人员、薪酬等方面进行负责
4. 编辑：对各种文档进行建设。包含内部和外部描述
5. 文秘：管理员和编辑的副手
6. 程序员：负责编程和技术记录
7. 工具维护人员：相当于运维
8. 测试人员
9. 语言专家：技术专家，寻找简洁、有效的方法方案

贵族专职、民主政治和系统设计

概念完整性

1. 宁可省略一些不规则的特性和改进，不提倡独立和无法整合的系统

获取概念完整性

1. 软件的描述是计算机系统本身说明的10-20倍
2. 易用性：应该简洁、直白，注意使用习惯和每个部分都应该有同样的设计规则

贵族专治

1. 概念完整性需要由一个人活着少数人来实现
2. 将设计方法、体系结构方面的工作与具体实现分离是获得概念完整性的强有力方法
3. 系统体系结构：完整和详细的接口说明
4. 非常重要但是不兼容的构想，需要抛弃原有设计，对基本概念进行合并，合并后重新开始
5. 设定良好的时间和空间目标
6. 相当于水平划分来说，垂直划分从根本上大大减少了劳动领，使交流彻底被简化。

画蛇添足

1. 今早交流和持续沟通能使结构师有较好的成本意识
2. 估算过高的解决方案：削减设计或者采用成本更低的实现方法。
3. 第一个系统一般倾向于精炼、简洁
4. 第二个系统一般进行功能的装饰和优化
5. 为每个小功能分配一个值，每次改进
6. 不断提出正确问题，确保原则和概念上的完整性

贯彻执行

文档和手册

1. 手册是产品的外部规格说明，描述和规定了用户所见的每一个细节
2. 文档上要有带日期的版本信息
3. 手册要包含用户可见的一切。不仅仅是界面，避免描述用户不可见的东西
4. 如果要保证一致性，规则的书面化只能由1-2人完成，参与设计的人越少，统一性越高

形式化定义

1. 形式化定义就是手册需要精确
2. 选择形式化或者记叙性文字作为标准对文档进行书写，另一种则作为辅助描述
3. 所有定义的问题都可以使用测试来进行验证

会议和大会

1. 周例会：由研发和市场计划人员参加，由cto进行主持，会议中任何人可以提出问题和修改意见，建议书在会议之前进行分发，重点是创新，吧解决方案详细的记录到变更建议书中
2. 对详细的变更建议作出决策，正面和负面的意见都要被详细描述
3. 需要迅速的作出决策，举棋不定时由cto决定
4. 需要作出决策
5. 年度大会（一般半年举行一次）一般持续两周：由全体参加，对一些堆积的问题进行处理，对决策进行记录更新，第二天都会将所有已经做的决策更新到手册上，发放到人
6. 年度大会的决策更容易被接受，每个人都在倾听和参与

多重实现

1. 根绝文档修改代码比根据代码修改文档的代价要高
2. 可以根据代码修改文档也是可以的

电话日志

1. 增加问题记录
2. 保存电话日志，记录每个问题和响应的回答

产品测试

1. 需要测试是否遵循了设计
2. 测试应该在设计阶段就参与进来

巴比塔为什么失败

巴比塔的管理教训

1. 巴比塔有清晰的目标；充足的人力、材料、时间、技术但是因为交流问题导致了失败

项目中的交流

1. 公开、广泛的发布变更结果
2. 对书写的文档共同理解

项目工作手册

1. 包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录
2. 备忘录：提出建议或者解释设计
3. 利用树状结构建立索引
4. 每个编程人员都应该了解所有材料
5. 工作手册必须实时更新。通知进行了什么修改，标记修改了的文本。对变更的重要性进行批注
6. 记录修订日期和标记表更标识条
7. 一个信息系统不但能暴露接口错误，还有助于修改错误

编程项目的组织机构

1. 如果有那个工作人员，那么相互交流的接口则有（n*n-n）/2个。
2. 减少交流，使用人力划分和职责限定。
3. 产品负责人：需要保证必要的资源，建立团队内部的沟通和报告方式，确保进度目标的时间
4. 技术主管：提供解决方案，根据需要调整系统设计
5. 产品负责人和技术主管必须在基本的技术理论上具有相似的观点。在主要的技术问题出现之前，四小讨论。

胸有成竹

1. 规模小的程序，所花费的时间少的多，幂函数型增长
2. 交互越多，生产率越低

削足适履

成本的程序空间

1. 100块可以增加1g内存，而优化程序减少1g内存的占用成本是200的话，则增加硬件配置更划算

规模控制

1. 制定一系列的标准：例如每个模块的大小，内存占用，响应速度。还要限定每个模块的功能
2. 模块性能达标，系统的性能不一定能达标

空间技能

1. 设计人员需要决定用户可选项的粗细程度
2. 功能分解到很小的模块会耗费空间和降低性能
3. 空间和时间的折中

计算机产品文档

1. 文档需要定义迫切需要的资源、约束和优先级，计算机手册加性能规格说明
2. 进度： 预算
3. 组织结构图：目标、技术说明、进度、预算、组织结构、工作空间分配、报价预测
   • 制定产品的性能说明，和确定假设的价格，从而设计得出组件单元的数量，的大欧美歌单元的开发工作量和固定成本。又决定了价格
   • 价格高于预测值就需要提高性能和支持更高的时长预测，成本必须降低

关键项目的文档

1， 目标

2. 产品技术说明
3. 时间 进度
4. 资金：预算
5. 低点：工作空间分配
6. 人员：组织图

为什么要有正式的文档

1. 书面记录、明确分期、矛盾
2. 文档能够作为同其他人沟通渠道
3. 数据基础和检查列表
4. 项目经理的任务是：制定计划、实现计划，包含了时间、地点、人员、项目内容和资金。

未雨绸缪

实验性工厂和增大贵吗

1. 实验室可以进行反应过程
2. 一开始设计算法，算法应用到待发布的软件中，然后根据进度一次发布给客户
3. 第一个开发的系统，太慢、太大而且难以使用，丢弃和重新设计可以一步完成，也可以一块块的实现，
4. 必须构建一个可以用来抛弃的系统
5. 需要为舍弃而计划

唯一不变的是变化本身

1. 用户实际需要和用户感觉会随着程序的构建、测试和使用而变化
2. 不建议所有的用户需求和目标都实现
3. 除了圆形和设计需要变化，技术上也需要变化，随着学习的过程不断更改设计

为变更设计系统

1. 为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间的接口设计和完备的文档
2. 每个版本都应该有自己日程表和冻结日期，再次之后的变更属于下一个版本

为变更设计架构

1. 计划、里程碑、日程安排都是尝试性的，方便行进变化
2. 为变更组件的团队很困难，每个人被分配的工作都是多样的，管理人员和技术人才能进行互换
3. 这种需要技术管理不分家，和外科手术团队组建模式相悖

前进两部后退一步

1. 维护成本一般是开发成本的40%以上
2. 随着使用的熟练，用户使用新的功能，会发现更多的问题以及一些不容易察觉的问题
3. bug的修复会以20%-50%概率引入新bug
4. 理论上每次修改以后，都要运行先前的所有测试用例
5. 设计实现人员越少、接口越少产生的错误也越少

前进一步 后退一步

1. 随着时间推移，系统会变得越来越无需，修复就失去了根基，系统表面上可用，实际上已经面目全非
2. 现实系统不可能永远可用，基于原有系统重新设计师非常必要的
3. 开发是减少混乱度、维护增加混乱度

干将莫邪

目标及其

辅助机器和数据服务

1. 文档是图书馆或者百科全书，而不是一些类强制阅读的文章

整体部分

剔除bug的设计

1. 许多失败完全是因为那些产品未精确定义导致的，细致的功能定义、仔细的规格说明、规范化的功能描述大大减少了系统中bug的数量
2. 测试规格说明
3. 自上而下的设计：系统开发划分为体系结构设计、设计实现和物理编码实现
4. 模块分隔和模块的独立性避免了系统级的bug
5. 设计在每个精华步骤上都是可以测试的，所以测试可以尽早开始
6. 先有一个总体设计，再从总体到每个部分的精细设计
7. 结构化编程：规定循环、分支结构语句

系统集成调试

1. 系统集成调试要求只能在每个部分都能正常运行之后开始
2. 将各个部分和龙的越早，系统bug出现越早
3. 记录一直bug，测试时跳过
4. 文档化bug，
5. 制作辅助程序，为测试提供数据
6. 准备一份变更文档，把所有变更记录到文档中
7. 有详细的测试用例，并能进行回归测试

祸起萧墙

1. 灾祸一般来自于小问题的积累

里程碑还是沉重的负担

1. 里程碑必须是具体的，特定的，可计量的事件，边界明显没有歧义
2. 在活动开始之前就着手估计，每两周进行一次修订
3. 长短的过高估计都会随着活动的进行持续下降
4. 过低的估计在活动中不会有天大变化，知道计划结束日期前大约三周
5. 偏离度是士气的杀手

其他的部分反正会落后

1. 必须关心每一天的之后
2. pert图可以显示谁需要什么，谁在关键路径上，在哪发生之后会影响最终的完成日期
3. pert是关键路径的计划的细化
4. 每周对某些部分进行平生，每月进行整体评审
5. pert图需要1-3人维护更新

另外一面

亲身做示范，延时如何完成这项工作

需要什么样的文档

1. 使用程序：目的、环境、范围、实现功能和使用的算法、输入-输出格式、操作指令、选项、运行时间、精度和校验、验证程序
   • 常规数据对程序功能的测试用例
   • 少数合法数据和边界性数据验证
   • 少数非法数据的测试用例
2. 修改程序
   • 流程图或子系统结构图
   • 所用算法的详细描述
   • 对所有文件的规划解释
   • 数据流处理的概要描述
   • 初始设计中，对已遇见修改的讨论

自文档化程序

php例如phpdocument的使用规范

1. 文档整合到源程序
2. 建立程序注释规范，例如段注释
3. 用符号、后缀、编号和日志记录对应起来
4. 使用包含版本号宝珠记录程序名称
5. 包含记叙性的描述文字

没有银弹

软件的主要任务：构建抽象实体，次要任务抽象实体转变为机器码

1. 仔细进行市场调研，避免开发已上市产品
2. 获取和制定软件需求的时候，将快速原型开发作为迭代计划的一部分
3. 有机的跟新，慢慢增加新功能
4. 不断的培养概念设计人员

根本困难

1. 提高软件生产率、可靠性和简洁程度
2. 开发中的根本困难是计算机本身的复杂度
   • 函数复杂度
   • 结构复杂度
   • 安全机制等
3. 复杂度导致了技术困难和管理困难
4. 一致性导致了复杂度的增加
5. 功能扩展和适配更多硬件环境导致了复杂度增加

银弹的希望

1. 面向对象只是消除了设计表达上的次要困难
2. 人工智能
3. 自动编程
4. 专家系统
5. 图形化编程，流程图已经被证明是完全不必要的设计工具

针对概念上的根本问题的解决方法

1. 购买逗比重新开发低廉
2. 软件包的通用性使其有了更广泛的应用
3. 需求精炼和快速原型：详细的需求包括了所有的人机界面，与机器和其他软件系统的接口
4. 计划软件活动时：要让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一部分
5. 原型的目的是明确怪你按结构，是客户可以测试一致性和可用性
6. 使用增量方式开发，调用一系列的子系统，系统一点点充实，子系统轮流别开发
7. 自上而下的设计

再谈没有银弹

1. 可重用开发设计师普通开发的2-3倍
2. 易于重用是面向对象最大优点
3. 程序设计要易于定制
4. 要关注质量，又不能过分关注

人月深化是与非

焦油坑

1. 秉承系统的开发是普通程序开发工作量的9倍
2. 越接近完成收敛的越慢

人月深化

1. 缺乏合理的时间进度是造成项目延后的主要原因
2. 构思本身就有缺陷，因此会有bug
3. 分解任务会带来额外的工作量，沟通和培训
4. 1/3进行疾患 1/6进行编码 1/4构建测试
5. 对落后的项目增加人手，会更加落后

外科手术团队

1. 优秀的程序员生产率是差的程序员的10倍
2. 经验和实际表现之间没有相互联系
3. 小型、精干队伍是组好的
4. 两个人团队是最好的
5. 对于大型系统，小型团队填满

贵族专职

1. 概念完整性
2. 为了概念完整性，设计必须由一个人活着具有共识的团队完成
3. 将体系结构方面的工作与具体实现分离是获得概念完整性强有力方法
4. 体系结构、设计实现、物理实现可以并行

画蛇添足

1. 今早交流和沟通，使开发人员对设计有信息，不会混淆各自的责任分工
2. 建议一种实现方法，听取开发人员在结构上改进的建议
3. 不能过分设计

贯彻执行

1. 即使是大型设计团队，最后的设计结果也要1-2人完成
2. 明确记录更改
3. 精确详细记录设计
4. 将形式化或者记叙性作为标准，另一个作为辅助

巴比塔为什么事变

1. 尽可能多的方式进行相互交流
2. 事先指定良好结构的工作手册
3. 每个团队成员应该能够看到所有材料
4. 实时更新很重要
5. 驼队组织的目标是煎炒交流和协作
6. 不允许双重领导

胸有成竹

1. 程序开发伴随程序规模的大量增长而增长
2. 1500-1w行代码/人

削足适履

1. 设立规模目标、控制规模
2. 占据内存方面是明确、还要规定访问磁盘的次数
3. 不断的局部优化、较少考虑用户的整体影响
4. 系统整体触发面向用户
5. 早起应该制定策略、决定用户可选项目的粗细程度
6. 每个项目都应该有自己的标准组件库
7. 数据重新构建

提纲挈领

1. 目标、用户手册、内部文档、速度、预算、止机构图和工作空间分配
2. 使每个人都向着相同的方向前进
3. 文档使各项计划和决策在整个团队范围内交流

未雨绸缪

1. 需要测试环境
2. 系统丢弃和重新设计可以一步完成
3. 为舍弃而计划
4. 用户实际需要和用户感觉会随着程序的构建、测试和使用而变化
5. 维护成本是开发成本的40%甚至更多
6. 用户越多所发现的错误越多
7. 缺陷修复会议20%-50%几率引入新bug
8. 设计的人员越少、接口越少、产生的错误越少

干将莫邪

1. 大部分系统调试工作总是在夜里完成

整体部分

1. 测试需要验证说明的追却性和完整性
2. 有时候需要回退、推翻顶层设计
3. 系统调试所花费的时间会比预料更长

祸起萧墙

1. 进度表由里程碑和日期组成
2. 里程碑必须是具体的、特定的和可度量的时间
3. 慢性进度偏离是士气杀手
4. 评审机制使所有人员都可以通过它了解真正的状态。出于这个目的，里程碑的进度和完成文档是关键

另外一面

1. 用户文档包含了与软件相关的基本决策，绝大部分需要在编程之前书写
2. 除了描述还需要说明为什么这样做

20年后的人月深化

概念完整性和结构师

1. 描述了应用和实现应用的方法以及用来指明操作和各种参数的用户界面使用策略
2. 产品的概念完整性是易用性中最重要的因素
3. 概念模型包括所用功能的详细说明以及调用和控制的方法，对功能、性能、规模、成本和进度进行平衡
4. 有必要由以为主结构师吧系统分解成子系统，系统边界应该划分在使子系统间最小化和最容易严格定义的地方
5. 概念完整性是茶品质量的核心

开发第二个系统的后果

1. 盲目的功能，以性能甚至是易用性为代价，过多的向产品添加边界实用功能
2. 给用户划分类别，分析每个群体的实际需要
3. 每个都有发生频率
4. 细致的考虑对象用户群
5. 用户有属性，属性决定了某种需求的发生，通过分析可以得到哪种属性得到了需求更多
6. 通过类比得到概念完整性
7. 根据习惯，例如先选择名词，再选择动词
8. 平衡用户功能和易用性
9. 从新手向数量用户的主键过度

没有构建舍弃原型-瀑布模型是错误的

1. 瀑布模型假设项目只经理一次过程
2. 实际需要一块块的丢弃和重新设计系统
3. 瀑布模型假设整个系统一次构建完成

增量开发模型

1. 一个一个功能开发，逐渐增加模块，需要不断你的回归测试
2. 将不易于变化的设计决策放置在根部
3. 增量开发过程能使真正的用户较早的参与测试
4. 通过测试环境，获取早期的用户反馈

人月有多少深化色彩

1. 增减人手需要重新安排

使用塑料包装的成品软件

1. 成品软件提供了大型的功能模块和尽心定制的接口
2. 把系统编程更大的模块