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