您有个紧急任务，您要修复程序错误,您要立刻上线产品。
但是您也要为以后着想：每个您描述的程序错误之后甚至会花更多的时间去解决，并且不应该再采用那些被废弃的APIs,过时的依赖库以及工作方式。
因此，您应该什么时候去整理代码呢？
现在？
以后？
从不？
我将在这篇文章回顾一套能够帮助您决定何时采用这三种解决方案的启发式策略。
1. 更新过时的依赖库和不再使用废弃的APIs
2. 重构去解决项目中糟糕的抽象
3. 多方面整理——从违背编程规范到别扭的编程风格
视情况而定的启发式策略
原型设计
当您满怀热情得准备着手某事时，您可能先从一个原型开始（极限编程把它称作spike）。您不会保留这些代码，只是在探索问题和解决方法，看看能从中借鉴什么。
既然您要抛弃这些代码，那么做更新、多方面整理的工作就没有了多大的意义。同样地，若您只需要理解现有的API或技术手册，您也无需做大量的重构工作。
另一方面，如果您原型设计的目标是找到正确的抽象，则需要做大量的重构工作。
1. 更新：从不
2. 重构：设计全新的API或者抽象时，现在；否则，从不
3. 多方面整理：从不
新项目
当开始一个全新的项目时，您做的决定对往后代码的可维护性有着很大的影响。这个时候，是应用最新（最可行）的依赖库、与项目有关的最佳实践方法、可维护的代码，以及能想到最好的抽象的最佳时机。您大概不会使这些都完全地贴切，但非常值得花时间一个个试过去，找到尽可能合适的方法。
1. 更新：现在
2. 重构：现在
3. 多方面整理：现在
紧急错误修正
面对用户，您需要尽快地修复错误。在这过程中，您可能会看见代码的很多不足之处，如果它们不是和当前的错误紧密相关，最好以后再去理会。
有时候这意味着二次修正：飞快的第一次和已做必要整理后的第二次。
1. 更新：以后
2. 重构：以后
3. 多方面整理：以后
新特性或非紧急的错误修正
当您有一个正在开发的项目，并且您正在做连续不断的工作，无论是特性还是错误修复，您都有一个很好的机会来逐步整理代码。
您不需要每次碰到代码时就修正所有内容。循序渐进得整理当前遇到的代码，慢慢地，您的代码库会拥有良好的可维护性。详细请见on Jefferies’excellent article。
1. 更新：对于当前遇到的代码，现在
2. 重构：对于当前遇到的代码，现在
3. 多方面整理：对于当前遇到的代码，现在
处于维护阶段的项目
最终您的项目将会完成:没有做很多新的开发工作，如果程序某部分崩溃或者有了新的需求，大多数情况下，它只需每隔几个月微调一下。
这个时候您的工作就是用最小的工作量使项目能够正常运转。重构、多方面整理工作无关紧要，但更新工作需要——依赖库可能停止运行，或需要安全更新。提前5年更新依赖库通常要比每年5次陆续地去更新依赖库难得多。
因此，无论何时您需要修复错误，您都应该更新依赖库——最好选择长期支持的版本，以减少使用中API的更新需求。
1. 更新：现在，最好是长期支持的版本
2. 重构：从不
3. 多方面整理：从不
权衡现在和未来
软件项目倾向于日积月累的过程，而不是一蹴而就。现在整理工作可能会为您节省一些时间——但是如果您现在有一个紧急任务，那最好还是推迟一下，即使以后要付出更多的工作。
因此，本文仅是一个起点:与任何启发式方法一样，也有例外，您需要根据您的实际情况和目标进行酌情分析。
