我发现自己重新审视了我的项目领域并再次对其进行改进。这通常发生在我从头开始做某事时，当我更好地理解它时，我的代码和技术会变得更好，因此我会回顾我所做的事情并让它变得更强大。这是正常的还是我只是缺乏经验？你多久重新访问一次你的代码？好的程序员写一次就不需要改变吗？
【问题讨论】：
我同意其他答案，但这也取决于您编写代码的原因。如果它是截止日期的特定项目，您可能没有太多机会。如果它可能被其他人重用，请确保重构不会破坏他们正在使用的任何东西。如果这是一个长期项目，尤其是一个公共项目，那么几乎可以肯定它需要大量重构。
我已经编写了一个公共图书馆大约 13 年，并且经历了 5 个半的修订（我正在经历的那个）。在许多情况下，这是因为技术已经改进，而我为自己做的事情现在可以用标准库来做。多年来，我学到了许多更好的策略。
一般来说，好的重构通常意味着丢弃旧代码。
更新 现代工具使自动执行许多操作变得容易（例如更改名称、包）。专家建议方法很短，所以当你发现你的方法延伸到两页时，将它重构为更短的方法。但有时这些工具无济于事，您必须创建暂时损坏的代码。在这种情况下，请确保您 (a) 在工作版本上运行单元测试 (b) 提交它。很容易进入一个复杂的重构操作，并意识到你已经把它破坏得非常糟糕，以至于你需要回溯。 如果您的用户依赖您的代码，请确保您继续提供他们知道的 API。例如，假设您有一个名为
的例程Date date = getLastUpdate();
然后你决定（正如我和其他许多人所做的那样）java.util.Date 已经彻底崩溃了。您决定将其更改为 Joda DateTime，但在此过程中会很艰难。您可能需要留出时间一次性完成它。不要将 API 更改为
DateTime date = getLastUpdate();
新建一个界面如
DateTime date = getLastDateTimeUpdate();
然后将原来的标记为@Deprecated
在决定发布新版本之前，您不应删除早期版本（动态更改 API 会失去朋友）
【讨论】：
我想说你没有什么可担心的，复习你的代码是正常的，有助于提高你的理解。您唯一需要担心的是，您是否正在检查相同的代码并一次又一次地更改实现。
即使您没有动手实践经验，编写和测试代码也会变得更好。
【讨论】：
检查代码很好...只要确保在更改代码时对其进行测试（设置自动回归测试是个好主意）。
此外，如果您在许多地方使用相同的代码，请将其放入类库中，这样您就只能在一个地方使用它，（因此任何改进只需要进行一次）。
这正常吗？ - 可以（只要不占用其他项目太多时间）
您多久重新访问一次代码？ - 每当我再次使用该代码并有时间查看它时
优秀的程序员写一次就不需要改变吗？ - 给猫剥皮的方法不止一种，所以这是主观的。
【讨论】：
我会说这是健康的，并且会认为这是一种很好的做法。只要您的测试良好，重构对于良好的代码库至关重要。
在 TDD 中，循环是：
【讨论】：