个体度量过程PSP0和PSP0.1

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

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

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

个体规划过程PSP1和PSP1.1

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

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

个体质量管理过程PSP2和PSP2.1

代码走查

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

个体循环过程PSP3

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小时，因此以小时为单位对工作时间进行测量不能提供用以计划和管理工作所需要的详细数据，而用分钟跟踪时间容易得多。一旦决定进行时间跟踪，用分钟作为测量单位将比用小时更恰当。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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