第12章 干将莫邪
项目经理应该制订一套策略，以及为通用工具的开发分配资源，与此同时，他还必须意识到专业工具的需求。
尽管技术不断变化，采用时间块来安排匮乏计算机资源的方式仍得以延续（20年）1975年，是因为它的生产效率最高（1995年）。（现在都2014年了….）
在编制程序的项目中，节省最大工作量的工具可能是文本编辑系统。（为毛线是文本编辑系统？）
交互式编程
某些应用上，批处理系统绝不会被交互式系统所替代
调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。（自动化测试）
有限的数据表明了系统软件开发中，交互式编程的生产率至少是原来的2倍。
第13章 整体部分
许许多多的失败完全源于那些产品未精确定义的地方。
在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明完整性和明确性。开发人员自己不会完成这项工作。（策划提需求详细地描述功能完整性和明确性，但开发应该根据自己的理解提出更合适的开发方案以及学会拒绝不合理的需求。）
有时必须回退，推翻顶层设计，重新开始。（也许开发的过程中会发现设计有问题，但是根据情况和时间决定是否先完成版本需求，之后再改进；还是果断放弃，重新用更靠谱的方案。这也说明靠谱的方案比编码更重要。git版本控制让回退更容易调整）
系统调试仅仅应该在所有部件能够运作之后开始。
必须有人对变更进行控制和文档化。（git是很好地变更控制工具，而git wiki是很好的文档工具）
第14章 祸起萧墙
项目是怎样延迟了整整一年的时间？..一次一天
一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥补（将开发目标版本，不断重新审视，可以发现很多问题和防范很多问题）
对于大型项目，一个对里程碑报告进行维护的计划和控制小组是非常可贵的。
里程碑还是沉重的负担？
如果根据一个严格的进度表来控制项目？
第一个步骤是制订进度表。进度表上的每一件事，被称为“里程碑”。
里程碑必须是具体的、特定的。可度量的事件，能够清晰定义。
反面例子：
例如编码，在代码编写时间达到一半的时候就已经“90%”完成了；调试在大多时候都是“99%完成”的；计划完毕是任何人只有愿意，就可以声明的事件。
然而，具体的里程碑是百分之百的事件。
必须关心每一天的滞后，它们是大灾祸的基本组成元素。
第15章 另外一面
不了解，就无法真正拥有
公共应用程序在用户的时间和空间上都远离它们的作者，对这类程序，文档的重要性更少不言而喻！
我想他们知道如何正确地编写文档，却缺乏工作的热情。
如何做（才能产生一篇优秀的文档）
有用的文字描述
-
目的。主要的功能是什么？开发的原因是什么？
-
环境。运行在什么样的机器、硬件配置和操作系统上？
-
范围。输入的有效范围是什么？允许显示的合法范围是什么？
-
实现功能和使用的算法。精确地阐述它做了什么。
-
输入-输出格式。必须是确切和完整的。
-
操作指令。包括控制台及输出内容正常和异常结束的行为。
-
选项。用户的功能选项有哪些？如何在选项之间进行挑选？
-
运行时间。在指定的配置下，解决待定规模问题所需要的时间？
-
精度和校验。期望结果的精确程度？如何进行精度的检测？
流程图
流程图的作用是吹出来的（事实上觉得思维导图比文字更形象地表达一个系统的设计）
自文档化
注释或者程序自己解释自己