推荐一本书——《人月神话》

推荐一本书，叫《人月神话》。

全书分为20章，作者是布鲁克斯，这本书讲述了作者在IBM公司做大型软件系统OS项目经理时的实践经验。

布鲁克斯这哥们是美国人，是博士，也是教授，在IBM做过事，还得过图灵奖，是个牛人。

此书读来令人拍案叫绝，惊叹不已，五体投地，感觉不读此书真是人生虚度。（黄金开头法，逼格满满，代入感贼强）

---

一句话概括全书内容：人是程序员，月是时间，，如果10人干1个月如果等同1人干10个月那就成神话，即10人干1个月的软件工程进度是恒小于1个人干10个月的。

解释：假设每个人一天的工作量恒定，那么10个人干1个月的工作量是等于1个人干10个月的。但是这十个人之间需要交流，进度会下降不少。

其实一切的根源就是我们软件造的越来越大，大到像王者荣耀那样（几百万行源代码，还只是源代码），我们人类一个人的信息流根本无法掌控。这种趋势是无法避免的，所以软件危机也是无法避免的。毕竟你企业想要挣到钱，就得弄出拿得出手的软件，要是靠着一个不到一万行的软件，是没前途的。

---

不喜欢废话，自己写的博客是为了自己看的，写那么多废话有个P用。
第1章 焦油坑
1.1 编程系统产品

做大型软件开发就好比一个焦油坑。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。
没试过团队合作，不过自己写软件的时候，如果不是按照一定的章法来写，确实会越来越迷糊。

1.2 职业的乐趣
1.3 职业的苦恼
第2章 人月神话
2.1 乐观主义
2.2 人月

①.Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。所以在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。
②.不为系统测试安排足够的时间简直就是一场catastrophe。

2.3系统测试
2.4 空泛的估算
2.5 重复产生的进度灾难
第3章 外科手术队伍
3.1 问题
3.2 Mills的建议

外科手术型队伍：小型，精英组成的团队。
项目进程中，个人沟通的花销是巨大的。
为了减少沟通，Mills建议，大型项目的每一个部分由一个团队解决，该队伍以类似外科手术的方式组建。
这样，每个团队的代表和首席架构师交流，每个团队内部交流，有效地减少了沟通。

3.3 如何运作
3.4 团队的扩建
第4章 贵族专制、民主政治和系统设计
4.1 概念的完整性
4.2 获得概念的完整性

这章整到政治上了，拿政治的不同进行对比，看的云里雾里的。

4.3 贵族专制统治和民主政治
4.4 在等待时，实现人员应该做什么
第5章 画蛇添足
5.1 结构师的交互准则和机制

这章是对架构师的忠告。
不要向系统添加很多无谓的功能
把成本高的功能削减设计或者换成成本更低的实现方法，如果有时间限制的话。

5.2 自律-开发第二个系统所带来的后果
第6章 贯彻执行
6.1 文档化的规格说明-手册
6.2 形式化定义
6.3 直接整合
6.4 会议和大会

对于开发团队来说，实现人员有疑问时应询问相应的架构师，而不是一边自行猜测一边工作。
即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

6.5 多重实现
6.6 电话日志
6.7 产品测试
第7章 为什么巴别塔会失败

巴比伦塔项目的失败是因为缺乏交流和组织。
每个人或多或少地更改一下规章输入输出，就会给其他人的整合带来要命的麻烦。

7.1 巴别塔的管理教训
7.2 大型编程项目中的交流
7.3 项目工作手册
7.4 大型编程项目的组织架构
第8章 胸有成竹

如何做到胸有成竹，要知道以下信息？
做出整体所需要的时间是要远远大于分别作出部分需要的时间之和的，越大的工程整合时间越长。
在公司中，要完成一个项目，你只有一半的时间来编写和调试代码。

8.1 Portman的数据
8.2 Aron的数据
8.3 Harr的数据
8.4 OS/360的数据
8.5 Corbato的数据
第9章 削足适履

这章说了一个现象，团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。
我们要从系统整体出发来编程。

9.1 作为成本的程序空间
9.2 规模控制
9.3 空间技能
9.4 数据的表现形式是编程的根本
第10章 提纲挈领
10.1 计算机产品的文档
10.2 大学科系的文档
10.3 软件项目的文档

这章讲了文档在开发中的重要性，有着指引团队方向，规范时间的作用。

10.4 为什么要有正式的文档
第11章 未雨绸缪
11.1 试验性工厂和增大规模
11.2 惟一不变的就是变化本身
11.3 为变更计划系统
11.4 为变更计划组织架构

废话。。。
目标上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。

11.5 前进两步，后退一步
11.6 前进一步，后退一步
第12章 干将莫邪
12.1 目标机器
12.2 辅助机器和数据服务
12.3 高级语言和交互式编程
第13章 整体部分
13.1剔除bug的设计
13.2 构件单元调试
13.3 系统集成调试
第14章 祸起萧墙
14.1 里程碑还是沉重的负担

可以在项目开发过程中弄一个里程碑，也就是deadline,这样会更有干劲

14.2 “其他的部分反正会落后”
14.3 地毯的下面
第15章 另外一面
15.1 需要什么样的文档
15.2 流程图
15.3 自文档化的程序
第16章 没有银弹-软件工程中的根本和次要问题
16.1 摘要
16.2 介绍
16.3 是否一定那么困难呢？-根本困难
16.4 以往解决次要困难的一些突破
16.5 银弹的希望
16.6 针对概念上根本问题的颇具前途的方法
第17章 再论“没有银弹”
17.1 人狼和其他恐怖传说
17.2 存在着银弹-就在这里！
17.3 含糊的表达将会导致误解
17.4 Harel的分析
17.5 Jones的观点-质量带来生产率 //没感想，无聊~~
17.6 那么，生产率的情形如何
17.7 面向对象编程-这颗铜质子弹可以吗
17.8 重用的情况怎样
17.9 学习大量的词汇-对软件重用的一个可预见，但还没有被预言的问题
17.10 子弹的本质-形势没有发生改变