重構：高手的姿式你學不會

軟件開發是一門工程技術，其中任何一個技術或技能若是孤立地看都會是管中窺豹，只見一斑。任何一個做者在寫書時都有一些前提和細節，然而常常是要不做者沒說清楚，要不讀者直奔主題而忽略了這些前提和細節，結果是東施效顰，拔苗助長，照貓畫虎不成反類犬。

我在和不少人交流重構的時候發現，你們很是注重重構的結果，即重構先後的代碼是什麼樣的，但會忽略重構的姿式。

高手重構的姿式

老馬在書中強調頻繁且小步地進行重構："犯錯誤是很容易的，至少我很容易犯錯誤……重構技術是以微小的步伐修改程序，若是你犯下錯誤，很容易即可發現……真的犯錯後，只考慮一個很小的改動範圍，這使得查錯和修復問題易如反掌，若是我改動了太多的東西，犯錯時就可能陷入麻煩的調試，併爲此耗費大把時間。小步修改，以及它帶來的頻繁的反饋，正是防止混亂的關鍵「。

這個重構的過程能夠用下圖表示：

"這就是重構過程的精髓所在，小步修改，每次修改後就運行測試"。

然而，咱們大部分人作不到。

不是咱們作不到小步修改。

是咱們作不到每次修改後就運行測試。準確的說是沒法作到每次修改後運行充分的測試，這成本過高了。要作到這一點，除非修改部分的代碼有充分的自動化單元測試代碼覆蓋。然而，我見過的大部分工程中，單測代碼少的可憐。因此，咱們的重構過程多是這樣的：

因爲測試成本過高，致使如下兩個問題：

重構的步子變大，這樣能夠少測試幾回，但步子大了，容易累積錯誤，修改錯誤變得困難

更可怕的是步子大了，累積的錯誤也多，有些錯誤不容易及時發現，會在某個節點暴雷，若是是提測後上線前還算幸運，但若是是在上線後暴雷，重構的罪過就大了

因此，結論是，對通常人來講，重構很是危險。

給普通人的建議

若是作不到自動化單元測試覆蓋，但爲了不危險，建議就是：不要對已經上線的代碼進行重構，甚至，時間點再提早一點，不要在測試以後去重構。

寫一段新的代碼的時候，很難一開始就把代碼寫的很整潔，因此先怎麼舒服怎麼寫，寫的差很少了，能跑通了，這時候，先不要去作全面的人工測試，先去重構，先去整理代碼，整理完後，在作全面的人工測試。這樣能夠省下人工迴歸測試的成本。

這是對通常開發人員最實用的重構姿式。按理想的重構姿式作，軟件原有功能不多被破壞，因此有很是多的時機作重構，這來源於自動化測試的保障以及這種保障下的小步修改，這些是"防止混亂的關鍵"；但對於實用的重構姿式，你安全重構的機會只有測試前的這一次。因此，要無比珍惜。

除了這種安全的重構的時機，還有一些相對比較安全的重構，若是你的情懷能支撐你冒一點風險的話。

好比修改一個線上BUG的時候。

首先，有時候重構有助於你改BUG。你根本看不懂那個BUG所處的"屎山"同樣的代碼塊，俗稱"不敢改"，在修復BUG前重構一下可能會幫助你讀懂它，而後你稍微變的敢改了。

其次，因爲改一個線上BUG引入的新的BUG後果並不嚴重，我說的不是對系統來講不太嚴重，而是說對改BUG的人。大多數管理者能容忍這種改BUG引入的BUG，但難以容忍只爲了改善代碼可讀性而引入的BUG。

最後，你改完BUG，總得迴歸測試一下吧，包括你本身，包括測試人員。若是引入了新的BUG，測試人員也能承擔一部分責任。

不是教你學壞，實在是沒有辦法，除非你不介意在"屎山"上再貢獻一些本身的力量。這種相對比較安全的重構孰是孰非，難以說清，我我的既不同意也不反對。

你們仍是用好惟一的那一次安全重構的機會吧。

取法乎上得乎其中

我是一個葉公好龍式的書法愛好者，我常常會照着字帖去臨摹，但一直沒法達到專業的水準。

有一次我看到老師教孩子寫隸書，講的是"蠶頭燕尾" 筆法，一個筆畫被拆的特別細，徹底是一個技術活，沒有一點寫字的樂趣。但我從中明白了我沒法達到專業的水準的緣由。

但知道和作到仍是有一段距離的，我依然沒法靜下心練這些筆法，我仍是喜歡隨意地按字帖去臨摹。

我知道永遠也達不到專業的水準了，但這些臨摹確實讓個人字變得比之前好看了。

對於大部分人來講，重構也是這樣。

取法乎上得乎其中。

讀者福利：

分享免費學習資料

針對於還會準備免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料） 爲何某些人會一直比你優秀，是由於他自己就很優秀還一直在持續努力變得更優秀，而你是否是還在知足於現狀心裏在竊喜！但願讀到這的您能點個小贊和關注下我，之後還會更新技術乾貨，謝謝您的支持！

資料領取方式：加入Java技術交流羣963944895，私信管理員便可免費領取