文／刘建华
经常听到开发人员抱怨 ，“这么烂的代码，我来重构一下！”，“这代码怎么能这么写呢？谁来重构一下？”，“这儿有个坏味道，重构吧！”
作为一名QA，每次听到“重构”两个字，既想给追求卓越代码的开发人员点个赞，同时又会感觉非常紧张，为什么又要重构？马上就要上线了，怎么还要改？是不是应该阻止开发人员做重构？
重构几乎是开发人员最喜欢的一项实践了，可QA们却充满了顾虑，那么为什么QA不喜欢重构呢？
不止一次遇到这样的场景，某一天一个老功能突然被破坏了，QA们感到奇怪，产品这块儿的功能已经很稳定了，也没有在这部分开发什么新功能，为什么突然出问题了呢？
追查下去发现是近期做了重构。再追问下去，对于老代码，已经几乎看不懂老的测试了，可是开发人员看到代码的坏味道就想重构，于是功能破坏了。
在快速迭代的开发模式下，QA们主要关注用户故事的生命周期，重点测试新的特性功能，所以对于老功能回归测试的投入是非常有限的，如果开发人员突然对老功能进行了重构又没有告知团队，这样的问题很可能就会进入生产环境，这样是非常有风险的。即便很多开发人员重构老功能时会告知QA，以提前发现和修复导致的问题，但无疑会大大增加QA做回归测试的负担。
按照用户故事的开发流程，开发人员完成功能后，多方角色会首先在开发人员的机器上进行用户故事的快速验收以及探索性测试，然后开发人员会提交代码，由QA拿到包之后部署到测试环境进行测试。
但有的时候QA在开发机器上快速验收之后，开发人员又进行重构，曾经经历过“故事验收的时候功能都是正常的，拿到包部署之后好多功能不工作了”的事情，跟开发人员确认，又是重构导致的。
有时候开发人员会在用户故事验收之后告知QA还会继续重构，QA可以等到重构完成后再拿新的版本做测试，这样就会导致用户故事的测试时间推迟。或者开发人员会先重构再做验收，而这样又会导致QA在开发机器上进行重复的验收测试。
开发人员的重构时机对我们来说是无规律的。有的时候一边开发用户故事一边重构，有的时候会在故事完成后、QA在开发机器上验证结束后才做重构，有的是代码评审后大家指出问题后做重构，有的甚至得等到项目组来了有经验的开发人员才开始重构。对QA来说，重构的时机是无计划的。
另外重构也是不可见的。我们总谈可视化，日常的开发工作由用户故事和缺陷来可视化，而重构经常是幕后进行的，不被跟踪、不被记录、不可见，有经验的开发人员会在进行“大”的重构之前口头告知团队，如果没有告知，就在不知不觉中发生了，只有功能被破坏了才能意识到。
以上列出了QA不喜欢重构的三个理由，归根结底其实都是重构不当导致的。代码重构（Code refactoring）指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。而不当的重构往往只关注了前半部分却忽略了对输出结果的影响。
个人认为，如果能够注意以下几个方面，也许可以很大程度减少QA对重构的顾虑：
充足的自动化测试是保障输出结果的一个有效途径。不管对于历史代码还是新代码，进行重构的前提应该是确保这部分功能已经被足够的自动化测试覆盖，有的开发人员认为这是一个不可行的建议，因为“充足”对于每个人每个角色的标准可能是不一样的，QA也许永远都不会觉得测试足够，但是其实可以借助测试覆盖率等度量工具，甚至直接针对功能特性由QA来定义需要哪些自动化测试，在补齐这些自动化测试的基础上再做重构。
对于新功能的重构，应该融入到正常开发过程中，在故事验收之前已经完成相应的重构。因为自动化测试不是万能的，也不可能达到100%的覆盖率，所以还是需要QA验证的。这么做就意味着客户要为我们的重构买单，所以作为软件领域专家的我们，如何让业务领域专家的客户理解重构的价值，这就变的至关重要了。
小步前进，尽量避免或者减少大的重构。这样可以减少突然增多的回归测试工作量，也会减少功能被破坏的风险。如果发生了大的重构，反思一下是哪里出了问题？是我们积攒了太多的技术债？还是业务领域模型发生了大的改变？然后采取措施避免类似的事情再度发生。
对于一些核心功能或者组件，进行重构之前尽早告知团队QA。如果能够给QA讲解一下重构的目的以及本次重构可能会影响到的业务区域会对QA有很大的帮助。这样做一方面可以让QA把重心放在最容易受到影响的功能上加强回归测试，另一方面也能帮助QA更合理地安排测试计划。
尽量避免在产品上线前进行重构。不仅可以减轻QA回归测试的负担，也会降低功能破坏后来不及修复的风险。
重构的目标是为了改善代码质量，长远来看应该是可以减少软件缺陷的，从这个角度来说QA和开发人员的目标是一致的，我们相信，如果重构恰当，必定对项目是有利无害的。
关注微信
