几个月前我开始了一个相当大的2D游戏引擎项目，我开始注意到：
前一个或两个月的代码与最近的代码完全不同：
有些部分几乎可以立刻找到一种更好的方法来实现它
代码似乎质量明显较低
但是，在我写这篇文章的时候，我正在注意尽可能地像现在这样做。
现在，我的问题：
这是一种常见情况，即使在大型商业项目中也是如此？
我是否应该考虑投入（大量）时间进行重构，甚至可能重写受影响的代码？
随着项目的发展和变化，大部分代码必须从头开始重构或重写，这是正常的吗？这不好吗？
答案 0 :(得分：9)
这是一种常见的情况，即使在大型商业风格的项目中也是如此？
是
我是否应该考虑投入（大量）时间进行重构，甚至可能重写受影响的代码？
你明天也会这样做吗？
没有。除非您实际处理要重构的代码，否则不会。
随着项目的发展和变化，大部分代码必须从头开始重构或重写，这是正常的吗？
是
这不好吗？
如果我们完美无缺，那肯定会容易得多，是的。
答案 1 :(得分：4)
是的，这也是我项目的常见模式。 ABR：永远在重构。当我觉得出现了新的模式时，我会尝试更新旧代码以匹配它。随着项目的发展，您在问题领域工作的经验会影响您的风格，并且更新旧代码以匹配它也是个好主意。
作为必然结果，如果您的第一个项目提交在几个月之后仍然在您的项目中保持不变，那么就会出现问题。我将开发视为一种探索性实践，其中很大一部分是更新旧代码并改变您的风格。在开始编码之前，没有人知道他们的最终设计/ API。找到任何大型开源项目并查看其提交历史记录;它无处不在。
如果你曾经在绘画或绘画上工作一段时间，那么你的风格会越长越精致。此外，您的第一层或前几张草图很少是最终结果中出现的墨水线。
答案 2 :(得分：3)
从这次经历中得到的一个重要教训：你会变得更好。或者，至少，你正在改变。当然，从今天的角度来看，你今天写的代码看起来更好。如果您回写的代码今天看起来很糟糕 - 让它看起来更好。你今天的责任不仅仅是你今天写的代码;它是整个代码库。所以说得对 - 很高兴你变得更好。
答案 3 :(得分：3)
是的，这种情况发生了。我甚至会说，当您深入研究解决方案时，这是预期和典型的。
只有在您返回并触摸它时才更新您的代码。在调整之前不要忘记编写单元测试。
无缘无故地重写坏代码非常诱人，特别是当你没有截止日期临近时。你很容易陷入这种循环中。
请记住，送货是一项功能。
答案 4 :(得分：2)
这是一种常见情况，即使在大型商业项目中也是如此？
我必须在此承认，我的信念是，如果您先设计并稍后编码，您可以避免许多问题。所以我想在这里说它取决于。如果一个好的设计开始有一些公司标准，以确保基于设计的代码遵循相同的重要规则，无论谁写它，那么至少你有机会避免这种情况。但是我不确定是否总是如此： - ）。
我是否应考虑投入（大量）时间进行重新分解，甚至可能重写受影响的代码？
让事情变得更好永远不会受到伤害： - ）。
随着项目的发展和变化，大部分代码必须从头开始重新计算或重写，这是正常的吗？这不好吗？
我会说是的，当结果代码优于旧代码时，通常认为重新分解是一件好事。世界永远不会保持不变，即使某些时候某些东西是合适的，也可能是因为它无法满足当今的需求。所以我会说，如果你工作的公司会对你说：“你不能重新考虑这些代码。这是神圣的”。变化（如果变得更好）总是好的。
答案 5 :(得分：1)