这一切都从一个简单的任务开始。 我只需要向页面添加一个具有自动完成功能的搜索框。 我开始学习，在我研究代码时，我开始注意到不太整洁的片段。 当我继续工作时，我的大脑开始na我以清理东西。 我继续进行原始任务，但the的声音加剧了。 我告诉自己“好吧，这只是一个快速解决方案，不会对我当前的工作有太大影响。”
几个小时后，我已经对界面下面的许多层进行了重组，我感到很高兴。 我瞥了一眼时钟，只是意识到时间快到了。 我花了一整天的时间进行重构，而在最初的任务上我还是正式落后了。 我现在非常沮丧，今晚我也不会睡得好。
重构是拖延的借口
通常进行重构以提高代码质量。 它有助于我们使代码更易于维护，并且更易于扩展。 它还为我们创造了一个宜人的工作环境，对我来说，这比通常认为的重构最终目标更有价值。 但是，它更经常地成为拖延的另一个原因。
重构之所以如此出色，是拖延的借口，是因为它本质上是不错的。 从长远来看，重构的效果（如果做得正确）甚至可以减少开发所需的时间。 我们可能对自己撒谎：“是的，我现在可以花几个小时来重构代码，因为它将在下周节省我几天的时间。”但这只是我们为自己设置的一个聪明小陷阱。 结果往往像本文引言中所示。 我们最终会吃掉完成我们最初承诺的任务所需的宝贵时间。
如果这是重构的方式，那么您已经知道这是错误的。 至少您对此是正确的。 但是我们该怎么办？
诀窍在于何时
正如我在上一节中所暗示的那样，有一种正确的方法来进行重构。 与其说如何做，不如说何时重构（或什么时候不做）。
当您有重构的欲望时，绝对不是正确的时机。 不要一时兴起地重构。 当您准备好完全专注于重构时，重构应该是一种刻意的动作。 但是，您应该立即做的是在您想重构的代码部分添加一个FIXME注释，或者将其记在书写板或便签上。 它应该很快而不是太详细。 尝试抓住要点，而不涉及要完成的技术方面。
以下注释是您不应执行的操作：
// FIXME：将接下来的4行移至一个单独的模块，并实施
//一个返回对象的工厂，该对象暴露了其中的逻辑
//作为带有`count`和`limit`参数的公共函数。
这个注释的理想状态是：
// FIXME：将此逻辑移至模型层。
作为常规计划的一部分，请分配一些时间专门用于重构。 这可以基于某个事件（例如，“我用X完成后”），某个时间点（例如，“下周的最后两天”）或某种条件（例如，“之后累积了20个FIXME”或“在我可以看到至少3个具体用例之后”）。 只要您认真地考虑一下，如何定义标准就不那么重要了。 我的重构条件通常是“在完成当前任务后，如果我可以看到至少3个具体用例”。
重构作为奖励
到目前为止，所有所说的话都不是什么新奇的东西。 在书上。 转折点在于使用重构作为奖励 。 如果您已经进行了一段时间的编程，那么您可能会想使代码漂亮，正确，甚至很棒。 这种渴望有时可能很大。
我们可以利用这种冲动，并将其用作正常发展的动力。 通过有意地（但在任务完成之前）有意地进行必要的重构，我们将重构作为一种胡萝卜来激励自己继续处理当前的任务。
重构的情况
我刚刚完成了一段代码，在其中我确定了该体系结构的第三个用例对代码很有用。 这是我的提示，即将进行重构。 我迫不及待地想要在那时和那里重构这些层。 我的手指立即滑向会打开文件的组合键，而我不得不在其中修改代码。 相反，我记下了一个FIXME并在我们的团队频道上宣布，一旦完成当前任务，我将立即开始重构。
尽快完成当前任务非常重要，因为团队中的其他成员正在等待代码。 在世界末日上花一两天，对于其他成员来说可能会有些沮丧。 无论大脑多么努力地敦促重构，这显然都不是正确的做法。 同时，我知道我会从中受益匪浅，它将在同一时间为代码库带来很多清晰度。 换句话说，我知道它必须在某个时候完成。 宜早不宜迟。
当我把原先的任务弄乱时，我告诉所有人我将致力于重构两到三天，并询问他们是否还需要我做些其他事情。 提出了一些要求，我还记得另外一项任务，可以迅速完成完成一部已经开放了一段时间的史诗。 知道我即将进入架构清晰的必杀技之后，我专注于处理小任务，并在短期内完成了这些任务，最后给了我当之无愧的重构标志。
当我终于开始重构时，发生了两件事。 我对修改代码的渴望如此之大，以至于我极力去完成它-我完全专注于此任务。 我的潜意识还提出了一些其他改进措施，“当我还在的时候”，以及改进本来要修复的代码的更好方法。 重构的全部工作比我最初想象的要完整得多，并且要简单得多，并且结果完成的时间要短得多-只需一天半，而不是三天。 最终，我感到非常的欣慰和满足，因为克服了这种重构之痒，并且获得了比我预期的更好的结果。
我还要在这里指出，由于我的三个用例规则，我完全拒绝了前两个重构的要求。 这确实有助于我真正地解决问题，并尽可能多地考虑边缘情况。
摘要
作为软件工程工作流，为重构做好准备很有意义。 毕竟，正常的编码是使事情正常进行，而重构阶段是在其中添加修饰，使事情一起正常工作 。 您应该对此部分投入最大的精力和精力是很合乎逻辑的，尤其是在您处于敏捷工作流程中时。 在我看来，从战略上和始终如一地推迟重构是最有效的启动技术。
总而言之，以下是我的建议，以最大限度地提高重构的好处，无论是对于您的代码还是您个人对过程的乐趣，均如此：
- 等待重构的冲动浮出水面
- 在需要改进的代码中编写简短的
FIXME注释 - 决定何时进行重构，并使该决定成为常规工作流程的一部分
- 通过推迟重构直到准备好全神贯注并投入工作，让您的大脑提出好的重构解决方案
- 使用重构作为正常发展的奖励和动力
