为什么QA不喜欢重构？

经常听到开发人员抱怨 “这么烂的代码，我来重构一下吧！”，“这代码怎么能这么写呢？谁来重构一下？”，“这儿有个坏味道，重构吧！”，作为一名QA，每次听到“重构”两个字，既想给追求卓越代码的开发人员点个赞，同时又会感觉非常紧张，为什么又要重构？马上就要上线了，怎么还要改？是不是应该阻止开发人员做重构？

重构几乎是开发人员最喜欢的一项实践了，可QA们却充满了顾虑，那么为什么QA不喜欢重构呢？

老功能被破坏

不止一次遇到这样的场景，突然某一天一个老功能被破坏了，QA们感到奇怪，产品这块的功能已经很稳定了，也没有在这部分开发什么新功能，为什么突然出问题了呢？追查下去发现是近期做了重构，再追问的话，对于老代码，测试已经几乎看不太懂了，可是看到坏味道又实在心痒痒，就想重构，于是功能破坏了。

在快速迭代的开发模式下，QA们主要关注用户故事的生命周期，重点测试新的特性功能，所以对于老功能回归测试的投入是非常有限的，如果开发人员突然对老功能进行了重构又没有告知团队，很可能这样的问题就会进入生产环境，这样是非常有风险的，所以很多开发人员重构老功能时会告知QA，虽然这样可以提前发现和修复导致的问题，但无疑会大大增加QA做回归测试的负担。

QA发现功能破坏后找出重构导致

新功能推迟/重复测试

按照用户故事的开发流程，开发人员完成功能后多方角色会在开发人员机器上进行用户故事的快速验收以及探索性测试，然后我们期望的是开发人员提交代码，拿包测试，但有的时候我们在开发机器上验收之后，开发人员才会进行重构，曾经经历过故事验收的时候功能都是正常的，拿到包之后好多功能不工作了，跟开发人员确认，又是重构导致的。

所以有时候开发人员会在验收之后告知QA还会继续重构，QA可以等到重构完成后再做测试，或者开发人员会先重构再做验收，前者会导致用户故事的测试时间推迟，后者则会导致重复的验收测试。

在开发机器上重复验收

无计划不可见

开发人员的重构时机对我们来说是无规律的，有的时候一边开发用户故事一边重构，有的时候会在故事完成后QA在开发机器上验证结束后才做重构，有的是代码评审后大家指出问题后做重构，有的甚至依赖于项目组来了有经验的开发人员才开始重构。对QA来说，重构的时机是无计划的。

另外重构也是不可见的，我们总谈可视化，日常的开发工作由用户故事和缺陷来可视化，而重构经常是幕后进行的，不被跟踪不被记录不可见，有经验的开发人员会在进行“大”的重构之前告知团队，如果没有告知，就在不知不觉中发生了，只有功能被破坏了才能意识到。

重构总是不知不觉发生

总结

以上列出了QA不喜欢重构的三个理由，归根结底其实都是重构不当导致。代码重构（Code refactoring）指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。而不当的重构往往只关注了前半部分却忽略了对输出结果的影响。

重构的目标是为了改善代码质量，长远来说应该是可以减少软件缺陷的，从这个角度来说QA和开发人员的目标是一致的，我们相信，如果重构恰当，必定对项目是有利无害的。

如果能够符合以下几个规则，也许可以很大程度减少QA对重构的顾虑：

1. 充足的自动化测试是保障输出结果的一个有效途径。不管对于历史代码还是新代码，进行重构的前提应该是确保这部分功能已经有了足够的自动化测试覆盖，否则就不要进行重构。

2. 对于新功能的重构，应该融入到正常开发过程中，在故事验收之前已经完成了相应的重构，因为自动化测试不是万能的，也不可能达到100%的覆盖率，所以还是需要QA的验证的。

3. 小步前进，尽量避免或者减少大的重构，这样可以减少突然增多的回归测试工作量，也会减少功能被破坏的风险。

4. 对于一些核心功能或者组件，进行重构之前尽早告知团队QA，以便QA可以合理安排测试计划。

5. 尽量避免在产品上线前进行重构，不仅可以减轻QA回归测试的负担，也会减少功能破坏后来不及修复的风险。