你如何決定代碼的哪個部分應該被整合/重構？

Question

您是否使用任何度量標準來決定代碼（類，模塊，庫）的哪些部分應該被整合或重構？

Answer 1

我不使用任何可以自動計算的指標。

我使用code smells和類似的啓發式來檢測錯誤的代碼，然後我會立即修復它，只要我注意到它。我沒有任何檢查問題的清單 - 大多數人都覺得「這段代碼看起來很亂」，然後推斷爲什麼它很混亂並找出解決方案。簡單的重構，比如給一個變量賦一個更具描述性的名字或者提取一個方法只需要幾秒鐘。更強化的重構，比如提取一個類，可能需要花費一兩個小時的時間（在這種情況下，我可能會留下一個TODO註釋並在稍後重構它）。

我使用的一個重要啓發是Single Responsibility Principle。它使這些類很好地結合在一起。在某些情況下，我使用代碼行中的類的大小作爲啓發式，以便更仔細地查看一個類是否有多重責任。在我的current project中，我注意到在編寫Java時，大多數類的長度都不會超過100行，而當大小接近200行時，類會執行許多不相關的事情，並且可能會將其分開，因此以獲得更有針對性的凝聚力課程。

Answer 2

我們使用Cyclomatic_complexity來標識接下來需要重構的代碼。

Answer 3

我使用Source Monitor，並且在複雜性度量值超過8.0時常規重構方法。

Answer 4

每次我需要添加新功能時，我都會搜索已經存在的類似的代碼。一旦我找到這樣的代碼，我想重構它來解決原來的任務和新的任務。當然，我不打算每次重構 - 我經常重複使用代碼。

Answer 5

我通常只重構「按需」，即如果我看到代碼的具體的直接問題。

通常當我需要實現新功能或修復一個bug，我發現代碼目前的結構，使這個困難，如：

• 太多的地方，因爲複製&粘貼的改變
• 不合適的數據結構
• 硬編碼的東西需要改變
• 方法/班太大理解

然後我會重構。

我有時會看到似乎存在問題的代碼以及我想要更改的代碼，但是如果該區域目前尚未處理，我就會抵制這種衝動。我看到重構是未來驗證代碼和做不真正產生任何即時價值的事情之間的一種平衡。因此，除非我看到具體的需求，否則我通常不會重構。

我想聽聽那些重構作爲日常事務的人的經驗。你如何阻止自己拋光以至於你失去了重要功能的時間？