如何举行一次高效的软件代码评审会议?

如何举行一次高效的软件代码评审会议?作者:uahoo

 

 

 

许多软件公司中,程序员是被代码缺陷驱赶着前进,程序员的工作节奏就是:编码、交付、修复缺陷、再交付的循环中... … 。在零碎的缺陷面前,程序员长期单独作战,无从全面了解设计与架构,也无法分享经验和获得团队的帮助与认可,他们情绪开始低落,知识结构也逐渐陈旧,开始死气沉沉。

代码评审(code review)是提升程序员士气、激发热情、增强沟通、提高代码质量的有效方法,应该成为软件开发组织中常用的缺陷排除手段。

 

常见的评审包括管理评审、技术评审、软件评审。软件评审的正式形式是软件审查(software inspection)。非正式形式有许多种,包括代码评审(code review)、代码走查(code walkthrough)、捉对编程(pair programming)、肩头评审(over-the-shoulder)、桌面检查(desk check)等。

代码评审是软件评审的非正式形式之一,但是有一定的规范要求。我们在编码过程中可以灵活采用,如果能坚持使用并注意采集度量值,也可以进行过程的量化管理与分析。

 

下面用问答的形式介绍一次高效的代码评审如何举行。


什么样的代码参加评审?

 

  • 不是全部代码都要评审;

  • 如果代码只能由团队中的某一两个人能明白、维护时;

  • 如果代码对问题的实现比较抽象或者在算法上比较精妙时;

  • 代码中某个对象、类、API在使用时有困难,含混时;

  • 新手的代码或者采用新开发工具、开发语言编写的代码;

  • 如果某些代码很关键,运行时不能出现任何错误的代码。

 

 什么样的人参加评审?

 

  • 选择一个3-10人的评审团队;

  • 团队成员要有技术背景,能够阅读和理解被评审的代码; 

  • 选择一个主持人;(主持人有足够的技术背景,能客观地评价;控制会议、管理批评-不能让批评成为攻击。)

  • 作者和其他参观者。

 

一次典型的代码评审是如何互动的?

 

 

  • 评审会前散发材料 ,要提前散发,并确保代码被阅读了;

  • 评审会上作者介绍代码,并不是逐行读代码,而是简单描述代码功能,当有人不理解代码的用处或者有疑问时,作者给出解释。

  • 评审现场发现的缺陷只记录不修复,当检查者发现代码缺陷时,主持人只是记录在日志上,不允许立即修复它,而只是标识问题,直达所有代码评审完成,缺陷在会后被修复。

  • 不陷入解决问题的细节,在代码评审会议中,主持人特别注意不能把会转向解决问题的议程中,工程师喜欢解决问题,导致陷入细节和长时间讨论问题分析,这些讨论有价值,但不属于代码评审,导致发现代码缺陷的效率将降低。

 


代码评审如何处理缺陷?

 

  • 评审现场不允许修复缺陷,只允许-重构(refactor),通过现场重构代码,使得代码更加可读,可以标识额外的缺陷。

  • 评审会后,代码作者修改直至关闭所有问题。要保证所有问题被修复并被评审者确认。

 

代码评审单有哪些内容需要考虑?

 

  • 可读性;    代码是否清晰可读?程序员是否不必要的复杂化了代码?

  • 可维护性; 其他工程师可否维护该代码?文档和注释是否正确?

  • 正确性;    代码是否实现了功能?算法是否得当?

  • 可靠性和健壮性;     代码是否容错力?异常情况如何处理?

  • 安全性;代码在非授权访问,恶意使用,非法修改上如何处理?

  • 扩充性;当负载、用户、数据、输入等增长时,代码是否是系统扩充的瓶颈?

  • 重用性;本代码能否被其他应用使用?

  • 效率;代码是否有效地使用的系统资源?并能被优化?

 

一场代码评审会议需要多少人时?

 

  • 一般代码行数不多于400行;

  • 每次评审会议不超过2小时;

  • 评审团队中需要4~5人评审会前花费1-2小时阅读代码及准备评审;

  • 评审团队中需要4~5人花费1~2小时参加代码评审会议;

  • 一般统计评审效率是每小时预审代码约200行;评审会议上每小时评审100-150行代码

  • 句统计平均每次代码评审花费约20人时。

 

 

如何评价代码评审的效率和效果?

 

  • 代码评审效果差的主要原因有两个,评审内容太分散和评审过程不够严肃。如果评审活动不严肃,将浪费很多时间,而且没有回报,或者大家把它作为例行工作,敷衍了事。

  • 评审时,技术主管事先约定规定效率基准,如java类代码,评审前阅读代码的效率是每小时160-200行代码,评审时每小时需要评审110-150行代码,

  • 评估代码评审的效率时,常用3个指标测量,评审前的代码覆盖率,评审时的代码覆盖率,千行代码缺陷密度。评审前的代码覆盖率用于考核评审的准备工作,确保评审前,被评审代码被阅读和了解。覆盖率一般用每人时阅读的代码行表示。缺陷率一般用千行代码存在的缺陷数表示。

  • 针对某一类开发语言的代码评审,累积12次评审,或者执行代码评审3个月以上的,就可以针对每次统计的结果,进行效率评估和评审流程的改善。

 

评审的好处?

 

  • 在发现早期需求、设计、测试计划和用例的缺陷中,相对于测试,评审被逐渐公认是最有效和廉价的方法。

  • 通过评审,团队中得经验和智慧被充分利用;

  • 通过评审,让团队有参与感、工作被认可感、成就感;

  • 通过评审,提高团队成员的进步,提高团队预防缺陷的意识,建立高效技术团队

 

代码评审工具有哪些?

 

  • 最简化的形式  ;web或者客户端的diff工具,如Subversion用户可以使用Websvn;TortoiseSVN在小组内实施代码评审。

  • 轻量级代码评审工具; reviewboard;

  • 商业代码评审工具;  结合较为规范的流程和度量工具,可以采用商业化工具如Crucible ;

 

资料索引:

 《Software Project Management in Practice》

 《Applied Software Project Management 》

 《Pragmatic Software Testing: Becoming an Effective and Efficient TestProfessional 》

展开阅读全文

没有更多推荐了,返回首页