重構(gòu)
重構(gòu)作為敏捷實(shí)踐的精髓之一
1重構(gòu)的幾個(gè)要點(diǎn)
重構(gòu)不應(yīng)改變原有程序的可觀測的行為
把添加新功能和重構(gòu)當(dāng)做兩件不同的事情來對待,就像兩頂帽子,在開發(fā)過程中我們經(jīng)常兩頂帽子換著戴
小步重構(gòu),更安全的前進(jìn),讓代碼在絕大部分時(shí)間處于可工作的狀恣
檢垃圾式的重構(gòu):發(fā)現(xiàn)一個(gè)垃圾時(shí),不想跑題太多,同時(shí)也不想將垃圾留在原地;如果此時(shí)很容易重構(gòu),就立即完成,否則就記錄下來,等后續(xù)再來重構(gòu)
絕大多數(shù)的重構(gòu)是見機(jī)行事的,而非單獨(dú)安排的一項(xiàng)工作
重構(gòu)的唯一目的是讓我們開發(fā)更快,用更少的工作量創(chuàng)造更高的價(jià)值;重構(gòu)不是來自"整潔的代碼""良好的工程實(shí)踐"等道德要求,而是純粹從經(jīng)濟(jì)角度出發(fā)的考量
自測試代碼是重構(gòu)的基石,也是持續(xù)集成的關(guān)鍵環(huán)節(jié)。
各種基礎(chǔ)重構(gòu)手法組合使用,以實(shí)現(xiàn)高級的重構(gòu)目的
有人在得到一個(gè)好的設(shè)計(jì)之后,就完全忽略之前的代碼,重新進(jìn)行一遍實(shí)現(xiàn)。然而重新實(shí)現(xiàn)一遍代碼真的不難,難點(diǎn)在于如何讓之前的遺留代碼還能正常工作
以子類取代類型碼重構(gòu)
? 用封裝變量將類型碼封裝到一個(gè)函數(shù)內(nèi)部
? 創(chuàng)建一個(gè)工廠函數(shù),根據(jù)類型構(gòu)造不同的子類
? 創(chuàng)建其中一個(gè)子類
? 在工廠函數(shù)中替換構(gòu)造出來的對象
? 對每個(gè)類型重復(fù)上述操作
? 去除類型碼
? 使用函數(shù)下移重構(gòu)和以多志處理?xiàng)l件表達(dá)式重構(gòu)來處理原來的函數(shù)調(diào)用處的代碼
小步重構(gòu)
在書中反復(fù)地樂此不疲地強(qiáng)調(diào)小步重構(gòu)
以便可以隨時(shí)回退到上一個(gè)可工作的版本再次來過。
菅地法則
我們應(yīng)該至少在離開營地時(shí),讓營地比我們到來時(shí)更干凈。
- 結(jié)論如果每次經(jīng)過一段代碼,都讓其變得更干凈,積少成多,垃圾總是會被處理掉
- 每個(gè)人都應(yīng)當(dāng)在提交代碼時(shí)停下來想一下,我們這次提交是讓代碼更健康了, 還是更腐化了, 還是沒變化?
只有我們每次提交代碼都至少沒有讓代碼更腐化,代碼才能越來越健康
我們在增加功能的時(shí)候,順便重構(gòu)了原來的代碼,讓其可讀性更高,可復(fù)用性更好等等。
重構(gòu)與測試
測試是重構(gòu)的保護(hù)傘,我們需要有一組可靠的測試才能放手進(jìn)行重構(gòu)
- 我們所有可能的組合
實(shí)踐中我們需要適可而止,因?yàn)闇y試達(dá)到一定程度之后,其邊際效用會遞減
編寫太多測試,我們可能因?yàn)楣ぷ髁刻蠖鴼怵H
我們應(yīng)該把注意力集中在最容易出錯(cuò)和最沒有信心的地方 - 測試的指標(biāo)
覆蓋率,能一定程度上衡量測試是否全面而有效, - 最佳的衡量方式
主觀的感受
如果我們覺得對代碼比較有信心,那就說明我們的測試做的不錯(cuò)了 - 不依賴于某個(gè)特定測試框架進(jìn)行測試
喜歡使用 Spring提供的 SpringBootTest注解進(jìn)行測試 - 關(guān)注的是應(yīng)用自身的業(yè)務(wù)邏輯
業(yè)務(wù)邏輯才是測試的重點(diǎn),而非框架的邏輯。當(dāng)然有時(shí)候我們可能對框架的配置代碼信心不夠強(qiáng)(比如spring的配置還是比較復(fù)雜的),這個(gè)時(shí)候,我們可以有針對性的寫少數(shù)幾個(gè)測試來驗(yàn)證這些配置就足夠了 - 而基于某個(gè)特定框架實(shí)現(xiàn)的測試往往維護(hù)困難。
測試都是僅僅基于 junit 實(shí)現(xiàn)的,那這些測試將非常容易理解,非常容易遷移
測試的問題在子其過度依賴于某個(gè)框架,測試運(yùn)行過程中會執(zhí)行到大量的框架代碼,從而導(dǎo)致測試運(yùn)行緩慢,出錯(cuò)了也不好定位問題。
