重构并不是我单独花时间做的事情。我会在开发新代码或维护旧代码时不断进行重构。将其纳入日常工作计划，并一直寻找可以改进代码的地方。
针对您在回答这个问题时添加的具体案例：我认为您的情况是重构而不是彻底重写的好例子。确保在更改任何代码之前，为相关代码编写一组良好的测试用例。如果代码未通过某些测试，则可以达到三个目的。首先，它将使您专注于特定区域。其次，它将为您（向老板）提供充分的理由来修改代码。第三是标准的单元测试安全网，您希望在重构代码时始终使用该安全网。
重构是我在开发过程中持续进行的操作，而不是计划做的事情。每当代码表明可以以某种方式更好地组织时，我都会进行适当的更改。
你永远无法期望设计完全正确。实际的细微差别会在实现过程中显现出来，通过不断地重构，你始终努力达到更好的设计和分解代码的目标。
我在编写代码的同时进行重构，并尽力保证快速和安全 - 代码区域经过更好的测试，我就能更快、更安全地进行操作。
此外，我会标记那些需要进行大规模改进的区域或架构问题，并尝试将这些较大的工作单独安排 - 通常，导致它们变得更大的原因是缺乏测试，这意味着我必须花费一段时间来添加所需的测试。
针对一个具体的问题：有一个项目，其中一些糟糕的代码（甚至是已经离开公司的人写的）在几个月内被编写出来。完全重写是不可行的，我无法向客户或管理层解释。
因此，我想知道在这种情况下，在对该模块进行更改之前重构某个模块是否可行。
我知道这不是最好的情况，但上下文是一个特殊情况（代码已经损坏，无法全部重写）。
我会说我也会寻找代码异味，但我想更具体一些。我正在使用一个由我设计的框架，随着每个项目的发展而不断壮大和演变。在项目早期，我通常会进行大量的重构和重新设计（让自己保持分离是我仍在努力的事情），并且随着接近截止日期和解决任何问题或代码异味的时间越来越近，我会放松并专注于我的特定实现。在这样做的过程中，我通常会发现（或创建）一些功能上可行但我并不完全满意的东西。我会记录这些问题，并在下一次迭代项目时解决这些问题。
当我回到代码时，有时我会发现有一种更优雅的处理方式，然后为自己没有早点看到它而感到遗憾。有时候，我会发现有一种更好的方法，但它不是我最初设想的方式。有时候我发现它的现状很好，改变它会过度设计。其他时候，我发现在修复其他问题时，我的原始问题已经消失了。
