还有其他人有重构问题吗？[关闭]

看起来，在我编写了大量代码之后，我感到焦虑不安，好像我没有以最好的方式来完成它，而我最终却不断地在项目上重构和花费太多时间，或者从未得到过有时候做。这会发生在其他任何人身上吗？您如何处理呢？

这些时刻发生在我身上，我很享受。

原因是：如果我不回头看我的工作，并且认为我可以做得比不做开发者会做得更好。因此，当这些启蒙时刻发生时，请拥抱它们并记下您学到的知识。考虑当前项目的时间表，如果可能，请重构代码；如果不可能，请上课，并在将来的项目实现中使用它。

无论哪种方式，从自己的错误中学习都是一件好事！

以下是一些规则，可以限制此活动并提高其生产力：

• 设置时间，例如将计时器设置为25分钟
• 仅当您具有不错的测试范围时才这样做。
• 尝试使重构对接下来的几个功能的开发有用

看来您总是可以重构的，不是吗？我尝试仅在尝试解决其他问题时限制重构。例如，在遇到性能问题时进行重构，并在帮助您解决问题的情况下进行重构-在需要添加新功能时进行重构，而重构将帮助您解决问题

老实说，如果您正在编写大量的代码并且认为它是完美的并且不需要任何重构，我会更加担心。

当我年轻，缺乏经验时，我对自己的编程能力非常自大，并且总是倾向于想象设计和计划非常好是可能的，而且一旦进入实施阶段，我就将其付诸实践，并且都是完美的。

现实几乎相反。甚至有人说，一旦开始编码，就应该进入维护模式。这里的想法是，SDLC的“实现”阶段实际上并不存在，因为您不应将错误修复或重构放在一边，并假装所生成的代码是“新鲜的”且完美的。

说了这么多，我想这IS可能太过分了重构。我只是还没看呢。而且我拥有的经验越多，如果更多的软件团队专利地拒绝按时完成工作并承担技术债务，我认为这将是一件好事。毕竟，这是重构在现实世界中被抛弃的最常见原因。

我建议不要完全依赖感觉或代码气味。

清楚地列举代码有什么问题以及解决方案是什么。认真地写下来，因为您将要回顾重构对这一点的有效性。

确定将重构分解为可实现的块并确定其优先级的方法。让纪律只关注每个块的范围，避免切线会破坏您的任务。

另外，在继续之前，请确定可以针对现有代码编写的单元测试。如果已经有广泛的测试，那就太好了。缺少单元测试代表了进行测试的绝好机会。

毫无疑问，我陷入了这个陷阱，但是对于将来的支持/调试而言，一些重构很重要。

在编写主要代码段时，很容易将代码行保持在当前正在编写的方法中。当我完成了大部分代码后，我要放置一个待办事项：代码审查注释。然后几天后，我将进行代码审查并进行相应的重构。如果几天后无法阅读，那么几个月甚至几年后会发生什么。

我第一次学习语言或技术时会陷入这个陷阱。例如，当您第一次学习Java时，想象一下您使用servlet编写了一个Web应用程序，并认为这是正确的方法。然后您意识到存在jsp，并且您认为哦，这是更新的，可能是正确的。然后，一旦完成一半，您就会发现Struts以及一些EJB东西，之后找到spring（基于xml），之后又找到了很酷的@MVC批注，之后发现它们太冗长了，并且被宠坏了在groovy / grails和scala / lift之间选择！这对于个人项目来说是完全可以的，因为重点通常是学习而不一定要赶上最后期限。

我也曾经在工作中成为超级重构者。但是，随着我积累了更多的经验，我对重构的内容也变得更加挑剔。事实证明，当您离开公司时，您不会随身携带代码，通常其他工程师破坏代码的速度几乎比修复它快。

拇指我后续的规则是这样的：我重构，直到它优化的，因为它可以在那个时候，然后我不要再重构，除非情况变化，或更很少，如果我有一些新的和更好的方式来启发做事情（例如使用新的语言功能）。

例如，我曾经不得不为现有应用程序编写一个新的代码模块。我以某种方式写了它，第二天我再想一想，并认为我可以对其进行重构，使其更加抽象，因为我们可以肯定地需要将其扩展以用于其他用途。因此，我将代码重构了。然后，我认为它有点太通用了，我使用Generics（C＃）合并了一些基本上在做相同事情的类和接口，以获取相同的功能。在这一点上我可能可以进一步重构以使其更好，但它“足够好”-代码编写正确，遵循正确的设计模式和工程概念，并且可扩展。如果要求迫使我重新评估代码，或者存在某种语言功能可以使代码更清晰和/或更易读，那么我只会再次重构它。