手頭上有：
1.你永遠沒有時間做到這一點。
2.「上下文切換」在精神上非常昂貴（難以讓你在中間做什麼）。
3.通常不是一件容易的事。
4.總會有人擔心你會破壞正在工作的東西。什麼時候重構代碼？
另一方面：
1.使用該代碼容易出錯。
2.隨着時間的推移，您可能會意識到，如果您第一次看到代碼時重構了代碼，那麼從長遠來看，這將節省您的時間。
所以我的問題是 - 實際上 - 你什麼時候決定是時候重構你的代碼？
謝謝。
我看到的最常見的錯誤之一是人們將「重構」與「大變化」聯繫在一起。
重構代碼並不總是很大。即使是很小的變化，例如將bool更改爲適當的枚舉，或者將方法重命名爲更接近實際功能與意圖也是重構代碼。除了一個里程碑的結束之外，我每次登記時都會嘗試至少進行一次非常小的重構。您會驚訝於這會在代碼中產生明顯的差異。
更大的變化確實需要更大的規劃。我嘗試在正常開發週期中每兩週安排一次，每半周進行一次，以解決更大的重構變化。這是足夠的時間來對代碼庫進行重大改進。如果重構失敗，那麼每天1/2的損失並不算什麼。而且它幾乎不會造成全面損失，因爲即使重構失敗，也會教你一些關於你的代碼的東西。
+1：引用奶奶貝克 - 「如果它聞起來，改變它。」 – 2010-10-22 22:14:23
@donroby，馬丁福勒實際上不是嗎？當然，兩者都可以發明這種說法，但至少我認爲我已經在重構中首先閱讀了它。 – 2010-10-22 22:18:33
+1進行氣味測試。 – 2010-10-22 22:25:29
這聽起來像一個笑話，但說真的，當事情「變得一團糟」我只重構。當一個簡單的任務開始需要更多的時間和通常的時候，當我不得不扭動我的腦海以記住什麼功能在做什麼等等。另外，如果代碼開始運行緩慢，並且不是因爲我運行在開發環境（很多變量輸出等），如果我無法優化它，我重構代碼。正如你所說，從長遠來看它是受到嘲弄的。
不過，我總是確保在開始之前我有足夠的時間來思考問題，所以我沒有進入這個位置。
乾杯！
我不同意。這種態度是什麼導致你沒有時間重構的情況。把它關掉，直到它真的很痛 - 然後，它傷害太多。相反，通過一些小步驟不斷重構，始終保持代碼比開始時更好 - 然後代替「變得雜亂」，代碼將「變得乾淨」。 – 2010-10-23 14:42:04
@Carl Manaster這真的取決於你「弄亂」的理解。我所說的或多或少都在第一個答案的範圍內，只是從來不知道這裏有一個名字。除非我沒有時間重構，否則我從不放棄它。關於小步驟，我認爲它們是必要的，但是像我改變變量類型或方法的小東西在我看來並不是真正的重構。重新思考更大規模的課程和方法時，重構就會到位，但那可能只是我。 – Claudiu 2010-10-23 14:46:57
我建議你閱讀Martin Fowler的書，他在那裏爲術語「重構」提出了一個細緻而清晰的定義。這也是您可以在哪裏找到「改變它聞起來」的報價。我使用他的定義，並且非常清楚地包括重構與重命名方法一樣微不足道。你說這些東西不是在「你的意見」中重構，這很好，但是從一個像他這樣的重要術語的精心佈置的標準參考定義開始工作，可以幫助我們進行更有成效的討論。 – 2010-10-23 15:08:34
我開始重構一旦我發現我重複我的自我。乾燥原則ftw。另外，如果方法/函數的時間太長，或者它們看起來很笨重，或者它們的目的被函數的長度所掩蓋，我會將它分解成私有的子函數，以解釋實際發生的事情。最後，如果一切正常並且正在運行，並且代碼速度很慢，爲了提高性能，我開始考慮重構。
+1，但我建議分離重構和優化的概念。 – TrueWill 2010-10-22 22:20:27
可能，但是我真的在一些真棒和優雅的重構上取得進展的情況往往是由於性能增強的刺激。特別是在遺留代碼的情況下。 – Gopherkhan 2010-10-22 23:51:23
我平時重構當以下條件之一爲真：
重構代碼當需要重構的方式審美不滿。我尋找的一些症狀：
在一般情況下，無設計和/或不太清楚的要求，意味着更oppurtunities進行重構。
當實現一項新功能時，我經常會注意到，如果我正在處理的代碼以不同的方式構建，那麼任務會更簡單。在這種情況下，我通常會退後一步，嘗試首先進行重構，只有在完成此操作後，我才能繼續實現新功能。
我也有一種習慣，可以跟蹤筆記或錯誤跟蹤器中出現的所有潛在改進。這些想法在那裏烘烤了一段時間，其中一些不再那麼引人注目，而合理的想法是在一天中執行的，我專心致力於較小的任務。
一對夫婦的意見：
在手： 1.你從來沒有時間去做。
如果你把重新分解的東西從編碼（而不是體面編碼的固有部分）分開，如果你不能管理時間，那麼是的，你永遠不會有時間上的方便。
- 「上下文切換」是精神上貴（難以離開你在它的中間做什麼）。
請參閱上面的上一點。重構是良好編碼實踐的一個活躍組成部分。如果將兩者分開，就好像它們是兩項不同的任務一樣，那麼1）您的編碼實踐需要改進/成熟; 2）如果您的代碼嚴重需要重構（即代碼質量），則將進行嚴重的上下文切換。 ）
- 這通常不是一件容易的事。
僅當您生成的代碼不適合重構。也就是說，代碼難以重構表現出下列的一種或多種（列表不是普遍含）：
- 總是有恐懼，你會打破東西是現在的工作。
測試？驗證？分析？在進入源代碼控制之前（以及在交付給用戶之前），這些都是？
另一方： 1.使用該代碼是容易出錯。只有
如果從未測試/驗證和/或如果存在的在其下可能容易出錯代碼可接受操作條件和使用方式沒有明確的認識。
- 隨着時間的推移，你可能會意識到，如果你會重構代碼的 你第一次看到它 - 這將對您節省時間的長遠之計。
該實現不應該隨着時間發生。良好的工程和職業道德要求在工件（硬件或軟件）正在製造時實現這種實現。
所以我的問題是 - 實際上 - 你什麼時候決定是時候重構你的代碼？
實際上，當我編碼;我發現一個需要改進的領域（或者需求或期望發生變化後需要改進的領域）;我有機會在不犧牲期限的情況下改進它。如果在那一刻我不能重新考慮因素，我只需記錄下所發現的缺陷，並創建一個可行的，現實的計劃來重新構建重構的工件。
在現實生活中，會有一些時刻我們會編寫一些醜陋的kludge來讓事情繼續下去，或者因爲我們耗盡，疲憊或者其他任何事情。這是現實。我們的工作是確保這些事件不會堆積並無人看管。關鍵在於在編碼時重構代碼，保持代碼簡單並且具有優良，簡單和優雅的結構。 「優雅」我並不是指「聰明屁股」或深奧的，而是顯示通常被認爲是可讀，簡單，可組合的屬性（以及實際應用時的數學屬性）。
良好的代碼適用於重構;它顯示出很好的指標;其結構類似於computer science function composition和mathematical function composition;它有明確的責任;它使它的不變量，前後條件明顯;等等等等。
希望它有幫助。
+1爲綜合答覆，但現在的代碼，沒有考慮到你提到的大多數標準，我真的沒有時間（ - :(我不是那個人寫的） 。我的意思是提出這樣的問題 - 什麼時候它變得如此難以忍受，以至於你決定必須重構它，儘管時間（和其他）受到限制 – 2010-10-22 22:37:53
@Oren - Ouch，你似乎處在一個狹窄的角落裏，當它變得難以忍受時你會花費大量的時間去嘗試正確地實現一個變更，並且你也花費大量的時間來確定這個變更是否會破壞別的東西如果退化發生的可恢復性以外的話，重構不是一個可行的選擇可悲的是，當不加限制時，熱力學第二定律（熵）也適用於軟件，當發生這種情況時，我們必須承擔它，重寫它或者離開另一份工作（因爲做這種「長期」 。） – 2010-10-22 22:50:07
@Oren - 理想情況下，變化的成本應該是可以預測的，並且與變化的大小成正比。平均而言，一個統一的需求變更應該觸發一個可預測大小的代碼變更（從而導致成本）。每隔一段時間需要一次。更改可能會觸發非常大的代碼更改（或更改大小不容易預測）。這很好。當你永遠無法可靠地預測變更的成本（根據可預測的和成比例的代碼變更），那麼事情變得「難以忍受」......因爲你不會完全知道你在每次變更請求時會得到什麼：/ – 2010-10-22 22:55:46
Martin Fowler在他的book中，如果同一個名字建議您在第三次進入另一個代碼塊進行另一次更改。第一次在塊中，你碰巧注意到你應該重構，但沒有時間。第二次回來...同樣的事情。第三次回到現在重構。另外，我讀過當前Smalltalk版本（我認爲是squeak.org）的開發人員說，他們經歷了幾周的激烈編碼......然後他們退後一步，看看可以重構的東西。 就我個人而言，我必須抵制重編碼的衝動，因爲我編碼或者「癱瘓」。
可能重複的[你什麼時候重構代碼？]（http://stackoverflow.com/questions/971863/when-do-you-refactor-code） – 2010-10-22 22:00:18
當俚語對科技字的比例超過N，Where N是一個取決於當地文化和項目難度的實驗確定的值。 – 2010-11-10 01:37:15