你的项目截止时间就要到了，你有一个紧急的 bug 需要修复，你的项目需要快速迭代输出产品。
虽然你很忙，但是你也必须考虑你的未来：你现在引入的每一个 bug ， 都会给以后修复带来巨大的时间成本。 因此我们不应该使用过时的API， 过时的版本以来，和一些老旧的做事方法。
所以，我们什么时候来清理我们的代码呢？
现在就做？
以后需求少了在做？
还是永远不做？
在本篇文章中，我将告诉你该在什么时间去用以下三种方法来清理你的代码：
- 更新项目依赖和废弃的API
- 重构不合适的抽象设计
- 编码规范和日常编程习惯等杂项清理
解决方法
原型设计
在工程构建之前，你会做一些技术调研，做一些原型设计（或者极限编程中的Spike解决方案），但你不会长期保留使用这些代码，你仅仅是使用这些代码来验证是否能解决问题。考虑到你有可能会废弃掉这些代码，更新和规范没有什么需要值得特别注意的事项。如果你也想尝试理解学习那些已经存在的API, 你也不需要对代码进行重构。
但是，如果你是想通过原型设计找到更好的抽象方式，你就必须进行大量的重构了。
最佳实践:
- 更新： 不需要处理
- 重构： 如果你需要找到更好的架构方式，你就需要重构，反之，你就不用在意重构的问题。
- 杂项清理：不需要处理
新项目
如果你正在着手搭建一个全新的项目，你的任何一个决定都会对以后带来很大的维护成本。
当然，这也是一个机会，让你可以使用最新的框架，最佳的解决方案，最好的编程规范和最好的架构。虽然你不一定能做到完美，但是你可以使它尽可能的接近完美。
最佳实践：
- 更新: 从现在开始
- 重构：从现在开始
- 杂项清理: 从现在开始
紧急的bug修复
在这个时候，你需要快速为用户修改 bug ，如果你看到了问题需要解决，但是这个问题和当前需要修复的bug无关，我建议你暂时不要动它，等 bug 修复结束了在来处理它。
有些时候，bugfix 有两层含义: 一次是快速解决问题，另一次是你需要让代码更整洁。
最佳实践:
- 更新：稍后
- 重构： 稍后
- 杂项清理: 稍后
新功能开发中或者不紧急的bug修复
当你有一个正常迭代开发的一个项目，不管你是在做新功能开发，还是bug修复，这个时间是你做代码清理的最佳时机。
在这个时候，你并不需要修复所有你接触到的代码，你需要做的是整理你处理中的代码，并且使你的代码库更加的整洁。详情参考<Refactoring – Not on the backlog!>
最佳实践：
- 更新：立即更新你用到的代码
- 重构：立即重构你用到的代码
- 杂项清理： 在你用到的代码中，立即使用新的代码规范等
项目维护阶段
当你的项目已经开发完成：没有什么新的开发任务的时候，经常几个月才有一些给菜单多加一个选项等这种小的需求修改。
现阶段，你的目标是做少量的修改，让项目稳定运行。重构和杂项清理在现阶段是不必要的，但是你项目需要你及时更新一些框架库的依赖 —— 某些框架库不在提供服务，或者有安全更新。经常更新依赖显然要比5年才更新一次容易得多。
所以不管你是不是因为有bug要修复，你都应该及时的去更新你的依赖项 —— 理想情况下，长期发布更新，以减少对API使用的更新需求。
最佳实践：
- 更新：现在更新，并且长期发布版本支持
- 重构：不需要
- 杂项清理： 不需要
现在与未来的平衡
软件开发是一个持续的过程，不是做完就没事了。现在着手去清理代码，将会为你以后节省时间，尽管你现在赶项目的截止时间，现在着手去做也比放在以后多花几周时间去做要好。
本文只是做一个开篇，与任何其它方法一样，也都有不适用的时候，所以，你需要根据你项目中的实际情况和目标来做一些调整。
传送门
欢迎关注我的公众号，一起交流技术事。