活动:复审代码
目的
|
角色:
技术复审员
|
频率:每个迭代 |
步骤
|
输入工件:
|
生成的工件:
|
工具向导:
|
当构造高质量软件时,复审实施是对其它质量机制(如编译、集成和测试)的补充。在复审实施之前,先编译并使用工具(如代码规则检查程序)捕获尽可能多的错误。考虑使用可使代码可视化的工具。
如果使用运行时错误检测工具执行代码,则在实施复审之前也会检测和消除更多错误。
复审实施的好处是:
- 对项目强制实施和鼓励使用通用的编码样式。代码复审是使成员遵循编程指南的有效方法。
为了保证这一点,复审所有作者和实施者得出的结果比复审所有源代码文件更重要。
- 查找自动化测试未能发现的错误。实施复审捕获的错误与这些测试不同。
- 在个人之间共享知识,并将知识从较有经验的人员传授给缺乏经验的人员。
存在几种技术可用于复审实施。使用以下技术之一:
- 检查。详细检查实施的正式评估技术。检查被视为最有成效的复审技术,但它需要培训和准备工作。
- 走查。一种评估技术,其中实施作者带领一个或多个复审人员通过实施。复审人员询问问题,并且就技术、样式、可能错误、编码标准违例等方面给出意见。
- 读代码。一两个人员读代码。当复审人员准备就绪时,他们可开会并提出意见和问题。不过可以省略会议,复审人员可将意见和问题以书面的形式交给作者。建议通过读代码验证小的修改并作为“健康检查”。
此角色的技能需求与实施者角色的需求类似;扮演此角色的人员通常被视为用于复审代码的编程语言方面的专家。在大多数项目中,此角色由来自实施团队的高级程序员来担任。
另请参阅 指南:复审。
此部分提供了复审实施的一些常规检查点,作为在复审中查找内容的示例。编程指南应是代码质量的主要信息源。
概要
- 代码遵循编程指南吗?
- 代码是自说明的吗?有可能通过阅读代码来了解代码吗?
- 代码规则检查和/或运行时错误检测工具检测出的所有错误都已处理了吗?
注释
- 注释是最新的吗?
- 注释是明确和正确的吗?
- 如果代码变化,注释易于修改吗?
- 注释是侧重于解释为什么而不是如何的吗?
- 对于所有意外、异常情况和变通方法错误都做了注释吗?
- 对每个操作的目的都做了注释吗
- 关于每个操作的其它相关情况都做了注释吗?
源代码
- 每个操作都具有描述操作内容的名称吗?
- 参数具有描述性名称吗?
- 通过每个操作的正常路径与其它异常路径明确可区分吗?
- 操作过长吗?可以通过将相关语句抽取到私有操作中来简化此操作吗?
- 操作过长吗?可以通过减少决策点个数来简化此操作吗?决策点是代码择取不同路径的语句,如if、else、and、while 和 case 语句。
- 循环嵌套是最少的吗?
- 变量命名恰当吗?
- 代码是直接了当并避免了“耍小聪明的”解决方案的吗?
每次复审会议之后,会议结果必须记录在复审记录中。此外,缺陷必须记录在变更请求中(并最终指派给拥有和促成解决方案的人)。
|