11项针对轻量级高效同行代码评审-2
上一篇 / 下一篇 2012-08-23 09:38:28 / 个人分类：杂谈
团队需要维持这样一种态度，就是发现缺陷，就意味着代码开发者和评审者 作为一个团队 去改进产品的质量成功了。而不是“代码开发者产生了一个缺陷，而评审者负责去发现它”。它更像是配对编程的一种有效形式。
评审员要向所有的开发者展示收集坏习惯，学习新技巧，并展开功能的机会。开发员可以从他们的错误（bug）中学习，但是只是在他们警惕错误（bug）时才会这样。如果开发员害怕发现错误（bug），那么积极的结果就会消失。
如果您是一名初级开发员，或者是一个团队的新成员，那么其他人发现缺陷时，就意味着您强有力的队友在帮助您成长为一个合格的开发员。这就比您单枪匹马地编程，没有具体的反馈时，要更快地进步。
为了维持检查缺陷是积极的这样一种理念，管理人员必须要承诺缺陷密度不会进入到性能报告之中。公开作出这种承诺是很有效的。这样开发员就会知道他们要怎样做，并抗议公开破坏这条规则的管理人员。
管理人员绝不应该将错误（bug）代码作为消极性能评审的基础。他们必须谨慎对待，并对批评造成的挫折感及消极反应保持敏感，并要一直提醒团队发现错误（bug）是一件很好的事情。
9、警惕老大哥效应（Big Brother Effect）
作为一个开发员，您可以自动假设“老大哥正看着您呢”是真的，如果评审制度是由评审支持工具自动评价的，更是这样的。您是否花费了很长的时间去评审一下更改？您的同行从您的代码中是否发现了很多错误（bug）？这将如何影响您下一步的性能评价？
评估报表不应用来对付开发人员，尤其是在面对结对评审员时。这一做法会严重破坏道德观。
制度对于流程评价来说非常重要，这反过来，又为流程改进提供了一个基础。但是制度也可以被用来做坏事。如果开发员相信制度是用来对付他们的，那么他们不光是对流程有敌意，而且他们的注意力可能转到改变制度，而不是编写更好的代码，和变得更有效率上。
管理员可以做很多事情，来解决这个问题。首先也是最重要的，他们必须要警惕这一点，并且必须确定代码开发者没有面临很多的压力，而“老大哥”问题必须每次都得到详细的检查。
制度应该用来评价流程的效率，或者流程更改的效果。记住，通常来说，最困难的代码是由最有经验的开发员处理的。这些代码，反过来，最有可能出问 题，因此最难检查，也有可能发现最多的缺陷。因此，大量的缺陷很有可能是由复杂性，以及代码的分块性造成的，而不是代码开发者的能力造成的。
如果制度确实能够帮助一个管理员去发现一个问题，那么将某人踢出局可能会产生更多的问题。我们推荐管理员在解决相关问题时，要将一个小组当做整 体来对待。所以最好不要召开专门的会议，因为开发员在解决特定的问题可能会有压力。相反，您可以通过一个每周状态会议，或者正常的程序来解决问题。
管理员必须不断地维持这样一个年头，即搜索缺陷是好的事情，而不是糟糕的，缺陷密度与开发员的能力并不是挂钩的。记住对一个团队来说，缺陷，尤其是团队成员所引入缺陷的数量不应该被回避，也不应该用作能力的评价参数。
10、评审一部分的代码，就算您不能全部完成，以从自我效能感（Ego Effect）中获益
想象一下您自己坐在编译器的前面，任务是需要修复一个小小的错误（bug）。但是您知道只要您说出了“我完成了”，您的同行 — 或者更糟，您的老板 — 就要检查您的工作了。这会改变您的开发个性吗？所以在您工作时，一般是在您声明代码评审完成之前，就会更加的谨慎了。如此您立即就会成为一个更好的开发员 了，因为在您背后别人议论您时就会说，“他的员工非常谨慎，他真是一个不错的开发员”；而不是“他犯了大量愚蠢的错误（bug）。当他说工作完成时，实际 上还差着远呢”。
自我效能感（Ego Effect）会促使开发员编写更好的代码，因为他们知道其他人将会查看自己编写的代码及作品。没有人想被其他人认为自己经常犯初级的错误（bug）。Ego Effect 促使开发员在向其他人交付作品时更加谨慎地进行评审。
Ego Effect 的一个良好特征，是不管评审者要对所有的代码变更负责，还是仅仅执行“点检查”，就像随机性的药物测试一样，都能正常地发挥作用。如果您的代码有三分之一 的几率被评审者抽中进行评审，那么它仍然足以刺激评审者谨慎工作。如果您只有十分之一的概率被抽中检查，那么可能您就不会如此勤奋了。您知道您会说， “哈，我很少犯错”。
评审 20–33% 的代码时，从 Ego Effect 中获得花费时间方面的收益可能最大，评审 20% 的代码肯定要比不评审强很多。
11、采用轻量级，工具支持的代码评审
代码评审一般有些主要的类型和无数的变数，而指南却能适用它们中的任何一个。但是，为了完全优化团队花在评审之上的时间，我们要使用工具支持的轻量级评审过程来得到最优的结果。搜索缺席时，它是有效的，实用的。
规范，或者 重量级的 检查已经流行了 30 年。它已经不是评审代码的有效形式了。重量级检查平均花费的时间是每 200 行代码 9 个小时。尽管它很有效，但是严格的过程需要三到六个参与者，并进行一系列繁琐的会议以讨论具体的细节。不幸的是，尽管需要繁琐的过程，但是大多数的公司没 有条件将编程人员集成起来，进行长时间的会议。最近的几年，许多开发公司已经完全放弃了会议安排，纸质代码阅读，以及繁琐的作品收集工作，转而采用新型 轻量级 过程，以从规范的会议及老式重量级过程的重压中解放起来。
我们使用在 Cisco 中的案例研究，来确定轻量级技术与规范过程比较的特点。结果显示轻量级代码评审所需要的时间只是规范评审的五分之一（甚至更少），而且前者能够发现更多的错误（bug）。
尽管轻量级代码评审拥有很多的方法，例如实时评审和电子邮件评审，但是最有效的评审方法还是使用协作性的软件工具来促进评审，这些软件工具例如 SmartBear 的 CodeCollaborator（见于图 4）。
图 4. Cisco 研究中所使用到的轻量级代码评审工具，CodeCollaborator
CodeCollaborator 是与 IBM？ Rational Team Concert 工作流程相集成的唯一代码评审工具。它将源代码评审与聊天形式的协作集成起来，从而使开发员从联系注释与私人代码行的繁琐活动中解放了出来。当程序员向工 作项添加更改项进行评审时，在 CodeCollaborator 中将会自动创建评审，并分配适当的批准者。团队成员可以直接注释代码，与代码开发者聊天，并就每一个问题进行协作，追踪错误（bug）并修复缺陷。整个过 程不需要会议，打印，或者安排日程。
有了基于 Rational Team Concert 与 CodeCollaborator 的轻量级评审过程，团队就可以进行更有效的评审，并实现代码评审的有利点。
CodeCollaborator 获得了 “Ready for IBM Rational Software” 针对 Rational Team Concert V2 和 V3 的认证，以及针对 IBM？Rational？ClearCase？和 IBM？Rational？Synergy？ 的认证。
到现在为止，您已经被经实践证明有效的经验从头到尾武装起来了，以确保从过程和社会的角度来看，团队在代码评审过程 之中能够节省大量的时间。当然，您必须确实 完成了 代码评审，以实现这些便利。对 100% 的代码使用评审的规范方法（有人对这个百分比存在异议，简单来说是不现实的。集成到 Rational Team Concert 环境之中的工具支持轻量级代码评审，提供了最强大的功能，因为它提供了一个有效的方法去搜索缺陷，而且不会涉及到开发员头痛的一些问题。有了正确的工具和 这些实践方式，您的团队就可以对所有的代码进行同行评审，并在软件达到 QA 阶段之前就找到成本极高的错误（bug），这样您的客户每次都能够得到顶级品质的产品了。
为了方便您查看，下面总结了在一个简单列表中最容易保持的 11 项实践方式：
1、一次评审少于 200–400 行的代码。
2、目标为每小时低于 300–500 LOC 的检查速率。
3、花足够的时间进行正确缓慢的评审，但是不要超过 60–90 分钟。
4、确定代码开发者在评审开始之前就已经注释了源代码。
5、为代码评审和获取制度建立可定量化的目标，这样您才能改进流程。
6、使用检查列表，因为它可以极大地改进代码开发者和评审者的作品。
7、确认缺陷确实得到修复了。
8、培养良好的代码评审文化氛围，在这样的氛围中搜索缺陷被看做是积极的活动。
9、警惕“老大”效应。
10、最少评审一部分代码，就是您不能评审全部的代码，以从 Ego Effect 中受益。
11、采用轻量级，能用工具支持的代码评审。
TAG:
我的栏目
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 3336556
- 日志数: 1640
- 建立时间: 2011-12-07
- 更新时间: 2019-12-24
