几周前，我与一些同事就重构问题进行了讨论，但似乎只有少数人认为"尽早重构，经常重构"是防止代码混乱和难以维护的好方法。许多其他人认为它仅属于项目的维护阶段。

如果我们有意见，请辩护。

解决方案

就像我们说的：尽早重构，经常重构。

尽早进行重构意味着必要的更改仍在我的脑海中浮现。重构通常意味着更改趋向于变小。

延迟重构只会导致一团糟，这进一步使重构变得更加困难。一旦我注意到混乱，便进行清理，以防止它堆积起来，并在以后成为问题。

我重构获得的每一个机会，因为它使我可以将自己的代码磨练到最佳状态。即使在积极开发以防止最初创建无法维护的代码时，我也会这样做。通常，这也经常让我弄清一个糟糕的设计决策，然后再将其变为不可修复。

每次遇到需要时。至少在我们要更改需要重构的代码段时。

答案总是，但更具体地说：

• 假设我们为每个任务进行分支，然后在每个新分支上进行质量检查。
• 如果我们在主干中进行全部开发，则在每次提交之前。
• 维护旧代码时，请将以上内容用于新任务，并对旧代码进行主要版本的重构，以获取额外的质量保证。

一旦功能正常(所有测试通过)，我就会重构代码。通过这种方式，我可以在清理它的同时仍保持新的感觉，并且在其他人之前看不到第一个版本的丑陋之处。

初次签入后，通常我每次碰到一段代码时都会进行重构。重构不是我们应该单独留出时间的事情。这应该是我们随手做的事情。

绝对尽其所能。如果不这样做，痛苦就会加剧。

自从改用Squeak(我现在似乎在每篇文章中都提到了)以来，我已经意识到，原型制作过程中的许多设计问题都会消失，因为在这种环境下重构确实很容易。老实说，如果我们没有一个可以轻松进行重构的环境，那么我建议我们尝试吱吱声，以了解它的本质。

就像书上说的那样，我们重构何时

• 我们添加一些代码...一项新功能
• 修复错误/缺陷时
• 当我们与多人一起进行代码审查时
• 当我们发现自己第三次复制某些内容时。.3罢工规则

很多时候，当我提出想法时，我的代码开始都是非常紧密的耦合和混乱的。随着我开始进一步完善这个想法，逻辑上的分离变得越来越清晰，我开始进行重构。这是一个持续不断的过程，并且每个人都建议应该"尽早且经常"进行。

我认为当我们目前正在处理某部分内容时，应该对其进行重构。意味着如果必须增强功能A，则应该在之前(和之后)对其进行重构。如果我们对此功能不做任何事情，那么只要我们还有其他事情要做，就可以将其保持原样。

除非我们已经进行了更改，否则不要重构系统的工作部分。

关于此主题的观点很多，有些观点与特定的开发方法或者方法相关。正如我们所说，在使用TDD时，尽早进行重构通常是一种首选方法。

在其他情况下，我们可以根据需要进行重构。例如，当我们发现重复的代码时。

当采用更传统的方法进行详细的前期设计时，重构的频率可能会降低。但是，我建议在项目结束之前不要离开重构。我们不仅可能会引入问题，甚至可能在UAT之后引入问题，而且通常情况下，重构变得越来越困难。因此，经典项目的时间限制会导致重构和额外的测试被丢弃，并且在进行维护时，我们可能已经创建了意大利面条代码怪兽。

如果它没有损坏，请不要重构它。

我想说重构的时间属于初始编码阶段，我们可以根据需要进行任意多次和多次的重构。一旦掌握在客户手中，那就变成另一回事了。我们不希望自己"整理"代码只是为了发现代码已交付并破坏了某些东西。

从最初交付到重构的时间就是我们说要执行的时间。当代码变得太臭时，请使用一个专门的版本，其中包含重构和一些更重要的修复程序。这样，如果我们碰巧弄坏了某个东西，就知道它出了错，可以更轻松地修复它。如果我们一直都在进行重构，那么我们将无法解决问题，直到获得QAd，我们才知道它已被破坏，然后我们将很难找出错误修正/功能代码的更改是否导致了此问题，或者是某些原因重构我们很久以前执行的操作。

当代码看起来大致像以前一样时，检查重大更改要容易得多。重构很多代码结构，我们可以使其几乎不可能，因此只有在认真考虑时才进行重构。像对待其他任何产品代码更改一样对待它，我们应该可以。

我在以下情况下重构：

我正在修改代码，对此感到困惑。如果花点时间筛选一下，则需要进行重构。

我正在创建新代码，然后将其"运行"起来。通常，我会使事情正常进行，并且在编写代码时，我意识到"嘿，我需要重做我所做的20行，只需要做一些改动"。在这一点上，我重构并继续。

我认为应该阻止我们执行此操作的唯一方法是时间限制。不管你喜不喜欢，有时候你只是没有时间去做。

重构的三个很好的理由：

• 原始设计(也许在很小的区域，但是仍然在设计中)是错误的。这包括我们发现通用操作并希望共享代码的位置。
• 我们正在迭代设计。
• 该代码是如此糟糕，以至于需要进行重大翻新。

不重构的三个很好的理由：

• "这看起来有点混乱"。
• "我不完全同意最后一个家伙做这件事的方式"。
• "这可能会更有效率"。 (这里的问题是"力量")。

"凌乱"是有争议的，有一个有效的论点，被称为"修复破碎的窗户"，或者"代码卫生"，它表明如果让小东西滑动，那么也会开始让大东西滑动。很好，请记住，这是一件好事，但请记住，这是一个类比。它不会为寻找最干净的解决方案而无休止地找东西。

重构的频率应取决于良好原因发生的频率，以及我们对测试过程可以避免引入错误的信心。

重构本身绝不是目标。但是，如果某事不起作用，则必须对其进行修复，并且在初始开发中和在维护中都是如此。对于非平凡的更改，与将单个地方打成一大堆垃圾来修补单个地方以避免在其他地方进行任何更改相比，重构和干净地合并新概念几乎总是更好的选择。

对于它的价值，我认为只要知道使用它的用途并且更改的范围是可管理的，就不要更改任何接口。

我们戴着两个帽子写代码。刚刚得到工作的帽子和我需要了解这个明天的帽子。显然，第二顶帽子是重构帽子。因此，每当我们使某项工作可行时就进行重构，但是(不可避免地)会引入诸如重复代码，冗长的方法，易碎的错误处理，错误的变量名等气味。

在尝试使某些东西正常工作时(例如戴两顶帽子)进行重构对于非平凡的任务来说是不切实际的。但是将重构推迟到第二天/周/迭代是非常糟糕的，因为问题的背景将不复存在。因此，请尽可能多地在帽子之间切换，但不要将它们结合在一起。

就像国家公园一样-总是比我们发现的要好一些。

对我来说，这意味着每当我打开代码并不得不挠头弄清到底是怎么回事时，我都应该重构一些东西。我的主要目标是提高可读性和理解力。通常，为了清楚起见，它只是重命名变量。有时是在提取方法-

例如(琐碎的)，如果我遇到

temp = array[i];
array[i] = array[j];
array[j] = temp;

我可能将其替换为swap(i，j)方法。

编译器可能仍会内联它，而swap()会从语义上告诉每个人正在发生的事情。

话虽这么说，但是用我自己的代码(从头开始)，我倾向于重构设计。
我经常发现在具体课堂上工作更容易。完成并调试后，我将使用旧的Extract Interface技巧。

我将其留给同事重构以提高可读性，因为我离代码太近了以至于无法注意到漏洞。毕竟，我知道我的意思。

我将重构本地化为与当前任务相关的代码。我尝试先进行重构。我分开提交这些更改，因为从功能的角度来看，它与实际任务无关。这样，代码可以更干净地使用，修订历史记录也可以更干净。

我认为这100个Wordpress博客文章可能有一些不错的建议。
http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/

"尽早重构，经常重构"是一条富有成效的准则。尽管这种假设假设我们真的知道代码。系统越旧，重构就越危险，需要进行更多的审议。在某些情况下，重构需要管理的任务，包括工作量级别和时间估计等。

机会重构！只要容易就做。

如果重构很困难，那么我们将在错误的时间(不需要代码的时候)或者在错误的代码部分(在其他地方可以获得更高的效率)进行重构。 (或者我们还不太擅长重构。)

保存重构以进行"维护"是一种重言式。重构就是维护。

我尝试遵循这个座右铭：让我们触摸的所有代码都比过去更好。

当我进行修复或者添加功能时，我通常会利用这个机会对受影响的代码进行有限的重构。通常，这使我进行预期的更改变得更加容易，因此实际上不花任何钱。

否则，我们应该预算专用的重构时间，如果不能这样做，因为我们总是在扑朔迷离(我想知道为什么)，那么当我们发现进行更改变得比原本要困难得多并且出现"代码气味"时，应该强迫自己进行重构。简直难以忍受。

不断地，在合理的范围内。我们应该一直在寻找改进软件的方法，但是我们必须小心，避免为了重构而进行重构的情况(重构)。

如果我们可以提出重构将使一段代码更快，更易于阅读，更易于维护或者更轻松或者为企业提供其他价值的情况，我会坚持的！

重构通常可以节省一天，或者至少节省一些时间。我正在做一个项目，在达到了某个里程碑之后，我们重构了所有代码。这是一个很好的方法，因为如果我们需要删除不再有用的代码，那么它就可以更轻松地修补我们需要的任何新内容。

每当我阅读任何东西时，我都会进行重构，使其更具可读性。没有重大的重组。但是，如果我想自己"此"列表"包含什么？哦，整数！"！然后将其更改为List <Integer>`。另外，我经常在IDE中提取方法，以命名几行代码。

我们正在就此进行讨论。我们或者多或者少地同意"编写它以便使其起作用，然后对其进行修复"。但是我们在时间角度上有所不同。我更"立即修复"，我的同事更"在下一次迭代中修复"。

一些引述他的话：

雅虎高级JavaScript架构师Douglas Crockford：

refactor every 7th sprint.

肯·汤普森(男女皆宜的男人)：

Code by itself almost rots and it's
  gonna be rewritten. Even when nothing
  has changed, for some reason it rots.

我希望完成任务后，可以在2个月内重新提交提交的代码，并认为"是的，我在这里做得很好"。我认为很难找到时间以后再修复它。从我的角度来看，认为这有点天真。

编辑：拼写错误