為什麼QA不喜歡重構

08-10

為什麼QA不喜歡重構

經常聽到開發人員抱怨，「這麼爛的代碼，我來重構一下！」，「這代碼怎麼能這麼寫呢？誰來重構一下？」，「這兒有個壞味道，重構吧！」

作為一名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和開發人員的目標是一致的，我們相信，如果重構恰當，必定對項目是有利無害的。