【Book】人月神话
技术方面书籍选择最经典的《人月神话》，软件工程同学必备，人手一本。确实都是实实在在的经验。
时间和人月在需要团队交流的情形下不可互相替换。此时，人月不是一个好的衡量单位。从人月出发，引出软件工程的主要问题探讨。作者的写作功底十分了得。
本书提到的问题不仅仅是软件开发的问题，而是一个大项目都会碰到的问题。作者提出的最大的关键就是维持产品自身的概念完整性。这不仅仅是一个软件产品会碰到的问题，而是所有产品会碰到的问题。
至此，“如何经营公司”主题阅读结束。总共阅读了6本不同主题的书。他们虽然描述的是“如何经营公司”的不同方面，但有许多地方都是相同的。也许因为他们都在探讨如何做成一件事？光光看书的用处是不大的。并且我看书做笔记的方式也消耗了我大量的时间，虽然增加了记忆，但减少了思考的时间。看一本书，最重要的是思考和行动。今后的阅读，将更多采用“kindle摘出句子+自身思考”的方式。同时希望在日常生活中多回忆起这些书的内容。
- 序言
- 第1章 焦油坑
- 第2章 人月神话
- 第3章 外科手术队伍
- 第4章 贵族专制、民主政治和系统设计
- 第5章 画蛇添足
- 第6章 贯彻执行
- 第7章 为什么巴比伦塔会失败
- 第8章 胸有成竹
- 第9章 削足适履
- 第10章 提纲挈领
- 第11章 未雨绸缪
- 第12章 干将莫邪
- 第13章 整体部分
- 第14章 祸起萧墙
- 第15章 另外一面
- 第16章 没有银弹——软件工程中的根本和次要问题
- 第17章 再论“没有银弹”
序言
本书还是有一个中心的论点。简言之，我相信由于人员的分工，大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大；我相信关键需要的是维持产品自身的概念完整性。
第1章 焦油坑
编程系统产品
- 程序
- 编程产品
- 编程系统
- 编程系统产品
职业的乐趣
职业的苦恼
第2章 人月神话
乐观主义
系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所”应该“花费的时间。
人月
第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。
人月暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。
沟通所增加的负担由两个部分组成：培训和相互的交流。
系统测试
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
- 1/3 计划
- 1/6 编码
- 1/4 构建测试和早期系统测试
- 1/4 系统测试，所有的构建已完成
在许多重要的方面，它与传统的进度安排方法不同：
- 分配给计划的时间比平常的多。即便如此，只是勉强产生详细和稳定的计划规格说明，并不足以容纳对全新技术的研究和探索。
- 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
- 容易估计的部分，如编码，仅仅分配了1/6的时间。
空泛的估算
非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出有力的、看似可靠的和规避风险的估计。
显然我们需要两种解决方案。开发并推行生产率图标、缺陷率图标、估算规则等等，而整个组织最终会从这些数据的共享上获益。
重复产生的进度灾难
重新安排进度。我喜欢P.Fagg，一个具有丰富经验的硬件工程师的忠告：“避免小的偏差”（Take no small slips）。也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细，彻底地完成，从而无需重新确定时间进度表。
冒昧地简化一下Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
第3章 外科手术队伍
研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。
问题
小型、精干队伍概念上的问题：对于真正意义上的大型系统，它太慢了。
Mills的建议
Harian Mills的提议提供了一个崭新的、创造性的解决方案。Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
如何运作
团队的扩建
第4章 贵族专制、民主政治和系统设计
概念的完整性
我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
获得概念的完整性
由于目标是易用性（simplicity），功能与理解上复杂程度的比值才是系统设计的最终测试标准。单是功能本身或者简洁都无法成为一个好的设计评判标准。
贵族专制统治和民主政治
我当然不认为只有结构师才有好的创意。新的概念经常来自实现人员或者用户。然而，我一直试图表达，并且我所有的经验使我确信，系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法与特色，最好防盗一边，不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上重新开始。
至于贵族专制统治的问题，必须回答“是”或者“否”。就只能存在少数的结构师而言，答案是肯定的，他们的工作产物的生命周期比那些实现人员的产物要长，并且结构师一直处在解决用户问题，实现用户利益的核心地位。如果要得到系统概念上的完整性，那么必须有人控制这个概念，这实际上是一种无需任何歉意的贵族专制统治。
在等待时，实现人员应该做什么
在说明完成的时候，才雇佣编程实现人员。这也正是在搭建一座建筑时所采用的方法。
第5章 画蛇添足
如果将制定功能规格说明书的责任从开发快速、成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束结构师的创造性热情呢？
基本回答是结构师和建筑人员之间彻底、谨慎、和谐的交流。
结构师的交互准则和机制
想要成功，结构师必须：
- 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；
- 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；
- 对上述的建议保持低调和不公开；
- 准备放弃坚持所作的改进建议。
自律——开发第二个系统所带来的后果
第二个系统是设计师们所设计最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾经在第一个系统中被小心谨慎地放在次要位置。
第6章 贯彻执行
文档化的规格说明——手册
手册或书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
形式化定义
直接整合
会议和大会
多重实现
电话日志
产品测试
第7章 为什么巴比伦塔会失败
巴比伦塔的管理教训
交流与组织
大型编程项目中的交流
项目工作手册
大型编程项目的组织架构
第8章 胸有成竹
Portman的数据
Aron的数据
Harr的数据
OS/360的数据
Corbato的数据
第9章 削足适履
作为成本的程序空间
规模控制
空间技能
数据的表现形式是编程的根本
第10章 提纲挈领
计算机产品的文档
大学科系的文档
软件项目的文档
为什么要有正式的文档
第11章 未雨绸缪
试验性工厂和增大规模
唯一不变的就是变化本身
为变更计划系统
为变更计划组织架构
前进两步，后退一步
前进一步，后退一步
第12章 干将莫邪
目标机器
辅助机器和数据服务
高级语言和交互式编程
第13章 整体部分
剔除bug的设计
构件单元调试
系统集成调试
第14章 祸起萧墙
里程碑还是沉重的负担
“其他的部分反正会落后”
地毯的下面
第15章 另外一面
需要什么样的文档
流程图
自文档化的程序
第16章 没有银弹——软件工程中的根本和次要问题
摘要
所有软件活动包括根本任务——打造构成抽象软件实体的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。