新浪微博:罗斯汀zdlzx

如何管理软件开发中的重构

上一篇 / 下一篇  2011-03-05 20:58:44 / 个人分类:测试技能

通常,当测试人员听到开发人员兴致勃勃地宣称要重构代码的时候,就好像万里晴空突然飘来一片乌云,“糟糕,接下来又不知道要花多少额外时间测试了”。两年前,我也是这种感觉。但现在我已经不再对重构心有顾忌。在此整理一下两年来我所在的项目组对于重构的管理,看看我们的改进方法。

 

对开发人员而言,

1. 重构前要提出重构的理由

虽然大部分重构都是基于改进代码的良好愿望,但是“别人写的代码看不懂,还不如自己重写”这样的理由不能成立。设想,若每次开发人员换了模块或者项目就要重写一遍相关程序,对于公司的资源是多么大的浪费!如果对于一个明知3个月后要全面修改需求的模块进行代码重构也许也不能得到支持。

 

2. 重构一定要作为变更通知到测试人员进行相应的测试

测试人员最不能接受的其实不是重构,而是开发人员重构了代码却没有通知测试人员,往往给产品质量带来一些surprise。有时改动两行代码的顺序,或者注释掉一句认为冗余的代码,开发人员都觉得不能称其为重构,一般就是“顺手”就改了,但其实都有可能引入新的缺陷。我们要求开发人员对在没有需求变更的地方的代码的任何更改都作为技术变更记录下来,通知测试人员。仅仅是通知还不够,如果可能,应该把重构的影响面都明确列举出来,使测试人员能够有的放矢,更有效地测试。有些工具,比如ClearCaseClearQuest的集成,要求每个文件的check out都选择一个需求变更或者缺陷作为原因,在一定程度上也是帮助开发人员培养这样的一种意识“凡修改必关联一个原因,不做顺手的修改”。

而且,有的重构因为影响面大,会影响测试时间的长短或者测试重心,也需要及时通知测试人员及早计划和安排。

 

3. 需要保障重构的质量

我们建议开发人员通过代码审查或者建立底层的自动化测试来保障重构的质量,不要把所有质量的风险都放到测试阶段。

 

对于管理人员而言,

1. 上到下,由开发组长主动安排某个版本集中进行重构;而非从下到上,由每个开发人员在各个版本随机提出重构

前一种方式能够更节约测试的资源,避免每次都进行大规模的回归测试。而且,通常也能更好地保障充分测试的时间,而不是一般在每个版本中硬性地挤进一些重构,又觉得可以在某些回归中顺带测测就好了。后一种方式,类似每个版本都听到四处在叫“狼来了”,即使测试时间能够得到保障,对测试人员的长期的精神压力也会影响测试效率。

 

对测试人员而言,

1. 以积极的心态去面对重构,视之为常态

重构虽然有风险,短期内也许需要更多测试的投入来保障。但从另一个角度也是一件好事,因为它至少表明了改进代码质量的意愿。改进代码质量不也是测试人员希望的么?那就象拥抱变更一样地拥抱重构吧!

 

2. 通过积极推动自动化的方式,将重构后回归测试的代价降低

这里说的自动化测试并不仅仅是测试人员常用的功能层面的测试,还包括开发人员的单元测试。在一个自动化测试框架的保障下,重构不一定会需要太多额外的测试代价。这一点我们还做得很不够。

TAG:

 

评分:0

我来说两句

日历

« 2024-03-27  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 1323904
  • 日志数: 88
  • 建立时间: 2010-08-18
  • 更新时间: 2016-02-25

RSS订阅

Open Toolbar