如何管理软件开发中的重构_第1页
如何管理软件开发中的重构_第2页
如何管理软件开发中的重构_第3页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

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

通常，当测试人员听到开发人员兴致勃勃地宣称要重构代码的时候，就好像万里晴空突然飘来一片乌云，“糟糕，接下来又不知道要花多少额外时间测试了”。两年前，我也是这种感觉。但现在我已经不再对重构心有顾忌。在此整理一下两年来我所在的项目组对于重构的管理，看看我们的改进方法。对开发人员而言，1.重构前要提出重构的理由虽然大部分重构都是基于改进代码的良好愿望，但是“别人写的代码看不懂，还不如自己重写”这样的理由不能成立。设想，若每次开发人员换了模块或者项目就要重写一遍相关程序，对于公司的资源是多么大的浪费!如果对于一个明知3个月后要全面修改需求的模块进行代码重构也许也不能得到支持。2.重构一定要作为变更通知到测试人员进行相应的测试测试人员最不能接受的其实不是重构，而是开发人员重构了代码却没有通知测试人员，往往给产品质量带来一些surprise。有时改动两行代码的顺序，或者注释掉一句认为冗余的代码，开发人员都觉得不能称其为重构，一般就是“顺手”就改了，但其实都有可能引入新的缺陷。我们要求开发人员对在没有需求变更的地方的代码的任何更改都作为技术变更记录下来，通知测试人员。仅仅是通知还不够，如果可能，应该把重构的影响面都明确列举出来，使测试人员能够有的放矢，更有效地测试。有些工具，比如ClearCase和ClearQuest的集成，要求每个文件的checkout都选择一个需求变更或者缺陷作为原因，在一定程度上也是帮助开发人员培养这样的一种意识“凡修改必关联一个原因，不做顺手的修改”。而且，有的重构因为影响面大，会影响测试时间的长短或者测试重心，也需要及时通知测试人员及早计划和安排。3.需要保障重构的质量我们建议开发人员通过代码审查或者建立底层的自动化测试来保障重构的质量，不要把所有质量的风险都放到测试阶段。对于管理人员而言，上到下，由开发组长主动安排某个版本集中进行重构;而非从下到上，由每个开发人员在各个版本随机提出重构.前一种方式能够更节约测试的资源，避免每次都进行大规模的回归测试。而且，通常也能更好地保障充分测试的时间，而不是一般在每个版本中硬性地挤进一些重构，又觉得可以在某些回归中顺带测测就好了。后一种方式，类似每个版本都听到四处在叫“狼来了”，即使测试时间能够得到保障，对测试人员的长期的精神压力也会影响测试效率。对测试人员而言，以积极的心态去面对重构，视之为常态。重构虽然有风险，短期内也许需要更多测试的投入来保障。但从另一个角度也是一件好事，因为它至少表明了改进代码质量的意愿。改进代码质量不也是测试人员希望的么?那就象拥抱变更一样地拥抱重构吧!通过积极推动自动化的方式，将重构后回归测试的代价降低。这里说的自动化测试并不仅仅是测试人员常用的功能层面的测试，

人人文库> 全部分类> 应用文书 > 作业报告

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论