軟件開發是一門工程技術，其中任何一個技術或技能如果孤立地看都會是管中窺豹，只見一斑。任何一個作者在寫書時都有一些前提和細節，然而經常是要不作者沒說清楚，要不讀者直奔主題而忽略了這些前提和細節，結果是東施效顰，適得其反，照貓畫虎不成反類犬。
我在和很多人交流重構的時候發現，大家非常注重重構的結果，即重構前後的代碼是什麼樣的，但會忽略重構的姿勢。
高手重構的姿勢
老馬在書中強調頻繁且小步地進行重構："犯錯誤是很容易的，至少我很容易犯錯誤……重構技術是以微小的步伐修改程序，如果你犯下錯誤，很容易便可發現……真的犯錯後，只考慮一個很小的改動範圍，這使得查錯和修復問題易如反掌，如果我改動了太多的東西，犯錯時就可能陷入麻煩的調試，併爲此耗費大把時間。小步修改，以及它帶來的頻繁的反饋，正是防止混亂的關鍵“。
這個重構的過程可以用下圖表示：
"這就是重構過程的精髓所在，小步修改，每次修改後就運行測試"。
然而，我們大部分人做不到。
不是我們做不到小步修改。
是我們做不到每次修改後就運行測試。準確的說是無法做到每次修改後運行充分的測試，這成本太高了。要做到這一點，除非修改部分的代碼有充分的自動化單元測試代碼覆蓋。然而，我見過的大部分工程中，單測代碼少的可憐。所以，我們的重構過程可能是這樣的：
由於測試成本太高，導致以下兩個問題：
重構的步子變大，這樣可以少測試幾次，但步子大了，容易累積錯誤，修改錯誤變得困難
更可怕的是步子大了，累積的錯誤也多，有些錯誤不容易及時發現，會在某個節點暴雷，如果是提測後上線前還算幸運，但如果是在上線後暴雷，重構的罪過就大了
所以，結論是，對一般人來說，重構非常危險。
給普通人的建議
如果做不到自動化單元測試覆蓋，但爲了避免危險，建議就是：不要對已經上線的代碼進行重構，甚至，時間點再提前一點，不要在測試之後去重構。
寫一段新的代碼的時候，很難一開始就把代碼寫的很整潔，所以先怎麼舒服怎麼寫，寫的差不多了，能跑通了，這時候，先不要去做全面的人工測試，先去重構，先去整理代碼，整理完後，在做全面的人工測試。這樣可以省下人工迴歸測試的成本。
這是對一般開發人員最實用的重構姿勢。按理想的重構姿勢做，軟件原有功能很少被破壞，所以有非常多的時機做重構，這來源於自動化測試的保障以及這種保障下的小步修改，這些是"防止混亂的關鍵"；但對於實用的重構姿勢，你安全重構的機會只有測試前的這一次。所以，要無比珍惜。
除了這種安全的重構的時機，還有一些相對比較安全的重構，如果你的情懷能支撐你冒一點風險的話。
比如修改一個線上BUG的時候。
首先，有時候重構有助於你改BUG。你根本看不懂那個BUG所處的"屎山"一樣的代碼塊，俗稱"不敢改"，在修復BUG前重構一下可能會幫助你讀懂它，然後你稍微變的敢改了。
其次，由於改一個線上BUG引入的新的BUG後果並不嚴重，我說的不是對系統來說不太嚴重，而是說對改BUG的人。大多數管理者能容忍這種改BUG引入的BUG，但難以容忍只爲了改善代碼可讀性而引入的BUG。
最後，你改完BUG，總得迴歸測試一下吧，包括你自己，包括測試人員。如果引入了新的BUG，測試人員也能承擔一部分責任。
不是教你學壞，實在是沒有辦法，除非你不介意在"屎山"上再貢獻一些自己的力量。這種相對比較安全的重構孰是孰非，難以說清，我個人既不贊成也不反對。
大家還是用好唯一的那一次安全重構的機會吧。
取法乎上得乎其中
我是一個葉公好龍式的書法愛好者，我經常會照着字帖去臨摹，但一直無法達到專業的水準。
有一次我看到老師教孩子寫隸書，講的是"蠶頭燕尾" 筆法，一個筆畫被拆的特別細，完全是一個技術活，沒有一點寫字的樂趣。但我從中明白了我無法達到專業的水準的原因。
但知道和做到還是有一段距離的，我依然無法靜下心練這些筆法，我還是喜歡隨意地按字帖去臨摹。
我知道永遠也達不到專業的水準了，但這些臨摹確實讓我的字變得比以前好看了。
對於大部分人來說，重構也是這樣。
取法乎上得乎其中。