如何管理軟件開發(fā)中的重構(gòu)

如何管理軟件開發(fā)中的重構(gòu)

通常，當(dāng)測試人員聽到開發(fā)人員興致勃勃地宣稱要重構(gòu)代碼的時候，就好像萬里晴空突然飄來一片烏云，“糟糕，接下來又不知道要花多少額外時間測試了”。兩年前，我也是這種感覺。但現(xiàn)在我已經(jīng)不再對重構(gòu)心有顧忌。在此整理一下兩年來我所在的項目組對于重構(gòu)的管理，看看我們的改進(jìn)方法。對開發(fā)人員而言，1.重構(gòu)前要提出重構(gòu)的理由雖然大部分重構(gòu)都是基于改進(jìn)代碼的良好愿望，但是“別人寫的代碼看不懂，還不如自己重寫”這樣的理由不能成立。設(shè)想，若每次開發(fā)人員換了模塊或者項目就要重寫一遍相關(guān)程序，對于公司的資源是多么大的浪費!如果對于一個明知3個月后要全面修改需求的模塊進(jìn)行代碼重構(gòu)也許也不能得到支持。2.重構(gòu)一定要作為變更通知到測試人員進(jìn)行相應(yīng)的測試測試人員最不能接受的其實不是重構(gòu)，而是開發(fā)人員重構(gòu)了代碼卻沒有通知測試人員，往往給產(chǎn)品質(zhì)量帶來一些surprise。有時改動兩行代碼的順序，或者注釋掉一句認(rèn)為冗余的代碼，開發(fā)人員都覺得不能稱其為重構(gòu)，一般就是“順手”就改了，但其實都有可能引入新的缺陷。我們要求開發(fā)人員對在沒有需求變更的地方的代碼的任何更改都作為技術(shù)變更記錄下來，通知測試人員。僅僅是通知還不夠，如果可能，應(yīng)該把重構(gòu)的影響面都明確列舉出來，使測試人員能夠有的放矢，更有效地測試。有些工具，比如ClearCase和ClearQuest的集成，要求每個文件的checkout都選擇一個需求變更或者缺陷作為原因，在一定程度上也是幫助開發(fā)人員培養(yǎng)這樣的一種意識“凡修改必關(guān)聯(lián)一個原因，不做順手的修改”。而且，有的重構(gòu)因為影響面大，會影響測試時間的長短或者測試重心，也需要及時通知測試人員及早計劃和安排。3.需要保障重構(gòu)的質(zhì)量我們建議開發(fā)人員通過代碼審查或者建立底層的自動化測試來保障重構(gòu)的質(zhì)量，不要把所有質(zhì)量的風(fēng)險都放到測試階段。對于管理人員而言，上到下，由開發(fā)組長主動安排某個版本集中進(jìn)行重構(gòu);而非從下到上，由每個開發(fā)人員在各個版本隨機提出重構(gòu).前一種方式能夠更節(jié)約測試的資源，避免每次都進(jìn)行大規(guī)模的回歸測試。而且，通常也能更好地保障充分測試的時間，而不是一般在每個版本中硬性地擠進(jìn)一些重構(gòu)，又覺得可以在某些回歸中順帶測測就好了。后一種方式，類似每個版本都聽到四處在叫“狼來了”，即使測試時間能夠得到保障，對測試人員的長期的精神壓力也會影響測試效率。對測試人員而言，以積極的心態(tài)去面對重構(gòu)，視之為常態(tài)。重構(gòu)雖然有風(fēng)險，短期內(nèi)也許需要更多測試的投入來保障。但從另一個角度也是一件好事，因為它至少表明了改進(jìn)代碼質(zhì)量的意愿。改進(jìn)代碼質(zhì)量不也是測試人員希望的么?那就象擁抱變更一樣地?fù)肀е貥?gòu)吧!通過積極推動自動化的方式，將重構(gòu)后回歸測試的代價降低。這里說的自動化測試并不僅僅是測試人員常用的功能層面的測試，