【笔记】《人月神话》——从"削足适履"到"另外一面"

这是最近看《人月神话》时中途记录的一些笔记，稍稍改变下计划，这个是9-15章节的笔记，这样后面的银弹和记录能记录得比较连贯些。

这次篇幅不长，一下就看完了。感觉应该来给文章加个好看点的模板，说不定能吸引更多人呢？这次先试着修改下常用的字体大小试试。

削足适履

1. 应该从整体上来评价软件的规模，不应该仅仅就规模本身对软件进行批评
2. 规模目标的设置应该是在项目经理在对每个可用方案有了深刻的了解后设定的，聪明的经理还会给自己预留一些目标以在工作进行时分配
3. 必须对项目每个地方进行规模预算，而且要注意各个部分间规模的变化可能造成的互相影响
4. 应该制定好整体的规模预算
5. 应该在指明模块规模时，同时清晰指出模块的功能，防止每个人的局部优化不经意间损害了全局
6. 即架构师应该确保开发中的概念完整性
7. 开发不仅是做加法，适度的减法减少用户的选择可以换来更高的效率
8. 牢记时间换空间与空间换时间，达到削足适履
9. 要意识到在项目过程中开发公共库事半功倍

提纲挈领

1. 软件需要的文档内容： 目标，技术说明，进度，预算，组织结构图，工作空间安排，报价预测与价格循环
2. 其中报价预测与价格循环是决定项目成败的关键，预测决定报价，报价决定成本得到价格，价格高于预测时又需要调整预测。项目经理就如同一个调度轮稳定这个循环，经理的经验决策惯性管理着人员是否按照正确的速度执行

1. 管理的关注点永远是时间，地点，人员，项目内容，资金
2. 无论项目多小，都要立即生成若干小文档来作为自己进度和人员安排的数据的基础并要求其他人也给出基础小文档
3. 最初的文档不会是正确的，需要随时改变
4. 书面记录下决策内容和过程是必要的，记录下来才能看到分歧和矛盾
5. 文档也是人员的交流渠道和自己的数据基础和记录列表
6. 项目经理最基本的职责是沟通好每个人让之朝着正确的方向前进
7. 项目经理的直接任务是制定计划并安排人去实现计划，要利用文档来辅助自己快速设定好自己的方向和与人沟通

1. “普遍的做法是选择一种做法，试试看；如果失败了，没关系，再试试别的。不管怎么样，最重要的是先去尝试”——罗斯福
2. 一个称为“试验性工厂”的步骤是必要的，能在缺乏保护的情况下用典型数据来测试我们的项目是否能正确运行
3. 项目做出来的第一个版本常常是不合用的，如果我们把这个原型发布给用户虽然可以得到时间和回报但是常常会影响声誉和分散接下来的精力
4. 所以一定要构建一个生来用来抛弃的系统，也就是第一个版本，为舍弃而计划项目的进度
5. 产品的变化是与生俱来的，不是不合时宜令人讨厌的东西，开发人员最终交给用户的不仅仅是产品还是用户的满意程度，用户的需求和感觉会随着产品的构建和使用不断变化。而软件产品易于掌控又不可见的特性使开发者面临永恒的变更
6. 很多软件开发小组失败的原因是管理得太少而不是太多，详尽的文档方便控制
7. 开发人员通常不愿意提交尝试性的决策文档，因为这会使他们暴露于批评下，除非对他们做好保护
8. 人员结构要做好变化的准备，时刻准备几个可变动的顶级程序员可短时间去某些部门帮手
9. 不要认为管理岗高于开发岗，给人们相同的待遇或废除头衔或创造两条并行的晋升线
10. 管理者也应该学技术，开发者也应该学管理，项目的进度，管理问题等信息应该在整体高级人员间共享
11. 软件维护不仅包含修复漏洞还包括增加新功能
12. 用户越多维护所需的投入就越多，维护的成本将占到全部成本的40%甚至更多，所以要做好规划

1. 对缺陷的修复会以一定的几率(20%-50%)引入新的bug，所以开发维护的过程是走两步退一步
2. 每次维护后要进行一次整体的重新测试，因为修复缺陷可能带来新的缺陷，维护人员也常常由不稳定的新手负责，可能带来更大范围的问题
3. 随着时间的推移，软件的模块数量会呈线性增长，系统的混乱程度会不断提高，就算有再好的维护系统也只是放缓了这个过程，一段时间后基于原本系统进行重新设计是必要的

干将莫邪

1. 即使是现在很多软件仍然像是五金店，熟练的开发人员则搜集创造自己的一套工具集作为自己的技能证明，但要明白这样的行为其实是阻碍了软件开发时的沟通，开发公共的工具会让编程效率更高
2. 项目经理必须意识到工具的重要性，不能吝啬财力物力开发公共工具
3. 有些软件运行在数量有限的开发平台上，对平台调试进行时间分配时，时间片模式会高效于批处理模式，因为提供给小组更长的连续调试时间和间隔的总结计划时间能提高效率，比批处理提高的利用率更重要
4. 开发机可能有很多的bug，要将这些bug记录起来，后续的使用人员遇到时才能快速意识到
5. 项目的每个小组应该有属于自己的独立的开发区，程序在里面自由地调试，当经理需要时小组再提交自己那部分的成果，由集成小组负责组合并测试，发布更新正式的版本
6. 创造一个性能仿真工具是必要的

整体与部分

1. 开发一个完整可用的软件需要剔除bug保证稳定，有完整的测试保证可用，不是那么简单的事情
2. 产品需要有概念的完整性来保证开发有序和较少的bug
3. 很多项目的失败来自于定义的不精确，编写任何代码前应该把规格说明详尽地提交给测试组来准备检查工作
4. 采用自上而下的设计可以更好地对抗bug并方便对设计进行调整，让我们能清楚自己所作出的调整是属于整体的哪部分和其中的缘由
5. 当要把部件组合在一起时，使用尽量没有bug的部件防止加大测试的难度
6. 对于暂时还排不上解决的bug，将其文档化使后继者方便跳过
7. 测试通常使用传输设定好的假数据的假接口，包含各种典型记录和特殊值的假数据文件
8. 必须有专门的小组负责整体的组合和版本的变更，且每改动一个部件就要进行一次版本记录和文档修改，且进行一次子系统的测试，不要懒惰，这样能避免之后的很多bug
9. 在每个大版本更新间隔中内部都要使用快速补丁来进行更新，每个变更都要文档化

祸起萧墙

1. 和直觉不同，项目常常是因为大量的小问题而产生难以察觉的漫长的进度落后，而非因为重大的事故
2. 所以在一开始就要制定一个完整的进度表，进度表中每个安排好的事情称为里程碑
3. 里程碑必须是具体，特定，可度量的事情，具体的里程碑是百分百的事件，不能有模糊的地方
4. 在实际实施中，现状应该比进度超前，只有不断地保持超前才有能力处理突发的灾祸并有时间进行计划调整和进度的重新度量
5. 使用关键路径图来做项目的准备工作，关心每一天中对进度的偏离
6. 关键路径图的准备是图最有意义的部分，在项目早期就完成非常专业的关键路径图可理清整个任务的关系，第一份图常常很混乱低效，不要害怕，在工作中不断完善它
7. 让进度信息公开的窍门是减少角色的冲突，必须让执行者明白它的进度需要被评审者了解但评审者不会干扰它的执行，
8. 关键路径图中详细的里程碑是最终进度的评审来源，最好每周一次小评审，每月一次大评审
9. 关键的文档是里程碑实现情况的一大依据，负责某个里程碑的经理必须在评审的时候说出当前的正确进度和解决延迟的方法
10. 产品线总经理负责了解当前进度的情况并将重点放在如何获得更准确的进度估计并监督不要漏报瞒报

另外一面

1. 即使是开发给自己的产品也应该写文档，因为自己在未来也会失去对产品的理解
2. 给用户看的内容与给机器的编码一样重要
3. 不同的用户需要看不同的文档，对于每个文档都要有包含以下内容的一段基础总结性文字

1. 发布的产品应附带测试程序，证明自己的可用性并作为一份简单的教程
2. 测试用例的数据主要是下面三方面：代表性的正常数据，合法的边界数据，非法的数据
3. 对于目标是修改此程序的用户，提供的文档应有以下的进一步文字

1. 流程图被严重高估了，软件的流程图不应多于1页，且只是大略的介绍数据流即可
2. 新时代更适合的是自文档化的程序，让程序拥有详尽的注释，规范的编码风格和注释之间易用的跳转或指引，修改程序时也要同时修改程序，让程序和文档一起产生
3. 应对使用的基础算法提供参考引用和算法书籍的位置，方便索引并减少篇幅
4. 在程序总列表中应加入箭头之类的关系表
5. 功能处于同样逻辑中的短代码可写作一行