随着软体工程知识的普及，软体工程师都知道，要开发高质量的软体，必须改进软体生产的过程。目前，业界公认由CMU/SEI开发的软体能力成熟度模型SW-CMM是当前最好的软体过程，并且CMM已经成为事实上的软体过程工业标準。但是，CMM虽然提供了一个有力的软体过程改进框架，却只告诉我们"应该做什幺"，而没有告诉我们"应该怎样做"，并未提供有关实现关键过程域所需要的具体知识和技能。为了弥补这个欠缺，Humphrey又主持开发了个体软体过程(Personal Software Process，PSP)。

在CMM1.1版本的18个关键过程域中有12个与PSP有关，据统计，软体项目开发成本的70%取决于软体开发人员个人的技能、经验和工作习惯。因此，一个单位的软体开发人员如能接受PSP培训，对该单位软体能力成熟度的升级是一个有力的保证。CMM侧重于软体企业中有关软体过程的巨观管理，面向软体开发单位，PSP则侧重于企业中有关软体过程的微观最佳化，面向软体开发人员。二者互相支持，互相补充，缺一不可。

PSP过程改进模型

按照PSP规程，改进软体过程的步骤首先需要明确质量目标，也就是软体将要在功能和性能上满足的要求和用户潜在的需求。接着就是度量产品质量，有了目标还不行，目标只是一个原则性的东西，还不便于实际操作和判断，因此，必须对目标进行分解和度量，使软体质量能够"测量"。然后就是理解当前过程，查找问题，并对过程进行调整。最后套用调整后的过程，度量实践结果，将结果与目标做比较，找出差距，分析原因，对软体过程进行持续改进。

就象CMM为软体企业的能力提供一个阶梯式的进化框架一样，PSP为个体的能力也提供了一个阶梯式的进化框架，以循序渐进的方法介绍过程的概念，每一级别都包含了更低一级别中的所有元素，并增加了新的元素。这个进化框架是学习PSP过程基本概念的好方法，它赋予软体人员度量和分析工具，使其清楚地认识到自己的表现和潜力，从而可以提高自己的技能和水平。

PSP0的目的是建立个体过程基线，通过这一步，学会使用PSP的各种表格採集过程的有关数据，此时执行的是该软体开发单位的当前过程，通常包括计画、开发（包括设计、编码、编译和测试）以及后置处理三个阶段，并要作一些必要的试题，如测定软体开发时间，按照选定的缺陷类型标準、度量引入的缺陷个数和排除的缺陷个数等，用作为测量在PSP的过程中进步的基準。

CMM/TSP/PSP关係模型

PSP0.1增加了编码标準、程式规模度量和过程改善建议等三个关键过程域，其中过程改善建议表格用于随时记录过程中存在的问题、解决问题的措施以及改进过程的方法，以提高软体开发人员的质量意识和过程意识。

应该强调指出，在PSP0阶段必须理解和学会使用表格进行规划和度量的技术??经验，以準确地满足期望的需求，其中最重要的是要保持数据的一致性、有用性和简洁性。

PSP1的重点是个体计画，引入了基于估计的计画方法PROBE（PROxy Based Estimating），用自己的历史数据来预测新程式的大小和需要的开发时间，并使用线性回归方法计算估计参数，确定置信区间以评价预测的可信程度。PSP1.1增加了对任务和进度的规划。

PSP计画示意图

在PSP1阶段应该学会编制项目开发计画，这不仅对承担大型软体的开发十分重要，即使是开发小型软体也必不可少。因为，只有对自己的能力有客观的评价，才能作出更加準确的计画，才能实事求是地接受和完成客户（顾客）委託的任务。

PSP2的重点是个体质量管理，根据程式的缺陷善建立检测表，按照检测表进行设计複查和代码複查（有时也称"代码走查"），以便及早发现缺陷，使修复缺陷的代价最小。随着个人经验和技术的积累，还应学会怎样改进检测表以适应自己的要求。PSP2.1则论述设计过程和设计模板，介绍设计方法，并提供了设计模板、但PSP并不强调选用什幺设计方法，而强调设计完备性準则和设计验证技术。

实施PSP的一个重要目标就是学会在开发软体的早期实际地、客观地处理由于人们的疏忽所造成的程式缺陷问题。人们都期盼获得高质量的软体，但是只有高素质的软体开发人员并遵循合适的软体过程，才能开发出高质量的软体，因此，PSP2引入并着重强调设计複查和代码複查技术，一个合格的软体开发人员必须掌握这两项基本技术。

PSP3的目标是把个体开发小程式所能达到的生产效率和生产质量，延伸到大型程式；其方法是採用螺旋式上升过程，即叠代增量式开发方法，首先把大型程式分解成小的模组，然后对每个模组按照PSP2.1所描述的过程进行开发，最后把这些模组逐步集成为完整的软体产品。

套用PSP3开发大型软体系统，必须採用增量式开发方法，并要求每一个增量都具有很高的质量。在这样的前提下，在新一轮开发循环中，可以採用回归测试的方法，集中力量考察新增加的这个（这些）增量是否符合要求。因此，要求在PSP2中进行严格的设计複查和代码複查，并在PSP2.1中努力遵循设计结束準则。

从对个体软体过程框架的概要描述中，可以清楚地看到，如何作好项目规划和如何保证产品质量，是任何软体开发过程中最基本的问题。

PSP可以帮助软体工程师在个人的基础上运用过程的原则，藉助于PSP提供的一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的评估、计画和预测更加準确、更加有效，进而改进个人的工作表现，提高个人的工作质量和产量，积极而有效地参与高级管理人员和过程人员推动的组织範围的软体工程过程改进。

PSP软体工程规程为软体工程师提供了发展个人技能的结构化框架和必须掌握的方法。在软体行业，开发人员如果不经过PSP培训，就只能靠在开发中通过实践逐步掌握这些技能和方法，这不仅周期很长，要付出很大的代价，而且有越来越大的风险。 培训的方式有很多，既可以到专门的学校进修，也可以进行自学和参加培训班，例如：CMM网校中就有个体软体过程的课程。

PSP是一个需要逐步改进的过程。

Watts S. Humphrey服兵役的时候，必须学会机枪射击。开始训练时用猎枪打泥鸽子，Watts的成绩非常差，并且努力训练还是没有提高。教官对Watts进行了一段观察后，建议他用左手射击。作为一个习惯右手的人，开始Watts很不习惯，但练了几次后，Watts的成绩几乎总是接近优秀。

这个事例说明了几个问题。首先，要通过测量来诊断一个问题，通过了解Watts击中了几只鸽子和脱靶的情况，很容易看出必须对Watts做些调整。然后，必须客观的分析测量的数据，通过观察Watts的射击，教官就可以分析Watts射击的过程—上膛、就位、跟蹤目标、瞄準，最后射击。教官的目的就是发现Watts哪些步骤存在问题，找到问题所在，于是建议目的就是发现用左手射击。

最后，也是最重要的，就是自身的变化。过程改进是非常困难的，因为人们很多时候不愿意尝试新事物。他们传统的习惯看起来很自然，以至于不相信改变会有什幺帮助。Watts总是使用右手，从来没有想过左手射击会是什幺样子。但是自Watts採纳了教官的建议，他的成绩就提高了。

定义测量方法不是件容易的事情，但它总是可能的。首先定义测量方法。规定了测量方法后，就必须收集和分析数据。如果需要作些改进，接下来就要分析工作过程，看看什幺地方需要改进。最后要想真正的改进，必须切实做出改进。

如果Watts不改进他的射击过程，它的成绩几年后都不会有什幺变化，也不会成为一个优秀的枪手。仅仅进行测量并不会产生什幺提高，仅仅靠努力也不会有什幺提高。在很大程度上工作方式决定了所得到的结果。如果还是按照老办法工作，得到的结果还会是老样子。

改进工作方式与Watts学习射击的步骤一样。它们并不複杂，如图1所示：

人们很可能像上星期那样安排这星期的时间。当然，随着工作的不同，也有很多例外的情况。

为了制定切实可行的计画，必须对所用的时间进行跟蹤。如果问上周的时间是怎幺利用的，一般人都认为很容易所出每项工作花了多少时间，但是当看到实际的数据时，很可能感到十分惊讶：花在编程上的时间比估计的少得多，花在消遣的时间比预期的多得多；乐意做的事情做的特别快，用的时间也似乎特别少，令人头疼的事情占用的时间似乎比实际花费的时间多得多。要搞清楚时间都用在什幺地方，必须对时间进行跟蹤，保留一份準确的记录。

为了检查时间估计和计画的準确性，必须把它们写成文档并在今后与实际情况进行比较。做计画是一种技能，学习制定好的计画，第一步就是要先做计画，然后把该计画写下来，以便今后与实际数据相比较。

为了制定出更準确的计画，需要知道以前的计画中存在哪些错误，哪些地方可以进行改进。当按照计画进行工作时，记录下所花费的时间。通过比较文档化的计画和实际的结果，就可以发现计画中存在哪些错误以及如何改进做计画的过程。制定準确计画的关键就??较，然后就会知道如何才能制定出更好的计画。

为了管理好时间，首先制定时间分配计画，然后按照计画去做。製作计画容易，但真正实施计画是困难的。特别开始的时候，按照计画进行工作可能比较困难，你可能会有很多藉口，最常见的就是这份计画製作的不好。但只有按照计画去做，你才能知道它的优劣。

按照计画进行工作有三点好处：第一，了解计画存在哪些问题，有助于更好的计画下一个项目。第二，按照好的计画完成工作。这看起来不重要，但是事实上软体工程中的许多错误都是由于考虑不周、粗心大意或是不注意的小细节而造成的，按照好的计画工作是避免这些错误的最好途径。另一个更加微妙的好处就是它实际上在改变你的工作方式，有了计画就不用浪费时间去考虑下一步要乾什幺，它会帮助你把精力集中在所中的事情上，很少分心，从而提高了工作效率。

将主要活动分类。在开始分配时间时，你会发现大部分时间都用在相对很少的几个活动上。

记录每项主要活动所花费的时间。坚持记录时间需要很强的自我约束能力，要想进行精确的记录，必须记录下每件主要工作开始和结束的时间。除非你知道自己实际上用了多少时间，否则就不可能管理好使用时间的方式。

用标準的方法记录时间。必须使用标準的时间日誌。因为需要採集的时间数据的数量增加得很快，如果不认真记录和存储这些数据，它们很可能丢失或变得混乱，这样很不利于查找或对它们进行解释。如果不打算对这些数据进行适当的整理、归纳，就根本不必要去收集数据。

以分钟为测量单位。工程是在完成任务中不间断工作的时间一般都少于1小时，因此以小时为单位对工作时间进行测量不能提供用以计画和管理工作所需要的详细数据，而用分钟跟蹤时间容易得多。一旦决定进行时间跟蹤，用分钟作为测量单位将比用小时更恰当。

表2.1——了解时间的使用情况

处理中断时间。採用表2.1跟蹤时间时，一个常见的问题就是中断。电话、聊天、偶尔的烦恼以及必要的休息打断的次数多得令人吃惊。中断的时间不是有效的工作时间，并且变化幅度很大，如果不对它进行测量，实际上就在时间记录中加入了一个随机数，也就很难使用时间数据来计画和管理时间了。事件日誌中的数据能帮助你了解工作被打断的频率。多数中断不仅浪费时间，还会打断你的思路，导致效率降低和错误的产生，因此了解被打断的频率有助于提高工作的质量和效率。

将时间数据保存在合适的地方。记录时间花费情况值得推荐的方法就是用工程记事本来记录时间以及其他的事情。对一个软体专业人员，工程记事本用途很多，可以记录时间日誌、程式设计方案以及运算结果，可以作为你所遵循正确的工程实施方案的凭证，可以记录下脑子里面一闪而过的想法。推荐的方法是从工程记事本的第一页开始向后记录主要活动及其所花费的时间，最后一页开始向前记录时间日誌。记录主要活动及其所花费的时间，最后一页开始向前记录时间日誌。

周活动总结表。通过採用时间日誌收集时间数据后，你就能渐渐明白自己是如何支配时间的。但是时间日誌中的数据过于详细，需要用一种更有用的表格来总结这些数据，周活动总结表能够很好的完成这个任务。当然我们关心的时间不会只有一周这幺短，还需要一段时间内在各类任务上花费的平均时间、最大时间和最小时间。因此採用表2.2所示格式。周活动总结表中的数据可以帮助你了解时间都用在那些地方，还可以使用这些书对以后的几周进行计画。例如，有了这些数据就能判断出一个大的任务所需要的时间可能接近总结表中的最长时间，而一个简单的任务需要的时间可能接近最短时间。

记录时间的提示。随时準备好工程记事本；当偶尔忘了记录开始时间、结束事件或中断时间，凭记忆儘早作出估计；及时总结记录的时间数据。

这里介绍两种计画：阶段计画和产品计画。阶段计画是关于这段时间内对时间的安排，产品计画是关于製作产品活动期间的时间安排。以读一本书为例来说明阶段计画和产品计画的区别。为了计画这项工作，首先估计出整个任务应花费多少时间。例如，你可能希望用20小时阅读全书20章的内容。对于这个任务来说，产品计画就是以20小时读完全部书为目标，阶段计画就是每周安排1小时读书这种方式。下图表示了业务领域中产品计画和阶段计画的关係。

为了制定阶段计画，必须清楚时间的使用情况。根据上一章介绍的周活动总结表，我们就可以跟蹤记录自己是如何支配时间的。在制订下一周的计画时，就可以参考最近的周活动总结表。根据以前各个任务花费的时间，就能判断出下一周将在这些任务上花费多少时间。制定这种计画最简单的方法就是假设将要使用的时间与过去平均使用的时间相同。一种较为精确的方法就是首先考虑下周将要做的工作内容，然后根据以前的最长和最短时间来估计出一个合适的时间。

当工程师在项目小组中工作时，就需要计画个人的工作。计画是按期完成承诺的任务的可靠基础，可以在工程师合作开发产品过程中协调他们的工作，可以帮助工程师了解项目的状态。做计画是软体工程师工作的一个重要部分，要成为一个有才干的工程师，就必须知道如何制订準确的计画，也需要知道如何将这些计画与实际结果相比较，从而学会制定更好的计画。

制定产品计画是可以通过事件加以提高的一种技能。从现在开始对每个产品制订计画，产品可以是一个可制定的程式、一个程式设计方案或是一个测试计画，并在以后的项目中继续这样做下去。

收集历史项目数据。对于工程人员，一个产品计画包含产品规模、工作时间和进度三方面的估计。最基本的产品计画只包括对任务或作业所需时间的估计。通过收集以前不同任务所用时间的数据，就能够估计将来类似的任务大概所需要的时间。表3.1是为了记录每个项目估计时间和实际时间而设计的作业编号日誌，参考这些历史项目数据，我们可以方便、準确地作出估计。準确的估计是做好计画的关键。

表3.1——制定产品计画

估算程式规模。产品计画的第一步是要估计产品的规模。对于程式来说，可以使用代码行测量方法估计新程式的规模。为了準确的估计，需要用到以前的规模数据，因此把以前的规模数据按照功能分类是有帮助的。首先查看新程式的需求，估计各类代码有多少行，然后与以前统计的数字进行比较，可以得出开发新程式需要多少时间完成。随着所积累的数据越来越多，作出的估计就会越来越準确。作业编号日誌作为记录大量的历史的规模和效率数据提供了一种简便的方法，还可以使用表3.2记录不功能类型的程式历史数据，并按照规模排列。

表3.2——制定产品计画

规模测量的方法很多，应该根据不同的对象使用不同的估计方法，即使对程式来说，代码行测量方法也不能覆盖所有的情况。没有任何方法可以保证估计的结果一定準确，作出好的规模估计的关键是要有大量的历史数据，要进行多次规模估计，并且要定期的将实际结果与估计值进行比较。

可以按照如下步骤管理时间：

1. 分析自己使用时间的历史记录；

2. 制定时间安排表，决定如何使用时间；

3. 对照制定的安排表跟蹤使用时间的方式；

4. 决定应该改变什幺意思自己的行动达到所作安排的要求。

複查时间的分类情况。周活动总结表给出了每周用在各个活动上的平均时间、最大时间和最小时间。检查一下这些活动的分类，是否有些类别包含的範围过大了，而另一些有分得过细。时间管理的重点放在那些站用大部分时间的少数几项活动上。

作出时间安排。时间安排表是如何使用时间的计画，根据以前如何使用时间的数据，就可以作出计画，分配以后活动所需要的时间，如表3.3所示。

找出更多的时间。管理好时间的关键是逐步对使用时间的方式进行反覆平衡，因为时间每天24小时是固定的。如果希望以后在某些任务多用一些时间，除非能够在另外一些任务中少用一些时间，否则，这常常只是一个愿望而已。

制定基本规则。我们在做许多事情是都是按照一定的规则去做的。为了对时间进行有效管理，也需要有规则可循。不同的是前些规则是别人製作的，而时间管理必须自己制定这些规则。实际上，时间管理的安排就是为管理自己的时间而制定的规则。时间管理的基本规则：已经决定如何使用时间，就必须切实的按照预定的方式去做；为了切实按照预定的安排去做，就必须有非常具体的计画。表3.4就是位置到每天活动制定的每天时间安排表。

表3.4——每天时间安排表

设定时间分配的优先权。有些时间是固定不点的，如每周例会，可以把这些时间称为固定时间。进行其他活动的时间就是可变动的时间，只要有时间就可以去做这些活动。可变时间又分成需要完成的任务和自行斟酌的任务。需要的活动如编程、读书，虽然是需要的活动，但它们的时间是可变动的，因为无论如何找出时间都可做这些事情，并且每周在这些活动上所用的时间是不同的。自行斟酌的活动就是要做的所有其他的事情：吃饭、睡觉、社交、观看电视及其其他的娱乐活动。

当作出全面的时间安排时，固定时间的安排是没有什幺问题，最常见的问题是分配可变动的时间。列出需要儘快做的事情，首先努力完成最重要的任务。重要的任务推此时，你会不自觉的为这些任务担心，立刻处理这些事情常常是更有效的，并且也将给人们带来一种完成任务的成就感。此外，记住一旦开始了一项令人生畏的任务，就很少会感到象你想像中的那幺困难。

可以考虑从自行斟酌的活动中抽出那些额外的时间，但是这需要合理的安排，对个人是否真愿意按照这时间安排来执行。没有休息的时间会导致人们将管理好时间的想法推翻。做时间安排以及跟蹤时间是重要的，但是时间安排一定要是自己实际愿意接受的。

执行时间安排表。按照时间安排表工作的能力很大程度上取决于个人的自觉性，但是它还取决于要做的工作的数量和它们的优先次序。预料不到的时间是生活中很自然并且是很正常的一部分，特别是在软体工程中。危机常常会打破人们的计画，因此不得不作出调整。

在第一次使用时间安排表时，可能会感到它不是很有用，这是正常的，不要因为第一次没有起作用就放弃对时间安排的过程，而是要考虑所发生的事情，看看是否存在一些不可能再发生的反常时间、或者存在对有正常事件引起人而意外花费了很多时间？如果是紧急的情况，不必对时间安排做大的调整，下一周再试着用它，然后複查结果。如果一些经常发生的事情扰乱了安排，应考虑对安排进行改动，为以后类似事情提前做好準备。

最后，按照时间安排表跟蹤实施的性能，要继续收集时间数据。根据经验複查时间安排表，在根据需要和经验修改安排，要逐步的作出改变。在改变时间安排表时，要保存以前的版本。

时间管理的目标。收集时间是为了帮助自己管理时间。如果收集的数据被证明是没有用的，就需要重新考虑自己收集时间数据的方法。但是，只有在已经实践了安排的时间之后再这样做。记事作了时间安排表，如果由于一些原因对时间安排变化很大，那幺也应该收集更多的数据，知道自己明白当前是如何使用时间为止。

缺陷是指程式中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程式语句，是任何影响程式完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。

有人把缺陷称为Bug，这是不正确的。当成为Bug时，令人想到的是那些令人讨厌的小虫子，应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事，会养成一种错误的态度。缺陷并不像无足轻重的Bug，更像是定时炸弹。大家可能会觉得有些夸大其词，绝大部分细小的缺陷没有引起严重后果。然而不幸的是，很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题，但很快就会成为一个重要的问题。

设计错误的複杂性和所导致的缺陷的影响没有直接关係，一些微小的编码错误却可能引起严重的系统问题。事实上，绝大多数软体缺陷都源于程式设计师的疏忽大意。

为了减小缺陷，就必须进行缺陷管理，研究已经引入的缺陷，确定引起这些缺陷的原因，并学会在将来如何避免重複同样的错误。

缺陷分类。在分析缺陷时，将缺陷进行分类是有帮助的。通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上，一旦这几类缺陷得到控制，在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。

表4.1——缺陷分类

不要急于把10种类型的每一类细分出若干子类，直到你已经蒐集到大量程式的缺陷数据。那时，才能够看出哪里需要更详细以及补充什幺样的信息才是最有用的。

统计缺陷个数。採用缺陷记录日誌，记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解，但是要管理好缺陷，就必须收集有关缺陷的準确数据。如果原谅缺陷，那只会自欺欺人。如果你这样做的话，就别指望有所提高。

为什幺要儘早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程式，经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程式，它将永远是有缺陷的。虽然你可以修复所有已知的问题，并且让它通过所有的测试，但它还是一个有许多不定的有缺陷的程式。如果工程师能宽容有缺陷的工作，他将生产出低质量的产品。“我们忙，以后在修补吧”，这样的态度不可能出产出优质产品。

发现和修复缺陷的费用。在典型项目中，产品被分成很多小的模组，由不通的工程师负责开发。在模组设计、实现、编译后，工程师作初始的单元测试；单元测试后，多个模组组成一些大组件进行集成测试；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行系统测试。随着系统的规模和複杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、複杂程度有所不同，但几乎所有规模的软体产品，都需要这个过程。

研究证明，开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍。儘管缺陷的修复时间变化很大，但平均时间总是遵循这样的规律，而与缺陷的类型无关。

发现和修复缺陷的方法。儘管没有办法不引入缺陷，但是在开发过程中儘早发现和修复缺陷还是可能的。有多种发现程式中的缺陷的方法，基本上都包括以下步骤：表示缺陷徵兆；从徵兆中推断出缺陷的位置；确定程式中的错误；决定如何修复缺陷；修复缺陷；验证这个修复是否已经解决了这个问题。

有多种工具和辅助手段来帮助完成这些步骤，工程师最常用的工具是编译器，它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码，并且可能会在源程式有缺陷的情况下生成代码。因此，不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的徵兆，你必须自己对问题定位，并确定是什幺问题，通常很快能够做到这一点，但偶尔也需要较长的时间

另外一种常用方法就是上面讲述的测试。测试的质量是由测试用例覆盖所有程式功能的程度决定的。测试可以用来验证程式几乎所有的功能，但有自己的缺点：同编译器一样只能满足缺陷派出的第一个步骤，你仍必须从缺陷徵兆找出问题的根源，然后才能修复；随着项目规模的扩大，全面的测试会花费大量的时间，要进行完全测试几乎不可能的。

最有效的发现和修复缺陷的方法是个人複查源程式清单。这种方法是负很难彻底清除程式中的缺陷，但事实证明，这是最快而且最有效的方法。

代码複查就是研究原始码，并从中发现错误。代码複查更有效的原因是：在複查时看到的是问题本身而不是徵兆。从头到尾複查代码时，考虑的是程式应该做什幺。因此，当看到某些地方不正确时，就可以看到可能的问题是什幺，并立即去验证代码。複查的缺点是：非常耗时，而且很难恰当的进行；複查时一种技能，当然可以通过学习和实践来提高。

代码複查的第一步是了解自己引入的缺陷的种类，这是收集缺陷数据的主要原因。因为在下一个程式中引入的缺陷种类一般会与前面的基本类似，只要採用同样的软体开发方法，情况会一直如此。另一方面来说，当你有了技能和经验或改变了过程，缺陷的类型和数目会随之变化。但是到了一定程度后，改进就变得非常困难了。这是，就必须研究缺陷，这可以帮助你找到更好的发现和修复缺陷的方法。

如何进行代码複查。代码複查的目标是在软体过程中儘可能早和儘可能多的发现缺陷，缺陷发现时间越少越好。採用表4.3描述的一个有序的检查方法，在编译之前进行代码複查，是完成目标最好的方法。

表4.3——代码複查

编译之前进行複查。有几个原因说明应在编译之前进行代码複查：不论编译前或编译后，进行完整的代码複查的时间大约相同；不论编译前或编译后，对检查语法有效性的效果是一样的；先做複查将节省大量编译时间，若不做代码複查，一般要花12%～15%的开发时间进行编译，一旦使用代码複查后，编译时间可以缩短至3%或更少；编译程式后，代码一般複查很难彻底的进行； 经验证明，在编译阶段有大量的缺陷时，一般在测试阶段也有许多缺陷。

建立个人代码複查检查表。如果想发现和改正程式中的每一个缺陷，就必须遵照一个精确的规程。检查表可以确保遵循这个规程，它包括一系列程式的步骤。按照检查表去作时，就知道如何进行代码複查。

如果能够正确使用检查表，还能知道每个步骤发现了多少缺陷。这样就能测量出複查过程的效率，并进一步改进检查表。检查表包括了个人的经验。通过不断的使用和改进个人检查表，就可以帮助你用较少的时间发现这些缺陷。表4.4是一个C++程式代码複查表的範例。

定期更新检查表。随着时间的推移，检查表自然的要变大。但是，检查表的主要作用是帮助你把注意力集中在关键的方面。太大以后，你将失去重点。所以要定期複查缺陷数据，删除那些不能找到问题的表项。

从个人检查表的方法可以认识到，每个工程师都有各自的特点，某个工程师的实践经验对别人不一定适用。因而要设计出适合自己的检查表，并定期的对它进行检查以保证检查表更有效。只要你在代码複查中还遗漏缺陷，就要不断寻找改进检查表的方法。

进展是很缓慢的。最初，你发现缺陷的能力随着每次複查都有所提高。此后，提高将变得很困难。要坚持收集和分析缺陷数据，并坚持思考如何才能预防缺陷的产生或怎样更好的找到缺陷。只要坚持不断的做下去，就能在代码複查中不断进步，不断提高自己编写程式的质量。

编码标準。编码标準是被广泛接受的、能够作为工作样板的编码实践集。良好的编码标準将有效地帮助您避免开发有潜在危险的代码，有助于预防缺陷。例如，可以在编码标準中列出那些应该避免使用的方法，规定号循环入口或在说明是初始化变数，避免不良的变数命名等。编码标準还能有效地统一和规範整体开发活动。当其他开发人员加入到项目中来时，他们能够很好地适应这一切。代码也将变得更规範更易维护。

其他种类的代码複查。在软体组织中，一种常用的方法是同行评审，就是几个工程师彼此複查程式。组织良好的同行评审一般会发现程式中50%～70%的缺陷。互查虽然需要很多时间，但是可以有效发现缺陷，因为工程师往往难于发现自己的设计错误。他们创作这个设计，直到程式应该完整什幺，即使概念有瑕疵、作了错误的设计或实现假定，他们往往很难发现。检查这可以帮助他们克服这些问题。对一个大的项目，最佳检查策略是，先做个人代码複查再进行编译，然后在任何测试前进时行同行检查。

细心工作是有回报的。当工程师觉得对自己开发的程式附有质量责任时，他就不会依赖于编译器或其他工具来发现缺陷。全面的代码複查要花费时间，但是他们节省出来的时间比花费的时间多得多，并能够生产出更好的产品。

引入缺陷是人类的正常现象，所有的工程师都会引入缺陷。因此所有的工程师都应该了解自己引入缺陷的类型和数据。

在开发过程中，总是可再进行一轮测试或代码複查，决定是否这样做的唯一方法就是分析缺陷数据。通过分析历史数据，可以估计出程式中缺陷的个数。通过把当前项目的数据??的质量情况。这样就能决定是否需要增加一些缺陷排除步骤。

缺陷率的预测。当开发一个新的程式时，可能会觉得很难估计你将引入多少缺陷，理由是缺陷的个数因程式的不同而不同。缺陷个数不稳定是有以下几个原因造成的。首先使经验问题，个人的技能是在不断提高的。开始编程式时，要面临着很多以前没有碰到过的问题。往往不能确定有些过程和函式是如何执行的，可能是语言的结构不清楚或者可能会遇到新的编译器或编程环境的问题。这些问题都会引起开发时间和缺陷路的波动。有了经验后，你将逐渐克服这些问题，犯的错误就减少了。这既减少缺陷的总数又减少缺陷数目的波动。缺陷的减少起初是由于经验的增加和对语言熟练程度的提高。经过这最初的提高后，就需要收集和分析缺陷数据来进一步改进了。

缺陷路波动的第二个原因是个体过程不稳定。当开始学习写程式时你也同时开始学习使用新的过程和方法。你的过程将随着实际的经验不断的发展，这就会引起完成不同程式任务的时间和引入缺陷的数据的波动。

最后，缺陷本身也是这种变化的原因，引入的缺陷越多，修复这些缺陷所花时间就越长。修复缺陷所花的时间越长，引入新的缺陷的几率也就会增加。因此缺陷的修改时间变动幅度很大。所以，很难对一个引入很多缺陷的过程进行预测。

随着开发过程的改进，过程会逐步稳定下来。这种稳定将提高缺陷预测的準确性。试验证明，如果在代码複查方面花了足够的时间，你的过程会迅速稳定下来。一旦你的过程相当稳定，缺陷也将容易预测。

根据对最近的程式跟蹤每千行引入和排除的缺陷数，就可估计出在将来的程式中可能引入和排除的缺陷数。