软件开发过程

软件开发过程

一. 规范

规范应当是从简单到复杂的，我们首先制定的规范并不复杂，只是对如何使用异常机制的一些定义。要获得这些规范并不困难，大部分介绍异常的技术资料中都给出了很多的建议。理解并使用它们，仅此而已。

1、对不正常的条件使用异常，尽可能准确的使用预定义的异常。这一目标来自于Effective Java中的条款39和条款42。其目的是为了能够正确的使用异常。使用系统提供的异常能够减少代码，提高代码的可读性（特别是新人不需要了解自定义的异常结构）。大多数情况下，系统提供的异常已经足够用了。

2、尽可能多的收集异常发生时的上下文信息。异常之所以比返回码优秀的一个原因就是它能够将错误类型化，提供比错误代码多得多的信息。因此，我们实在没理由不使用这一功能。

3、正确的使用异常转义，并保留原异常信息。异常转义的目的是为了让客户端能够得到易于理解的类型。我们想象一个用户登录的情境，假设用户数据保存在一个文件中，当文件中找不到用户名的相关记录的时候抛出一个RecordNotFoundException异常，系统截获了这个异常，并将其发布给用户，问题在于，用户会觉得非常的奇怪，为什么会是记录没有找到呢？因此，建立一个IllegalUserException异常会更适合于这种情况。

4、针对不同的抽象层次定义不同的异常。正如我们在第三点中提到的，RecordNotFoundException异常并不适合于用户这个层次。但是，这个异常对于程序员调试代码就很有意义了。

5、将异常发布到合适的地方。有计算机的地方就一定有输入和输出。如果把异常发生时的信息收集看作输入，那么异常的输出是什么呢？可能是错误的提示信息，可能是一个显示错误信息的网页，可能是日志中的记录，可能是一条短信，也可能是一封EMail。这些就是异常的输出形式。此外，异常的输出还需要正确的确定对象，对用户来说，异常只要有一个友好的提醒方式就够了，但对于管理者来说，异常需要记录下来，或是通过异步消息进行通知。

这就是规范，你也可以把它称为最佳实践、建议等名词。当然，它还可以更加的细化，但事情总有个过程，一开始把问题弄得过于复杂未必是一件好事，你说呢？

二．技能

有了规范是一回事，能否把规范运用起来则取决于人员的技能。在有一部描述清末的电影中，有这样一个情节，留学归来的知识分子为了提高民众的知识水平，不惜花费巨资免费发放报纸，这一举措大受欢迎，可惜大部分的民众都不识字，他们要报纸的原因只是这东西烧火很方便。

所以其次要解决的问题就是，大部分的程序员没有足够的异常处理经方面的技能。如果程序员没有这方面的概念，你把一本异常管理最佳实践放在他的面前会有用吗？

学会使用异常并不困难，困难的是如何让程序员正确的使用异常。什么时候使用系统定义的异常。什么时候使用自定义的异常，自定义异常又该如何设计。这些都是程序员的技能问题。基于这种思路，首先做的是培训，而培训的目标是让程序员理解异常的机制，让程序员能够把异常运用到工作中。培训不等于上课，因为我们的目标是能够影响程序员的行为，单靠上课是无法达成目标的，因此我们把几种方式综合使用。一般来说，程序员对未知的技术总是

有兴趣的，并且会尝试着运用，然后就会慢慢失去兴趣。这种对新技术的兴趣是可以利用的，但是要在兴趣过去之前将行为稳定下来。所以我们首先做的是挑选合适的程序员，他们要么就是有使用异常的经验，要么就是热衷于研究新技术，这些人是比较容易说服的。这些人的作用并不是限于学习，他们的主要职责是将这项技术传播到整个团队中。管理的本质其实是透过人来做事，而不是自己做事，所以传播知识的职责应该是由一个团队来共同承担，绝对不是一个技术主管上窜下跳的。我见过很多过于忙碌的技术主管，他们都犯了这个错误。

当我们在讨论会议上取得了对使用异常机制的共识之后。开始使用第二种方式－训练。训练分为两个部分，前半部分是讲述异常的机理、如何使用。这时候还不讲异常的最佳实践，因为大家还没能够熟练的使用异常，讲述最佳实践的效果不好。后半部分是让原先挑选的程序员辅导其他程序员练习异常的使用。练习的时间大约维持了3天，我们观察到项目开发的

速度并没有受到很大的影响，因为训练并没有占用很多的时间，辅导的时间也是分布到项目开发中，但是我们知道，如果要在项目引入异常，一开始速度是一定会下降的。在首次训练完毕之后，是第二次的训练，这次主要是介绍异常管理的最佳实践。有了一定的使用经验之后，团队顺利的接受了这部分的知识。团队已经开始拥有了这方面的技能了。

三．组织

由于是团队协作，因此我们考虑问题必须在团队环境中考虑，这就象多线程，在多线程环境中考虑问题的方式和单线程是截然不同的，任何问题都有基本的解决思路，团队协作中主要的问题包括沟通、信息传递、协作、计划等问题。所以我们解决问题的思路也是先定义出问题和要达到的目标，然后再来考虑方法。

我们认为，异常在组织中的最大作用是它清晰的定义了类开发者和类调用者之间的契约关系。所以，我们希望类的开发者清楚的说明一个方法在什么条件下会出现什么样的异常，类调用者则需要保证他的调用对异常有明确、完整的处理。

这个时候，我们需要过程的帮助了。

四．过程

为了实现组织一节中定义的目标，我们对过程进行修订：

1) 在设计类时，需要同时设计异常类，并编写异常类的说明文档，通过复审。

2) 在给出类和方法的说明时，需要给出异常的定义和触发的条件。

3) 在代码中使用异常，而不是返回值。

4) 对输入参数进行判定，使用参数不正确异常和空指针异常。

5) 测试所有异常。

6) 方法调用时，如果方法中有异常，必须使用try块进行异常处理。

7) 异常需要通过通用的框架发布。

1、2、5三点属于设计的内容，3、4、6、7四点属于编码的内容。

注意到了吗？这种过程的定义是非常具体的，准确的说这类似于作业流程。很多软件组织都没有做这方面的工作。抽象的制度是没有意义的，比如这么一条，严谨的做好软件测试。什么叫严谨？软件测试的基本原理就是你不可能测试所有的情况，那么，严谨到底是测试到什么地步，没人知道。而我们这里的定义则不一样，方法中抛出的异常都需要测试。非常的明确，如果你的代码中抛出了3个异常，那么你就需要至少三个测试方法来测试它们。

当然，其实这个过程制度还是不完整的，我们拿第4条来说，它就有几个问题：首没有指

明两种异常的使用环境；没有规定异常如何收集上下文环境。但是，我们认为，制度性的规章不必要定义的如此复杂，你见过法律规定拿匕首杀人定什么罪，拿刀子杀人定什么罪吗？你可能会问，刚才你说制度要定义的细一些，现在又说不要定义的这么细，这不是自相矛盾