人月神话读书笔记
摈弃个人主义
摒弃个性化工具，提倡维护公用工具：
个性化的工具带有明显的个人倾向，并存在着过时和不兼容的问题。比起使用个人维护
工具带来的隐患，使用适合项目本身的一系列考虑，计划，组织的工具更加提升效率。在实
际开发中需要使用的公共工具通常分为：机器设施支持，操作系统资源，编程语言，调试工
具。文档处理工具。其中机器支持又分为目标机器和辅助机器，目标机器即软件最终运转在
该机器上，辅助机器指在开发过程中提供服务的机器。
针对开发出成功可用的系统的可行性提出“除掉可能存在的 bug 设计”，“进行构件的
单元测试”，“进行系统的集成测试”
项目进度是如何一步一步落下的：
里程碑的制定模棱两可，技术人员对于交付的功能点不明确，使得老板往往得到一份与
当前项目实际进度不符合的里程碑报告。当某一部分进度落后时，认为其他部分的情况一样，
缺乏进取的心和主动解决问题的意识。
通过教堂建筑风格来表示“提倡和谐统一，反对特立独行”，强调“易用性”
对“贵族专制”持肯定态度，认为必要的民主牺牲会对整个国家治理的“一致性”提供更多
保障。程序员在概念实现上不需要太多的“想法”
- 避免盲目乐观
- “乐观主义”不可取
- 利用“人月”来衡量工作量
- 强调系统测试的重要性
- 避免在第二个项目中因为“放松警惕”而画蛇添足
唯一永远不改变时不停的改变：
对于整个软件开发周期，项目的开发通常都是确定好设计算法后直接面向用户进行开发，
往往交付给用户的第一代产品具有过时，臃肿，效率低下等瑕疵之处。借用化工业生产的工
业模式，在讲实验室的研究成果大量投入生产前，通常会在一个试验工厂进行预生产，试验
工厂的产品达到技术标准后再大量投入正式生产。软件开发也是如此，因为项目在不断推进
中会逐渐偏离预先的设计算法，再造成不可逆的工程危机前进行模拟性的开发，可以将这一
风险降至最低。虽然这样的作法显得有些多余和浪费人力物力，但对于软件开发这样充满不
确定因素的开发活动，适当地牺牲一些成本会使得最终达成的结果易于交付和使用。
前进两步，后退一步或前进一步，后退一步：
软件的高开发成本不仅在于其设计阶段需要考虑多种的可变因素，在交付后的软件维护
阶段也会耗费巨大的人力资源。一个软件的用户数越大，bug产生的数量越多。虽然用户的
深度使用，bug的数量会继续增长，以前修复的bug 也可能再次出现。这是由于每次修复
bug需要引入新的执行语句，这些新的语句很大程度上会成为未来 bug的备用军。一般情
况下，在修复了旧的 bug 后应当对全局的系统进行一次全方位的测试，只有通过测试才能
确保此次修复不会带来新的问题。这样虽然增加了维护的成本，但为日后的维护结局了潜在
的隐患。
提倡科学管理
- 强调人员分配及每个职位在团队所占比例对项目交付时间的影响
- 提出了“外科医生”的运作模式
- 规格说明应同时包括形式化定义和记叙性定义
- 沟通与交流：周会，年会，电话日志
- 大型项目中的交流：非正式途径，会议，工作手册
举例巴比伦塔的建造失败是由于沟通不便使得人们之间关系疏远，最终遗弃工程。这个
例子告诉我们参与建造人员之间的沟通以及人员调度的组织方式有时候比工程的核心技术
更加决定整个工程的进向。
项目工作手册的编写不仅仅是为了让日后参与到该项目的开发人员对项目的初始设计
目的有较为准确地认知，同时它还具备控制信息发布的作用。通过使用树状的索引结构可以
确保信息的分层，每个工作人员可以通过有效的信息检索来获取到对应准确的信息。
对于如何衡量系统编程所耗费的时间，有如下几条较为典型的数据模型：
- Portman数据，
- Aron数据，
- Harr数据，
- OS/360数据
时空间的选择：
在考虑软件系统的开发成本时通常会设计时间和空间上的消耗，二者相互关联密不可分。
当系统设计者认为将软件主要程序常驻系统内存，占用较大内存开销会给系统带来更多的稳
定性。如果仅仅为了节约内存租用的资金成本而采取其他手段减少内存消耗，着眼于程序自
身的改进，妄图通过高效算法来节约空间成本，这种做法是不合适的。无法在强调软硬件集
成开发的同时，对系统的规模大小进行限制。
项目规模的控制:
项目经理根据用户的需求和工程上的设计，对既有的工作量做出内容和时间上的分配。
在指定规模时应当制定下总体规模的预算大小，同时对于后台存储也应当留有相应的备存。
在明确模块规模后应当明确各自承担的功能。要加强团队成员的沟通，每个人不仅仅应当完
成自己的功能模块，还应当跳出来观察全局和其他模块，做到适配全体，兼顾他人。
空间技能的规划：
当系统所持有的内存处在受限状态下，系统本身的高效性，可复用性可能无法体现。即
使是系统中功能划分最为细密的模块，在缺乏充足的运行内存下也无法正常发挥作用。虽然
可以通过采用分配临时交换区的方法实现，但节省下来的也仅仅是这些过多的访问次数所附
加的临时内存，仍然可能因为核心模块功能的限制影响系统的高效性。
产品文档：
通常项目经理需要从技术，组织，商用等多角度整理与项目有关的但十分繁琐和单调的
文书工作。尽管这一工作充满着被“吞噬”的可能性，但条理清晰，分工明确的产品文档往
往可以避免项目一开始就陷入焦头烂额的状态。
软件项目文档的组成：
通常围绕着目标，产品技术说明，进度安排，预算，工作空间的分配，人员分工组织图。
文档的生成受项目资源种类的约束，并随着项目的开发进行不停的修改与迭代。
没有银弹
根本原因：
软件设计不同于其他的工业设计，其中的复杂度，一致性，可变性，不可见性使得软件
开发存充满大量的不确定性。
为何复杂度不可简化：
过去几个世纪的物理学家和数学家为复杂的物理现象建立模型来忽略复杂度的影响，进
而只关注问题的本质属性。但对于软件来说复杂度即是它的根本属性之一，因此无法通过已
有的建模来简化软件的复杂程度。
为何软件无法达到一致性：
自然界中的种种物理现象之间是存在着某种统计的内在逻辑的，爱因斯坦相信上帝不是
反复无常和不循专一的。然而对于软件而言，不同的接口和组件来自不同的开发人员基于不
同的需求环境下达成的非一致性的结果，这就使得让软件内部设计完全能遵循某一一致性准
则变得尤为困难。
