經(jīng)常聽到開發(fā)人員抱怨 “這么爛的代碼，我來重構(gòu)一下吧！”，“這代碼怎么能這么寫呢？誰來重構(gòu)一下？”，“這兒有個(gè)壞味道，重構(gòu)吧！”，作為一名QA，每次聽到“重構(gòu)”兩個(gè)字，既想給追求卓越代碼的開發(fā)人員點(diǎn)個(gè)贊，同時(shí)又會(huì)感覺非常緊張，為什么又要重構(gòu)？馬上就要上線了，怎么還要改？是不是應(yīng)該阻止開發(fā)人員做重構(gòu)？
重構(gòu)幾乎是開發(fā)人員最喜歡的一項(xiàng)實(shí)踐了，可QA們卻充滿了顧慮，那么為什么QA不喜歡重構(gòu)呢？
老功能被破壞
不止一次遇到這樣的場景，突然某一天一個(gè)老功能被破壞了，QA們感到奇怪，產(chǎn)品這塊的功能已經(jīng)很穩(wěn)定了，也沒有在這部分開發(fā)什么新功能，為什么突然出問題了呢？追查下去發(fā)現(xiàn)是近期做了重構(gòu)，再追問的話，對于老代碼，測試已經(jīng)幾乎看不太懂了，可是看到壞味道又實(shí)在心癢癢，就想重構(gòu)，于是功能破壞了。
在快速迭代的開發(fā)模式下，QA們主要關(guān)注用戶故事的生命周期，重點(diǎn)測試新的特性功能，所以對于老功能回歸測試的投入是非常有限的，如果開發(fā)人員突然對老功能進(jìn)行了重構(gòu)又沒有告知團(tuán)隊(duì)，很可能這樣的問題就會(huì)進(jìn)入生產(chǎn)環(huán)境，這樣是非常有風(fēng)險(xiǎn)的，所以很多開發(fā)人員重構(gòu)老功能時(shí)會(huì)告知QA，雖然這樣可以提前發(fā)現(xiàn)和修復(fù)導(dǎo)致的問題，但無疑會(huì)大大增加QA做回歸測試的負(fù)擔(dān)。
新功能推遲/重復(fù)測試
按照用戶故事的開發(fā)流程，開發(fā)人員完成功能后多方角色會(huì)在開發(fā)人員機(jī)器上進(jìn)行用戶故事的快速驗(yàn)收以及探索性測試，然后我們期望的是開發(fā)人員提交代碼，拿包測試，但有的時(shí)候我們在開發(fā)機(jī)器上驗(yàn)收之后，開發(fā)人員才會(huì)進(jìn)行重構(gòu)，曾經(jīng)經(jīng)歷過故事驗(yàn)收的時(shí)候功能都是正常的，拿到包之后好多功能不工作了，跟開發(fā)人員確認(rèn)，又是重構(gòu)導(dǎo)致的。
所以有時(shí)候開發(fā)人員會(huì)在驗(yàn)收之后告知QA還會(huì)繼續(xù)重構(gòu)，QA可以等到重構(gòu)完成后再做測試，或者開發(fā)人員會(huì)先重構(gòu)再做驗(yàn)收，前者會(huì)導(dǎo)致用戶故事的測試時(shí)間推遲，后者則會(huì)導(dǎo)致重復(fù)的驗(yàn)收測試。
無計(jì)劃不可見
開發(fā)人員的重構(gòu)時(shí)機(jī)對我們來說是無規(guī)律的，有的時(shí)候一邊開發(fā)用戶故事一邊重構(gòu)，有的時(shí)候會(huì)在故事完成后QA在開發(fā)機(jī)器上驗(yàn)證結(jié)束后才做重構(gòu)，有的是代碼評(píng)審后大家指出問題后做重構(gòu)，有的甚至依賴于項(xiàng)目組來了有經(jīng)驗(yàn)的開發(fā)人員才開始重構(gòu)。對QA來說，重構(gòu)的時(shí)機(jī)是無計(jì)劃的。
另外重構(gòu)也是不可見的，我們總談可視化，日常的開發(fā)工作由用戶故事和缺陷來可視化，而重構(gòu)經(jīng)常是幕后進(jìn)行的，不被跟蹤不被記錄不可見，有經(jīng)驗(yàn)的開發(fā)人員會(huì)在進(jìn)行“大”的重構(gòu)之前告知團(tuán)隊(duì)，如果沒有告知，就在不知不覺中發(fā)生了，只有功能被破壞了才能意識(shí)到。
總結(jié)
以上列出了QA不喜歡重構(gòu)的三個(gè)理由，歸根結(jié)底其實(shí)都是重構(gòu)不當(dāng)導(dǎo)致。代碼重構(gòu)（Code refactoring）指對軟件代碼做任何更動(dòng)以增加可讀性或者簡化結(jié)構(gòu)而不影響輸出結(jié)果。而不當(dāng)?shù)闹貥?gòu)往往只關(guān)注了前半部分卻忽略了對輸出結(jié)果的影響。
重構(gòu)的目標(biāo)是為了改善代碼質(zhì)量，長遠(yuǎn)來說應(yīng)該是可以減少軟件缺陷的，從這個(gè)角度來說QA和開發(fā)人員的目標(biāo)是一致的，我們相信，如果重構(gòu)恰當(dāng)，必定對項(xiàng)目是有利無害的。
如果能夠符合以下幾個(gè)規(guī)則，也許可以很大程度減少Q(mào)A對重構(gòu)的顧慮：
1. 充足的自動(dòng)化測試是保障輸出結(jié)果的一個(gè)有效途徑。不管對于歷史代碼還是新代碼，進(jìn)行重構(gòu)的前提應(yīng)該是確保這部分功能已經(jīng)有了足夠的自動(dòng)化測試覆蓋，否則就不要進(jìn)行重構(gòu)。
2. 對于新功能的重構(gòu)，應(yīng)該融入到正常開發(fā)過程中，在故事驗(yàn)收之前已經(jīng)完成了相應(yīng)的重構(gòu)，因?yàn)樽詣?dòng)化測試不是萬能的，也不可能達(dá)到100%的覆蓋率，所以還是需要QA的驗(yàn)證的。
3. 小步前進(jìn)，盡量避免或者減少大的重構(gòu)，這樣可以減少突然增多的回歸測試工作量，也會(huì)減少功能被破壞的風(fēng)險(xiǎn)。
4. 對于一些核心功能或者組件，進(jìn)行重構(gòu)之前盡早告知團(tuán)隊(duì)QA，以便QA可以合理安排測試計(jì)劃。
5. 盡量避免在產(chǎn)品上線前進(jìn)行重構(gòu)，不僅可以減輕QA回歸測試的負(fù)擔(dān)，也會(huì)減少功能破壞后來不及修復(fù)的風(fēng)險(xiǎn)。
