第一章 焦油坑
1.编程系统产品开发的工作量是供个人使用的、独立开发构件程序的9倍；
2.编程行业提供了五种乐趣：创建事物，开发对其他人有用的东西，灵活组合，不重复任务可以不断学习，易于驾驭使用；
3.苦恼也有：将做事方式调整到追求完美，其他人会设定一些自己无法控制的事物，真正权威是每次任务的完成，创造性活动伴随了枯燥的艰苦的劳动、越接近完成越要命（或者说收敛过慢）、容易因为自己开发的产品因为环境的进步而显现的老旧
第二章 人月神话
1.缺乏合理的时间进度控制是造成滞后的主要原因，比其他任何事情影响的和还大；
2.好的东西需要一些时间来沉淀；
3.似乎所有的程序员都是“乐观主义者”；
4.期待不会有困难；
5.本身构思是有BUG的；
6.围绕成本核算的估计技术，混淆了工作量和项目进展；
7.若干人员中分解任务会引发额外的沟通工作量；
8.时间分配 计划：1/3，编码1/6，构件测试1/4，系统测试1/4；（这个是一次迭代，或者说瀑布模型中是这样的）
9.作为一门学科，缺乏数据估计；
10.我们队自己的技术不确定，常常缺乏支持自己计划的勇气，被迫添加时间等问题；
11.为落后进度的项目添加人手因为成本的增加（重新分配任务的中断，培训新人，额外的沟通）导致进度会更加落后；
第三章 外科手术队伍
1.相同程度的培训，优秀的人员的生产率是较差成员的10倍；
2.经验与实际表现没有相互联系，这种情况是普遍成立的；
3.小型、精干队伍最好（思绪少，相互交流容易）-----相对于普通情况下，如果是大型的可以将领导人拆出来做成一个决策组，来提升协调；
4.两人队伍，必须有一人是领导地位；
5.真正的大型系统，需要大型队伍；
6.绝大多数系统的经验显示，一拥而上的方法是高成本、缓慢、低效甚至无效的，开发的东西无法在概念中集成；
7.一个首席程序员（后来叫做架构师），可以采用一个外科手术式的队伍完成10人配比的队伍。大概是主程序、管理（BOSS）及他的文秘、编辑及他的文秘（这个可以省略），副手（和主程序相比，什么都会，但是没有主程序那么精通），其他程序，语言专家（外援），测试员这样的配比来执行，相应的还可以有工具维护人员（也是程序员的一种，负责辅助程序的开发）
第四章 贵族专制、民主政治和系统设计
1. 首先请考虑概念的完整性；
2.功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能；
3.为了概念的完整性，设计必须由一个人或具有共识的小型团队来完成；
4.对于大型的项目，将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力的方法；
5.如果要获得概念上的完整性就必须有人控制这个概念，这是无需任何歉意的必须的贵族专制；
6.纪律、规则、规矩对整个行业是有益的。外部的限制是为了增强，而不是用来限制一个小组的创造性的；
7.概念上的统一方便开发和测试；
8.体系结构、设计实现、物理实现这些工作是可以并行执行的。
第五章 画蛇添足
1.尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工；
2.结构师如何成功地实现影响：
（1）结构师只提出建议，实现留给程序员；
（2）时刻准备着为所指定的说明建议一种实现方法，准备接受其他任何实现的可行方案；
（3）对上述的建议保持低调和平静；
（4）对所建议的进行改进放弃坚持；
（5）听取开发人员对结构上的改进的建议。
3.第二个系统是人为设计的最危险的那个，因为会进行过分设计
4.画蛇添足最明显的一个例子是OS/360
5.为功能分配一个字节和微妙的优先权值是一个很有兼职的规范化方法。
第六章 贯彻执行
1.大型的设计团队也必须是一个或者相互默契的少数人来完成，保持一致性；
2.必须明确定义体系结构中与原先定义不同的地方，力度应该和原先保持一致；
3.出于精确性的考虑，我们需要形式化地设计定义；同样，我们需要记叙性的定义来加深理解；
4.必须采用形式定义和记叙性的定义中的一种来作为标准，另外一种作为辅助，他们都可以作为表达的标准；
5.设计实现，包括模拟仿真，可以冲淡一种体系结构的定义；但他有一些严重缺点（时间的浪费、设计实现思想的限制等）；
6.直接整合是一种强制性推行软件的结构性标准的方法；
7.如果期初至少有两种以上的实现方式，体系结构的定义会更加的整洁和规范；
8.允许体系结构师对实现人员的询问做出电话式的应答解释，而且这一点是非常重要的，并且必须进行整理和发布，（现在可以使用电子邮件的形式）；
9.项目经理最好的朋友就是他每天面对的对手：独立的产品测试机构/小组；
第七章 为什么巴比伦塔会失败
1.原因：缺乏交流以及交流产生的结果（组织）
2.交流的作用：
（1）团队成员之间产生理解的偏差的处理，
（2）应该尽可能团队应该尽可能多的方式进行相互之间的交流（非正式的简要的技术陈述会、共享的正式项目工作手册）
3.项目工作手册
（1）项目工作手册不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构
（2）项目所有的文档都是工作手册中的一部分
（3）应当尽早和仔细地设计工作手册结构
（4）事先制定良好结构的工作手册可以将后来的东西添加进去，提高产品质量
（5）每个团队成员都应该了解工作手册
（6）注意实时的更新
（7）工作手册的使用者更多的注意与上个版本中的变更在哪；
（8）尽可能的采用较为先进的，易于查看的方式保存文档；
（9）用变更条和修订日期等方式来标记文字；仍然需要栈结构的电子化记录变更小结
（10）各个部分封装起来，尽可能看它提供什么接口，入口是什么出口是什么掌控好即可；
4.组织架构
（1）组织架构的目的是减少一些不必要的交流和协作量
（2）为了减少不必要的交流组织结构包括了人力划分和限定职责范围
（3）不要出现双重领导的情况，容易分散精力，或者说容易导致变更不可控；
（4）交流的话是网状的，当然根据情况需要适应性调整
（5）每个子项目有两个不同的领导，分别掌控对外和对内，需要不同的技能，一个是项目经理，一个是架构师（技术主管）
5.两种角色组合是有效的
（1）项目经理和技术主管是同一个人
（2）产品负责人做老大，而技术主管是副手
（3）技术主管是老大，产品负责人当副手
第八章 胸有成竹
1.仅仅通过对编码部分时间的估算，然后乘以系数，呵呵肯定是无法获得一个较为精确的估算的
2.构件独立小程序的数据不适合编程系统
3.程序开发随着规模的大量增长而增长
4.它们时间的指数是大约是1.5，也有一种结果表明是在1.05-1.2之间
5.相比于其他活动，全职的程序员仅将50%时间用于编程和调试
6.生产率大约是100-200行/天的有效生产率（使用C语言或者更加底层的语言），当然如果不计BUG可能在1-2k之间
7.在基本的语句级别的话，生产率是一个常数
8.当使用适当的高级语言生产率是5倍提升（也就是实际上可以达到600-1200）
第九章 削足适履
（这个里面好多过时了）
1.开销主要是两种：一种是时间上的，一种是空间上的开销（这种开销在现代（2017年）可能就不是问题了）
2.当然在内存上长期驻留的程序要比其他程序有用的多，比如操作系统自带的必须的驱动等程序
3.软件开发人员必须设立规模目标，控制规模（虽然现在空间不是很值钱了但是如果构件太多重复度会大的不要不要的好么？）
4.规模预算必须与分配的功能相关联；指明模块大小的同时，确切定义模块的作用
5.规模预算不仅仅是在内存方面要明确，还要指明对磁盘的访问次数
6.大型团队中，各个小组倾向于不断地局部优化，满足自己的目标，但是考虑用户的感觉少了一定要注意这个
7.在整个系统的实现过程中，系统结构师一定要保持持续的警觉性，确保连贯的系统完整性；
8.从系统的整体出发，面向用户是最重要的职能。
9.早期指定策略，决定用户可选项目的粗细程度
10.暂存区空间的尺寸及每次访问磁盘数是很重要的，因为性能是非线性函数（这个........过时了，因为以前是用的虚拟内存，现在是用的好多好多的内存，内存已经不是瓶颈问题了好不........）
11.为了取得良好的空间（这个也明显过时了）——对时间可以进行折中处理
12.编程需要技术积累，每个项目应该有自己的标准库，积累自己的代码库；
13.库中的每个组建要两个版本（一个速度快，一个小）--------这个明显也过时了啊
14.精炼、充分、快速的程序往往是战略性的突破，而不是技巧的提高
15.突破的话常常是一种算法的提升
16.这种战略上的突破常常来自于对数据或表的重新表达，数据的表现形式是编程的根本。
第十章 提纲挈领
1.少数文档会成为项目的关键枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具
2.对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配以及机器本身的报价、预测和价格
3.对于大学科系，关键文档类似于目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室的分配、教师和研究生助手的分配。
4.对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配
5.即使是小型项目也应该对上述的一系列文档进行规范化
6.以上集合中的每一个文档的准备工作都将注意力集中在思索和对讨论的提炼上，而书写这中文档需要上百次的细小决定
7.对每个关键文档维护提供状态监督和预警机制；
8.每个文档本身就可以作为检查列表或者数据库；
9.项目经理的基本职责是让每个人都朝着相同的方向前进；
10.项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流
11.只有一小部分管理人员的时间（20%）从给自己头脑外部获取信息
12.因为上面一条的原因，广受吹捧的市场概念——支持管理人员的“完全信管理系统”病不基于反映管理人员行为的有效模型。
第十一章 未雨绸缪
1.软件也需要一个实验性工厂来作为提高产量和在却反保护的环境下运作提供宝贵经验
2.对于编程产品而言，这样的中间步骤同样是必要的，但是软件工程师在发布产品前很少可以进行这种测试（各种原因导致）
3.第一个开发的系统可能对于大多数项目并不合用。它可能太慢、太大，而且难以使用
4.系统的丢弃和重新设计可以一步完成也可以一块块的实现，但是这是必须完成的步骤
5.将第一个系统给用户，节省时间，但是对于用户是非常痛恨的.........，对于产品可能就影响了他的声誉......
6.因此一定要做出一些尝试，而为舍弃而进行的计划则是必须要做的（这个被现在证明是错误的了，因为模型的建立）
7.开发人员交付的应该使用户的满意程度而不是实际的产品
8.用户的实际需要同用户的感觉会随着程序的构建、测试和使用而变化
9.软件产品易于掌握的特性和不可见性，导致它的构建成员面临着永恒的需求变更
10.目标上的一些正常变化无可避免，实现为它们做准备总比假设它们不会出现要好的多
11.为变更而计划软件产品的技术，特别是拥有较细致的模块接口文档的结构化编程广为人知，但是并没有相同规模的实践。尽可能地使用表驱动（数据库驱动？？？）是有所帮助的。（现在看来这个似乎是面向对象编程的一种方式呢）
12.高级语言的使用、编译时操作、通过引用的声明整合和自文档技术能减少变更引起的错误。
13.采用良好的数字化版本将变更量子化（现在的软件版本的升级更新就是这个思想的实践，实际证明这种方法目前来看还是很有效的一种方法呢）
14.程序员不愿意为设计写文档，因为他需要为这种设计做辩解（这点在实习的时候感觉最深...只有我一个愿意留文档，结果各种询问，各种需要回答）
15.为变更组建团队比为变更进行设计更加困难
16.只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才可以进行互换，特别是希望可以在技术和管理人员相互之间自由分配人手的时候
17.两种晋升（一个技术，一个管理）的高效组织机构存在着一些社会性的障碍，人吗必须警惕并积极地同它做持续的斗争。
18.很容易为不同的晋升路线提供相同的薪水，但是不能提供相同的威信，这个需要潜在设置，比如相同的办公室，一样的调动权限等等。
19.外科手术式队伍似乎是一种解决方案
20.程序的维护主要是由于各种变更组成的
21.对于一个广泛使用的程序，其维护成本通常是其开发成本的40%或者更多
22.维护成本受用户数目的影响，用户越多，所发现的BUG越多
23.一个现实产品生命期中的每个月BUG数是先下降（因为用户知道怎么用且程序员知道怎么修改），然后上升（用户要体验新功能了，新功能中的BUG被发掘了）
24.缺陷修复的话有20%~50%的几率引入新的BUG
25.每次修复后要先运行所有的测试用例来避免新BUG
26.能消除、至少是能指明副作用的程序设计方法，对维护成本有很大的影响
27.实现设计的人越少，接口越少，产生的错误也就越少
28.模块数量随着产品的版本号呈现出线性增长，但是模块随版本号指数的增长而受到影响
29.所有修改都倾向于破坏系统的架构，增加了系统的熵（混乱度）。即使是最熟练的软件维护工作也只是延缓了系统退化到最混乱的程度的进程，以至于有时候须有重新进行设计。（许多程序升级的真正需要会冲击它的内部结构边界，原油边界引发的不足常常在日后体现）
第十二章 干将莫邪
1.项目经理应该制定一套策略，并为通用工具的开发分配资源，同时也需要意识到专业工具的需求
2.开发系统的队伍需要自己的目标机器，进行调试开发工作，安排一位成员专门维护这个东西，保证机器上的标准软件是及时更新和实时可用的
3.目标机器的需求是一种特殊曲线，先很低，然后爆发使用，然后平缓
4.大部分调试工作在夜间进行（用的人少啊）
5.应该分配连续有效的时间提供调试
6.技术不断在变化，但是采用时间块来安排匮乏计算机资源的方式，现在仍然可用（比如天河I号？）
7.主程序库中应该划分成（1）独立开发私有库（2）正在测试的库（3）发布版本
8.使用文本编辑器节省工作量
9.系统文档大容易产生不容易理解的问题，但是会比短小的文章提供更多的信心来描述系统
10.自伤而下的进行开发
(以下内容因为高级语言的全世界范围的推广已经过时了)
11.高级语言一定要好好用，还有就是新语言的出现懒惰会妨碍它的推广
12.高级语言提升工作效率，并且改进调试，找BUG更容易
13.传统的什么运行慢，容量大现在已经不是问题了
14.某些应用上，批处理文件系统不会被交互式系统替代（目前成立，比如银行？？？）
15.调试是编程中最困难的部分（受程序员的思维影响导致）
16.交互式编程的效率是非交互式编程的2倍
第十三章 整体部分
1.详尽的体系结构工作可以使产品更加易于使用，而且更容易开发，且BUG不容易产生
2.许许多多的失败来源于未精确定位的地方
3.编写代码前，规格说明书必须提交给外部测试人员测试
4.自上而下的设计还是很重要的
5.每个步骤中尽可能使用较高级别的表达
6.有时可能需要回退推到顶层设计重新开始设计
7.结构化编程程序的作用域要在控制域内
8.系统调试相对于单元测试所花费的时间会比预料更长
9.提供调试的困难程度证明了需要以一种完备的系统化和可计划的方法
10.系统调试应当在所有部件都能运作后开始
11.辅助测试的工具还是很有必要的
12.必须有有人进行变更和版本控制以及文档化
13.系统测试期间，一次只添加一个构件
14.变更的阶段（量子）要么很大，要么很小
第十四章 祸起萧墙
1.项目怎样被延迟了整整一年呢？一次几个小时，然后好几次，嗯 好了积少成多
2.一天一天的落后比重大灾难更难识别
3.根据一个严格的进度表来控制大型项目第一步是制定进度表（由里程碑和日期组成）
4.里程碑必须是具体的、特定的和可度量的时间，能进行清晰的定义
5.如果里程碑定义的非常明确，以至于无法自欺欺人时，程序员很少会就里程碑弄虚作假
6.大型项目的估计行为需要每两周或者一周左右进行一次重新估计时间，期间各种错误估计都会随着计划结束变得越来越少
7.慢性进度会严重损耗士气
8.进取是不可或缺的
9.我们可能需要各种图表来定义，辅助项目经理的进度过程控制管理
10.状态的获取是比较困难的，因为下属的经理有充分理由不提供当前的进度状态
11.老板的不良反应会全面压制各个方向上的进度，最后导致拖延期限
12.必须有一个评审机制使所有成员可以通过它了解真正的状态
13.如果产生疑问，尽快停止对评估日期的怀疑
14.对大型项目的话，历程被报告进行维护的计划和控制小组是非常可贵的
第十五章 另外一面
1.对于软件产品，程序和文档同样重要
2.即使是给程序员自己用的东西也必须有一些辅助，因为长时间不改之前的代码，会忘（深有体会啊，一个月前写了些什么还有印象，两个月前的东西，大概是怎么实现的，六个月前.......这个是我写的代码么？）
3.培训、学习、以及管理人员应该对文档有积极的态度
4.大多数文档写的很泛化，请放慢脚步，稳步进行
5.关键的用户文档包含了软件相关的基本决策，决策是在第9章（可能有点过时的）
6.每个发布的程序应该提供一些测试用例
7.修改程序的他们需要内部文档（参考第5章）
8.流程图不要太精细，除非要求
9.因此流程图一般不会超过一页
10.为了使文档易于维护，在程序代码中通过添加注释是必要的
11.最小化文档负担的三个关键思路
（1）借助必须存在的语句，如名称和声明
（2）一定的格式来标注它们
（3）以段落在程序中进行注释
12.程序修改的时候一定要注意，说明之前有哪些缺陷，现在为什么要改
第十六章 没有银弹
1.银弹在这里是指一种快速有效的方案解决软件的所有的开发过程
2.原因是软件的本身特性（会有各种变更，各种需求）导致不可能有（极大进步的）发明创新（都是小步快跑那种概念）
3.软件内在特性包括：复杂度，一致性，可变性，不可见性
4.以往解决一些困难的方案：使用高级语言，分时，统一编程环境
5.可能未来银弹存在的希望：新的高级语言，面向对象编程（目前正在大规模使用），人工智能，专家系统，自动化编程，图形化编程，程序自验证，新的计算机环境和工具，工作站。
6.如果需要快速解决可以使用的方法：购买，自行开发需求软件，需求精炼和快速原型，增量开发而不是直接搭建系统（正在大规模使用的一种），使用卓越的设计人员（有时候需要培养）
7.培养设计人员的方法
（1）尽可能早地、有系统地识别顶级设计人员，最好的往往不是最优经验的
（2）为设计人员指派导师，负责他们的成长
（3）为每个方面制定和维护一份职业计划，包括与设计大师的、经过仔细挑选的学习过程，正式的高级教育和短期的课程
（4）为成长中的设计人员提供相互的交流和激励机会
8.硬件的快速发展也导致了软件会变更特别特别的快
第十七章 再论没有银弹
Emmm....这章理解的不是很透彻，似乎是说 没有银弹 那一章受制于那个年代（20世纪六七十年代）下的一种特殊限制，于是产生了争论
1.含糊的表达将会导致误解
2.更笨和次要问题需要清晰划分
3.独立评价每一个可能成为银弹的部分
于是在这章中评论，可能面向对象编程（2017年）这种目前广泛使用的是一种次一些的解决方案，但是也比之前的好很多？
第十八章 第一版总结章
这章内容与本文类似，准确来说，本文是基于这一章诞生的
第十九章 20年后的人月神话
这里主要写的是1995年那个时候的情况
首先是核心观点--概念完整性和结构师
1.概念完整性：一个良好的软件产品应该向它的每一位用户提供一个条理分明的概念模型。
2.指派一名架构师是最重要的行动，而架构师就是负责概念完整性的那位
3.将体系结构和设计实现，物理实现相互分离，将会使架构师的关键任务更加可行
4.架构师的方案可以得到快速的重用
开发第二个系统所引起的后果——盲目的加功能和对使用频率的猜测
1.为大型用户群设计，这个会更加困难因为需要为不同的用户提供各种分配权重的方案，这也是目前来看大部分架构师正在研究的东西
2.盲目的功能，由于对边界功能的不断添加，导致边界功能过多的添加
3.用户群的定义成为了当前的主流需要记录的属性有：
（1）他们是谁who
（2）他们需要什么 need
（3）他们认为自己需要什么 need
（4）他们想要的是什么 want
4.频率，架构师应该猜测或者假设一系列完整的属性和频率值
图形界面的成功
这个描述的可能有上面那种交互式编程相关吧
1.通过类比获得了概念的完整性
2.命令表达与双光标提升了速率
3.目前可以提供出卓越的解决方案可以解决一些问题
4.用户功能和易用性，因为图形化界面让用户使用更舒适些啊
5.从新手向熟练用户的逐渐过渡（应该说的是图形化加快了这个进程）
6.成功的实现了设备的直接整合
没有构建而舍弃 -> 原型——瀑布模型是错误的
（但是它却给初学者接触软件工程提供了一个很好的思路）
1.瀑布模型项目是只经历一次所以才会产生了一些现在看起来不是很正确的观点
2.必须存在逆向移动
增量开发模型更佳——渐进地精化
还有在软件工程中，目前来看人员因素可以说是决定了大部分的软件构造的内容，而且对争论的仲裁是由团队组成的，而微型计算机的普及改变了每个人软件开发的方式。
软件工程在很多时候还真的像化学工程那样如何扩展到工业级别的非线性问题以及与工业工程类似，总是被人类行为的复杂性所困扰着，于是人工智能神经网络还有越来越多的名词在软件工程领域在不断诞生么？
--------------------
此文十分好，总结的挺好的。引用作为我的第二篇文章。原文链接：https://blog.csdn.net/jzsxyj1111/article/details/77986704