过去是怎么做的：
我总是写完全部的代码再进行测试。
为什么这样不好：
如果bug很多，就会导致最后的提交时刻，要一次次的重复查找bug并解决，甚至推翻重写代码，这是致命且让人感到十分枯燥的。
解决办法：
最好按照书中的编程习惯，制定一个恰当的解决测试办法和时间进度安排，避免出现最后时刻才测试的状况，尤其在大课堂测试中，如果一直写代码而不测试，很容易最后一堆bug且无时间解决。
具体读后感：
人月神话：
造成项目滞后的最主要原因，缺乏合理的时间进度。导致这种灾难原因：
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
乐观主义：
无论是什么样的程序，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”
系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
创造性活动的三个阶段：构思、实现和交流。
构思：书籍、计算机、或者程序的出现，首先是作为一个构思或模型出现在作者的脑海中，它与时间和空间无关。
实现：接着，借助钢笔、墨水和纸，或者电线、硅片和铁氧体，在现实的时间和空间中实现它们。
交流：然后，当某人阅读书本、使用计算机和运行程序的时候，他与作者的思想相互沟通，从而创作过程得以结束。
人月：
错误的思考方式之二：在估计和进度安排中使用的工作量单位：人月。
用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
系统测试：
顺序限制导致时间进度缓慢，其中单元测试与系统测试更有限制力。
经验法则：
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
系统测试必须安排足够时间。
空泛的估算：
某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。
我们需要两种解决方案：开发并推行生产率图表、缺陷率、估算规则等；基于可靠基础的估算出现之前，项目经理坚持估计，确信自己的经验和直觉总比从期望派生出的结果要强得多。
重复产生的进度灾难：
向进度落后的项目中增加人手，只会使进度更加落后。
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。