寒假读书笔记2

焦油坑
对于成年人来说，编程是一种极为纯粹的快乐，通过编程，人类可以体验类似于上帝创造世界的快感。同时在编程过程中，人们必须持续的进行学习，并将学习的内容实时地应用于实践中，并产生可见的结果（打印结果，绘制图形等）。正是这种对于学习成果的可见性和发自内心的创造事物的快感，构建了编程的快乐。
但是，在编程过程中也存在很多苦恼的事。由于每个程序不是一个完全独立于其他资源的个体，因此通常编程过程需要依赖一些其他人提供的资源，但是这些资源往往是不完美的，会存在很多未知的错误，编程人员需要消耗大量的时间去研究依赖的资源，并修改其中的错误。同时，编程人员自己创造的程序时常也是存在诸多bug的，相对于创造的快感，由于完成目标的压力与编程人员与生俱来的完美主义的双重压迫，寻找并改正差错的过程有时会显得些许无趣，甚至有些令人苦恼。
编程就是这样，犹如一个焦油坑，编程人员深陷于创造事物的快乐，却也被其中的苦恼所包围。
人月神话
在编程时，即编程人员将脑中的构思转换为程序的过程中，错误往往是无法避免的，因为人的思路中会隐藏着一些不完善的地方，这些不完善的地方只有在具体实现过程中才暴露出来，与此同时，由于编程人员都是乐观主义者，对于自己的思路的期待超出了其本身的完善度，编程人员通常以为“一切可以很好的运行”，造成了程序的实现过程具有很多预料之外的困难。
在软件完成过程中，项目管理人员在进度估算上也存在谬误，比如将人月作为工作量的单位，这种认知方式使得很多项目管理人员误以为人月是可以互换的，但在实际情况中，很多程序开发任务是不可分解的，人员的增加对于加快项目进度毫无益处。即使对于某些需要沟通的可分解任务，增加人员后也会带来一些额外的培训及沟通成本，由于软件开发是一种具有错综复杂关系的系统工作，随着人员的增加，这种沟通带来的额外增加的时间成本可能大于未进行分解前的时间成本消耗，反而造成开发时间的延长。同时由于过度的乐观主义，对于整个项目的系统测试时间往往分配的过少，而实际情况是在系统测试阶段会出现大量的未知的错误，在项目即将发布的时候，这些问题对于整个团队将会产生巨大的压力和高昂的代价。
在软件开发的项目进度估算过程，大多数时候仅仅凭借项目经理的直觉进行判断，当客户给予的压力过大时，项目经理极其容易做出不合理的项目进度安排。
在项目进行过程中，如果发生进度落后的情况，项目经理难免会下意识的增加项目人手，但是，增加项目人数会带来培训，交流的额外时间消耗，进而很可能造成“Adding manpower to a late software project make it later”的可怕状态，抑或是项目经理只能临时减少项目中的任务，已完成项目进度。
综上，项目开发过程中，缺乏合理的项目进度安排极可能造成项目的滞后，因此在项目开始前，就要对项目进度，项目工作量进行合理的计算，并未项目最终的系统测试留下充裕的时间，保证项目的容错性。

外科手术队伍

1. 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，Sackman和Humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。

2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。

3. 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。

4. 对于真正意义上的大型系统，小型精干的队伍太慢了。

5. 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。

6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

贵族专制、民主政治和系统设计

1. 概念完整性是系统设计中最重要的考虑因素。

2. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

5. 体系结构、设计实现、物理实现的许多工作可以并发进行。

未雨绸缪

1. 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

2. 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

3. 软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。

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

5. 对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。

6. 维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。

7. Campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。

8. 缺陷修复总会以（20－50）%的机率引入新的bug。

9. 在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。

10. 同样，设计实现的人员越少、接口越少，产生的错误也就越少。

11. 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程。

胸有成竹

1. 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。

2. 构建独立小型程序的数据不适用于编程系统项目。

3. 程序开发与程序规模成指数增长趋势。

4. 当使用适当的高级语言时，程序编制的生产率可以提高5倍。