你应该多久重构一次？
几周前我和一些同事就重构进行了一次讨论，而且我认为less数人认为“早期重构，经常重构”是一个很好的方法，可以防止代码变得混乱和不可维护。 其他一些人认为它只属于一个项目的维护阶段。
如果你有意见，请捍卫它。
就像你说的：早期重构，经常重构。
尽早重构意味着必要的改变在我心中仍然是新鲜的。 重构通常意味着变化趋于更小。
延迟重构只会导致一团糟，进一步使重构变得更加困难。 清理一旦我注意到混乱，防止它build立起来，成为一个问题后。
只要function正常（所有testing通过），我都会重构代码。 这样我清理它，而在我的脑海中仍然是新鲜的，在别人看到第一个版本是多么丑陋之前。
每次触摸一段代码后，我通常会重新初始化检查。 重构不是你应该单独留出的时间。 这应该是你正在做的事情。
你用两个帽子写代码。 戴上帽子，戴上我明白的明天帽子。 显然第二个帽子是重构的。 所以，每当你做了一些工作，但不得不重复的代码，长方法，脆弱的error handling，坏的variables名称等气味（不可避免地）
重构，而试图得到的东西工作（即戴两顶帽子）是不切实际的非平凡的任务。 但是推迟重构直到第二天/周/迭代是非常糟糕的，因为问题的上下文将会从你的头上消失。 所以尽可能多地在帽子之间切换，但不要把它们组合起来。
我重构每一个机会，因为它让我磨练我的代码到最好的状态。 即使在积极开发时也要这样做，以防止首先产生不可维护的代码。 它也经常让我在一个糟糕的devise决定变得不可修复之前。
重构三个很好的理由：
- 你的原始devise（可能在一个非常小的区域，但devise仍然是错误的）。 这包括您发现常见操作的位置，并希望共享代码。
- 你正在迭代devise。
- 代码非常糟糕，需要进行大规模的翻新。
三个不重构的好理由：
- “这看起来有点乱。”
- “我不完全同意最后一个人这样做”。
- “这可能更有效率”。 （这个问题有'可能'）。
“凌乱”是有争议的 – 有一个有效的论点，被称为“修理破窗户”，或“代码卫生”，这表明，如果你让小东西滑动，那么你就会开始让大的东西滑动。 没关系，记住这是件好事，但请记住，这只是一个比喻。 为了寻求最干净的解决scheme，这并不是无可奈何的理由。
你重构的频率应该取决于好的理由发生的频率，以及你的testing过程如何保证你不会引入错误。
重构本身从来不是一个目标。 但是，如果某件事不起作用，就必须加以修正，而且在维护过程中也是如此。 对于非平凡的变化，重构几乎总是比较好，并且整洁地结合新的概念，而不是用一大堆垃圾来修补一个地方，以避免其他地方发生任何变化。
对于什么是值得的，我认为没有任何改变接口的地方，只要我掌握了使用它的内容，并且结果变化的范围是可以pipe理的。
我试着按照这个格言去做：把你所碰到的所有代码都保留下来。
当我修复或添加function时，我通常会利用这个机会对受影响的代码进行有限的重构。 通常这使得我更容易做出预期的改变，所以它实际上不会花费任何东西。
否则，你应该为重构预算专门的时间，如果你不能，因为你总是在扑火（我想知道为什么），那么你应该强迫自己重构，当你发现做出改变比应该更难，当“代码味道”只是无法忍受。
很多时候，当我清理出想法的时候，我的代码开始非常紧密地混杂在一起。 当我开始打磨这个想法时，逻辑分离开始变得越来越清晰，我开始重构。 这是一个持续不断的过程，每个人都认为应该“早期和经常”完成。
正如书中所说，你重构的时候
- 你添加一些代码…一个新的function
- 当你修复一个错误/缺陷
- 当你与多个人进行代码审查
- 当你发现自己第三次复制的东西.. 3罢工规则
我重构的时候：
我正在修改代码，我很困惑。 如果我花了一段时间来筛选出来，它需要重构。
我正在创build新的代码，并得到它“工作”。 通常情况下，我会做事情的工作，而我正在编码，我意识到“嘿，我需要重做我做了20线，只有一些改变”。 那时我重构并继续。
在我看来，唯一阻止你这样做的是时间限制。 不pipe喜不喜欢，有时候你都没时间去做。
这就像国家公园 – 总是让它比你find的好一点。
对我来说，这意味着每当我打开代码，不得不挠头去弄清楚发生了什么，我应该重构一些东西。 我的主要目标是可读性和理解。 通常它只是为了清晰而重命名一个variables。 有时候，它正在提取一种方法 –
例如（微不足道），如果我碰到
temp = array[i]; array[i] = array[j]; array[j] = temp;
我可能会用swap（i，j）方法replace它。
编译器可能会内联它，swap（）会在语义上告诉每个人发生了什么事情。
这就是说，用我自己的代码（从头开始），我倾向于重构devise。 我经常发现在一个具体的课堂上工作比较容易。 当它完成和debugging，然后我将拉动旧的Extract Interface技巧。
我会把它交给一个同事来重构可读性，因为我太接近代码来注意漏洞了。 毕竟，我知道我的意思。
重构机会！ 只要它很容易就可以做到。
如果重构是困难的，那么你在错误的时间（当代码不需要的时候）或代码的错误部分（在其他地方有更好的效率的地方）这样做。 （或者你现在还不擅长重构）
保存重构“维护”是一个重言式。 重构是维护。
每次我读任何东西都会重构，并且可以使其更具可读性 。 不是重大的重组。 但是如果我自己想“这份List包含什么？哦， Integer ！” 那么我会把它改成List<Integer> 。 另外，我经常在IDE中提取方法，将几行代码放在一个好的名字上。
每次遇到需求 至less当你要改变一段需要重构的代码的时候。
答案总是，但更具体地说：
- 假设你为每个任务分支，然后在每个新分支进行QA之前进行分支。
- 如果你在干线里开发所有的东西，那么在每次提交之前。
- 在维护旧代码时，使用上述代码来完成新的任务，而对于旧的代码，可以在主要版本上进行重构，以获得额外的QA。
我将重构本地化为与当前任务相关的代码。 我试图在前面做我的重构。 我从functionangular度分开进行这些修改，与实际任务无关。 这样代码更清洁，修订历史也更清晰。
持续，在合理的范围内。 你应该一直在寻找改进软件的方法，但是为了避免重构（Refactorbation），你必须小心避免重构。
如果你可以做一个重构的代码，使代码更快，更容易阅读，更容易维护或更容易或为业务提供一些其他的价值，我说去吧！
“早期重构，经常重构”是一个富有成效的指导方针。 尽pipe这种假设你确实知道代码。 系统越老，重构就越危险，需要更多的思考。 在某些情况下，重构需要被pipe理的任务，努力水平和时间估计等等。
如果你有一个可以安全地进行修改的重构工具，那么当代码编译的时候 ，如果代码更清晰，你就应该重构。
如果你没有这样的工具， 只要testing是绿色的 ，你应该重构，如果它会使代码更清晰。
做一些小改动 – 重新命名一个方法，使其更清晰。 提取一个类，使一组相关variables明确相关。 重构不是要做大的改变，而是要一分一秒地让事情变得更清晰。 重构是每餐后清理你的菜肴，而不是等到每个表面都被肮脏的盘子覆盖。
绝对一旦看起来合适。 如果你不痛苦的话。
从切换到Squeak（我现在似乎提到每一篇文章）之后，我意识到，在原型devise过程中，很多devise问题都会消失，因为在该环境中重构非常简单。 说实话，如果你没有一个重构的环境基本上是无痛苦的，我build议你试着吱吱嘎嘎，知道它可能是什么样子。
重构通常可以节省一天，或者至less一些时间。 有一个项目是我正在研究的，在我们达到某个里程碑后，我们重构了所有的代码。 这是一个很好的方法，因为如果我们需要将代码解压出来，这已经不再有用，那么就可以更容易地修补我们需要的任何新东西。
我们现在正在讨论这个问题。 我们或多或less地同意“写出来，然后修复”。 但从时间的angular度来看我们有所不同。 我更“马上修好”，我的同事更多的是“下一次修复”。
一些引用他的话：
Douglas Crockford，高级Javascript架构师雅虎：
每7次冲刺重构。
肯·汤普森（unix man）：
代码本身几乎烂了，它会被重写。 即使没有什么变化，由于某种原因它腐烂了。
我希望一旦完成任务，提交的代码就可以在2个月后回来，并且认为“是的，我在这里performance很好”。 我不相信很容易找回时间回来修复它。 相信这从我的angular度来说有些天真。
编辑：拼写错误
我想你应该重构一些东西，当你正在做一部分的时候。 意思是，如果你必须增强functionA，那么你应该重构之前（和之后？）。 如果你对这个function不做任何事情，只要你还有别的事情要做，就把它保留下来。
不要重构系统的一个工作部分，除非你已经改变了它。
关于这个话题有很多观点，有些与特定的方法或发展方法有关。 在使用TDD时，如你所说，早期和经常重构是一种有利的方法。
在其他情况下，您可能需要时重构。 例如，当你发现重复的代码。
当采用更详细的前期devise的传统方法时，重构可能会更less。 不过，我会build议不要在重build项目结束之前进行重构。 您不仅可能会引入问题，潜在的后UAT，通常情况下，重构逐渐变得更加困难。 由于这个原因，经典项目的时间限制会导致重构和额外的testing被丢弃，当维护开始时，你可能已经创build了一个意大利面代码怪物。
如果没有破坏，不要重构它。
我想说重构的时间属于最初的编码阶段，并且可以按照您的喜好经常和多次完成。 一旦它在客户手中，那就变成另一回事了。 你不想为自己“整理”代码而只是为了发现它被装运和打破某些东西而工作。
初次交付重构之后的时间是当你说你会做的时候。 当代码太臭了，然后有一个专门的发布包含重构，可能还有一些更重要的修复。 那样的话，如果你确实发生了什么事情，你知道哪里出了问题，你可以更容易地修复它。 如果你总是重构，那么你将会破坏事物，直到获得了QAd，你才会知道它的破坏，然后你很难弄清楚错误修正/特性代码是否改变了问题，重构你在很久以前执行。
当代码看起来大致像以前一样时，检查cbreaking更改就容易多了。 重构很多的代码结构，你可以使它成为不可能的，所以只有当你真正意义的重构。 像对待任何其他产品代码一样对待它，你应该没问题。
我认为这个100个WordPress的博客文章可能有一些很好的build议。 http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/
