再结束了第一个个人任务以后，我也算有点时间翻开一本大部头来通读一下。在看了一些相关的评论说：“该书可以从任意章节读起”后，刚刚在180M测试文件的个人任务中吃了亏的我，决定从他的第5部分，代码改善看起，大致将感想记录如下。
首先是张图片，的确很符合一贯的认识，没有一个软件在每一方面中做到尽善尽美。我们能够做的是，根据每个软件的不同需求，在功能上做出不同的侧重。对于外部的交互部分，健壮性至关重要，而对于最核心的计算，效率则是需要优先考虑的。
其次是质量保证，文中提出了多种缺陷检测方式，从简单的单元测试到正式的代码复查，列出了一个表格。其后详细讨论了缺陷的成本问题，包括找出与修正所花费的成本，结论告诉我们这个会占据开发流程中相当一部分的精力。后续又紧接着提出了一个问题，就是什么时候进行质量保证工作。众所周知，如果在最后阶段发现致命问题，需要对整个代码大改，这是无法接受的。所以书中说到，要在早期阶段就开始强调质量保证，一步一步稳扎稳打，在开工之时就添加到计划中。
第21章 协同构建
可以说这一章刚好在讲述我们这周要做的事情，也就是结对编程。书中先提出，这一行为目的是为了改善软件的质量，用很多公司的例子与调查报告告诉我们，在合理的质量检测能够既减少缺陷也缩短开发周期。
其次对于结对编程的好处做出了充分的阐述：
可见，结对编程并不是一个玩乐的方式，而是切实有效的。
协同除了两人的结对编程，还有一个团体的协同，具体表现为正式检查，每个参与者以明确的角色去对代码仅检查。数据现实，这样的方式检出的缺陷仅少于原型和大规模 beta 测试，推荐的人数一般是6人，可以说是一种十分经济适用的方法了。
而且该方法由于有标准的核对表和标准的角色，是一个系统化过程，也可自我优化。采用了正式的反馈循环来改进核对表，无论开始时状况如何，都能够不断优化，最终起到很好的效果。
