你如何重構？

Question

我想知道其他開發人員如何開始重構。你的第一步是什麼？如果你重構了不屬於你的代碼，這個過程（重構）有什麼不同？你在重構時寫測試嗎？

Answer 1

1. 不重構任何不平凡的，不已經有單元測試
2. 編寫單元測試，然後重構
3. 重構小塊，然後重新運行測試經常
4. 停止重構代碼時幹^*乾淨

^* DRY =不要重複自己

Answer 2

對我來說，首先要確保代碼符合我們辦公室的所有最佳實踐。例如，對我們的Perl腳本使用strict，warnings和taint。

如果有efficienry或速度的煩惱集中在他們身上。 像找到一個更好的算法，或找到一個更好的方法來做什麼quadruply嵌套for循環正在做的事情。

而最後看是否有一種方法可以使代碼更易讀。這通常通過將5個執行類似事情的小腳本轉換爲1個模塊（類）來完成。

Answer 3

我重構，同時編寫新的代碼，使用單元測試。我還會重構舊代碼，如果方法太長，或者變量命名不正確，或者我認爲重複等，我的舊代碼或我的或別人的代碼都會重構。

Answer 4

開始獲取單元測試，然後使用自動重構工具。如果重構不能自動化，那麼它不是真正的代碼機械轉換，所以不是重構。單元測試是爲了確保您真的只是在執行從一個代碼庫到等效代碼的機械轉換。

Answer 5

我把廢話，使其不那麼糟糕。 :-)

重視。我不重構創建新功能。重構發生在新東西之前。如果沒有測試，我會寫測試以確保我不會因爲重構而破壞任何東西。如果有測試，我使用這些。如果測試不夠，我可能會寫更多的測試，但我會認爲這與重構是分開的，並且首先要做。

對我來說，第一步是注意到我可以抽象出一些東西並使其更加通用（並且在其他需要現在功能的地方很有用），或者我注意到某些東西不好，可能更好（主觀）。沒有理由，我不會重複概括性。適用YAGNI principle。

我們擁有共同所有權的概念，使代碼始終是我的 - 我可能不會寫，但我不認爲重構時。如果目的不明確，我可能會試圖理解一些事情，然後再決定是否需要重構 - 儘管這幾乎總是一個重構的原因。

Answer 6

重構沒有單元測試是危險的。始終有單元測試。如果你在沒有良好的測試的情況下改變某些東西，你可能對代碼的某些部分是安全的，但其他地方的東西可能不會有相同的行爲使用單元測試可以保護所有變更。

重構其他代碼也很好，但極端不是。別人不像你這樣編程是正常的。改變東西並不「友好」，因爲你會以其他方式做到這一點。只需重構，如果真的有必要。

Answer 7

我刪除重複，它統一了代碼中固有的思維模式。重構需要實現這兩件事情。如果你有兩次執行同​​樣的事情的代碼，將它重構到一個普通的位置，統一抽象。如果你在三個地方有相同的字面量，就把它固定在一個常數上，統一目的。如果您擁有相同的參數組，請確保它們始終以相同的順序使用，或者更好地將它們放在一個通用結構中，統一信息組。

Answer 8

讀Martin Fowler的書‘Refactoring’

順便說一句 - 這就是Martin Fowler的自己亞馬遜高管鏈接，如果你想知道:)

Answer 9

我同意其他海報當你重構你的代碼中寫道。

如果它是你沒有寫的代碼，尤其是如果有很多代碼的話，我會先用fxCop，Visual Studio的代碼分析，DevPartner等工具開始 - 我確信還有其他很好的代碼。他們會告訴你從哪裏開始以及最常見的編碼問題。我也會做壓力測試，看看瓶頸在哪裏，因此你在改進代碼方面的努力可以獲得最大的回報。

我喜歡重構我的代碼，但它可能過分。如果你沒有真正提高應用程序的性能，或者嚴重提高代碼的可讀性，你應該停下來。重構時總會有引入新bug的可能性，尤其是如果你沒有進行單元測試的話。

Answer 10

取決於我的目標。如前所述，您需要進行單元測試以確保您的重構沒有破壞任何東西，並且如果需要，您必須花時間修復它。對於很多情況，我測試現有的解決方案，如果它工作，將其包裝而不是重構它，因爲這可以最大限度地減少中斷的可能性。

如果我不得不重構，例如我最近不得不將一堆基於ASCII的C++移植到UNICODE，我傾向於確保在最終用戶和單元級別都有很好的迴歸測試。同樣，我嘗試使用工具而不是手動重構，因爲這樣做不太容易出錯，而且您得到的錯誤是系統的而不是隨機的。

Answer 11

我更不願意重構他人編寫的代碼，而不是重構我自己的代碼。

如果它是由我的一位前任編寫的，我通常只會在函數中重構。例如。我可能會用開關替換if語句。任何比這更大的東西通常超出範圍，並且不在預算範圍內。

對於我自己的代碼，當我寫東西時，通常會重構，只要有東西看起來很醜或開始聞起來。現在修復它很容易，而不是等待它導致問題。

Answer 12

你的第一步是什麼？

第一步是運行單元測試以確保它們全部通過。事實上，如果您在修改代碼之前已經損壞了之前，那麼您可能會浪費大量時間尋找您的哪些更改破壞了測試。

如果你重構的代碼不是你的，這個過程有什麼不同？

我當然在重構代碼的時候做的步驟比較小，我沒寫（或者我很久以前寫的代碼）。我也可以在進行之前驗證測試覆蓋率，以避免依賴總是通過的單元測試......但是這不會測試我正在工作的區域。

你在重構時編寫測試嗎？

我通常不這樣做，但我可能會增加在下列情況下新的測試（名單並不詳盡）：在我的腦海一個新的測試閃光的

• 想法（「發生什麼如果。 ？..」 - 寫 測試就知道了）
• 在測試覆蓋率

也要看正在執行的重構發現孔。當提取函數時，如果可以像以前那樣調用不同的方法，我可以創建一個新的測試。

---

這裏有一些一般性的建議：

第一件事情就是保持對代碼的工作，同時注意到code smells的列表。這可以讓你的頭腦免於回憶代碼中看到的內容。

當單元測試沒有完全通過時，黃金法則永遠不會重構。

重構當代碼是穩定的，你知道會被未來的重構受到影響，之前整合所有以上之前說你做增加一些之前。

在沒有單元測試的情況下，您必須將您想要重構的部分代碼放在測試中。如果單元測試太難改造，通常情況下，您可以按Michael Feathers in Working Effectively with Legacy Code的建議創建characterization tests。簡而言之，它們是端到端的測試，可以讓您確定代碼的當前行爲（不會始終保持完美）。

不要害怕做寶貝步驟。不要同時做兩件事。如果您想要重構某些內容，請記下它，即使看起來很簡單，也不要立即修復它。

經常檢查，當測試通過。這樣你就可以恢復一個糟糕的重構，而不會丟失之前完成的工作。

請記住，重構不會爲您的客戶增加價值（這可以進行討論），但客戶不會付錢給您重構。一個經驗法則是在對代碼進行更改或添加新功能之前進行重構。

Answer 13

第一步：確定一個code smell.

第二步：考慮替代實現，什麼權衡是和我在條款接受這些是「更好」。

第三步：實施更好的解決方案。

如果代碼是我的或沒有的話，這並沒有什麼不同，因爲有時候我可能會回過頭來看看我寫的幾個月或幾年前的代碼，它會看起來像其他人的代碼。如果我正在編寫新方法或者沒有足夠的測試代碼，IMO可能會編寫測試。

Answer 14

一般方法

我可以通過從鳥瞰圖軟件（組件）偷看開始了。依賴分析和圖形工具在這裏很有幫助（參見後面的章節）。我在包級別或類級別的依賴關係中查找一個圓圈，也可以查找具有太多依賴關係的類別。這些是重構的好選擇。

• Python
• Java