第8章 胸有成竹
系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？
编码大约只占了问题的1/6，编码估计或者比率的错误可能会导致不合理的混缪结果。（程序员大部分时间在思考，而思考是不可见的。实际上我思考了两天的时间，最终完成功能的编码时间却只有一个小时）
构建小型程序的数据不适用于编程系统产品。
原文有关于编程数据的分析，最终的结论
-
对常用的编程语句而已。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。
-
使用适当的高级语言，编程的生产率可以提高5倍。
第9章 削足适履 Ten Pounds in a Five-Pound Sack
他应该瞪大眼睛盯着诺亚，….好好学习，看他们是怎样把那么多东西装到一个小小的方舟上的。
作为成本的程序空间
程序有多大？除了运行时间以外，它所占据的空间也是主要开销。
没有人可以自始至终提倡更紧密的软硬件设计集成的同时，仅仅就规模本身对软件系统提出批评。
开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设计元器件数量目标，控制元器件数量。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
规模控制
对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和他们的应用，以设置将开发系统规模。接着，将这些系统划分成若干部分，并设定每个部分的规模目标。
空间技能
第一个技巧：用功能交换尺寸。程序可以有很多选择，每个功能仅占用少量的空间。也可以设计成拥有若干选项分组，根据选项组来剪裁程序。
很难用小型系统的模块构造出非常高效的系统
第二个技能是考虑空间——时间的折衷。对于给点的功能，空间越多，速度越快。
另外一种方法是认识到编程需要技术积累，需要开发很多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或宏库。对于每项功能，库至少有两个程序实现：运行速度较快和短小精炼的。
公共库开发可以与系统设计工作并行进行。
数据的表现形式是编程的根本
第10章 提纲挈领
前提
在一片文件的汪洋中，少数文档形成了关键的枢纽，每件项目管理的工作都围绕着他们运转。他们是经理们的主要个人工具。
计算机产品的文档
目标：定义待满足的目标和需要，定义迫切需要的资源、约束和优先级。
技术说明：计算机手册和性能规格说明。计划产品时第一个产生，并且最后一个完成的问文档。
进度：时间表
预算：预算会迫使技术决策的制订。
组织机构图
工作空间的分配
软件项目的文档
做什么：目标
做什么：产品技术说明
时间：进度表
资金：预算
地点：工作空间分配
人员：组织图
如果系统设计能自由地变化，则项目组织架构必须为变化做准备。
为什么要有正式的文档？
-
书面记录决策是必要的
-
文档能作为同其他人的沟通渠道
-
项目经理的文档可以作为数据基础和检查列表
项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队的范围内得到交流。
第11章 未雨绸缪
普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。
化学工程师已经认识到无法一步将实验室工作台上的反应过程移到工厂中，需要一个实验性工厂来为提高产量和缺乏保护的环境下运作提供宝贵的经验。
对于大多数项目，第一个开发的系统并不合用、它可能太慢、太大，而且难以使用，或者三者兼而有之。（渐渐地发现，过一段时间，对自己开发的系统越来越不满意，认为系统本来应该可以可读性更强，可维护性更好，可扩展性更好才是）
系统的丢弃和重新设计可以一步完成，也可以一块块完成。这是个必须的过程。
将开发的第一个系统——丢弃原型——发布给用户，可以获得时间，但是它代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力4；对于产品，影响了声誉，即使再好的设计也难以挽回名声。
为舍弃而计划，无论如何，你一定要这样做。（也许开始总避免不了舍弃，技术的发展超出了想象）
用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的变更（今天看到一句话，说程序20%时间开发，80%时间维护，而维护的时间大部分便是花在了需求变更上）
目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现好得多。（随着业务的发展，系统必然是逐步复杂，功能扩展和变化也就无可避免，事先想法可能发展的目标，预留更多扩展的可能性总能带来更多的便利）
采用定义良好的数字版本将变更量子（阶段）化。（每周的开发任务作为一个版本，不断量化细化阶段目标，更清楚自己做了什么和将要做什么）
程序员不愿意为设计书写文档的原因，不仅仅由于惰性。更多地是源于设计人员的踌躇——要为自己的尝试性设计决策进行辩解。
前进一步，后退一步——程序维护
程序维护基本上不同于硬件维护；它主要由各种变更组成，如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整。（重构代码设计，封装代码，补充注释，完善问答，新增功能，调整配置，代码组织方式变更..）
维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。
缺陷修复总会以（20-50%）的概率引入新bug
在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏（自动化测试的好处是每次修复之后自动测试用例，而不必手动重复，当然写测试用例也是麻烦的事情）
系统熵随时间增加
所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。软件维护工作，也只是放缓了系统退化到不可修复混乱的进程，从中必须重新进行设计。（什么时候重构？允许的情况下修改的时候重构）