重构：你什么时候知道它的时间和时间？

Question

您何时知道是时候重构/审核一些代码？更好的是，你什么时候做的？

可能和其他人一样，我发现自己知道某些事情需要重构/审查，但截止日期和管理层都没有时间。我还想听听您如何在一般开发过程中包含代码审查。

最近我发现自己在处理新功能/代码之前就已经这样做了。例如，如果我必须在应用程序的模块X中开发新内容或更改某些内容，我会对该模块进行代码审查。我发现它也有助于我更好地理解模块，因此我可以更容易地进行更改。

所以你什么时候知道它的时间和时间呢？最重要的是，您如何将其纳入项目规划中？

Answer 1

重构不是我留出时间单独做的事情。我在开发新代码时，或者在维护旧代码时不断地这样做。按照正常的程序进行操作，并始终寻找可以在代码中改进的内容。

要回答您在自己对这个问题的回答中添加的具体案例：我认为您的情况是一个完美的例子，说明何时重构而不是完全重写是个好主意。在更改代码行之前，请确保为有问题的代码编写了一组测试用例。如果代码未通过某些测试，则会有三个目的。首先，它将为您提供专注的工作重点。其次，它会给你一个充分的理由（对你的老板）来处理代码。第三是您在重构代码时希望拥有的标准单元测试安全网。

Answer 2

标准TDD方式是Red-Green-Refactor：使测试失败，编写代码以通过测试，然后在仍然通过测试的同时重构现有代码。在测试通过后以及当您发现代码太复杂或使用错误模式时，会发生重构。重构应该是正常的日常开发过程的一部分，而不是开发周期结束时的附加组件。我认为，它更好地保持重构很小。将其作为常规活动的一部分，可以防止糟糕的代码在重构发生之前变得太大 - 至少在理想情况下是这样。

Answer 3

我倾向于看到'代码闻起来'就像我一遍又一遍地重复相同的代码，或者我看到让我思考的东西，“必须有更好的方法来做到这一点，我会去找它“。这是我编写代码的一部分，并认为拥有可能需要更长时间才能完成的优秀代码是一件好事，但是更容易扩展，可维护，或让其他人接受它而不必花费几天找出我在代码中做了什么。

如果你继承了代码，那么我倾向于认为有两种思想可以解释它：

1）保持距离。这是您进行所需更改以获取该功能而不再执行此操作的位置。如果您知道该模块将很快被替换，或者您每年仅工作一次或两次，那么我可以看到不想花费大量时间修复它的逻辑。

2）让自己沉浸其中并立即修复它。如果您所做的是相当广泛的更改，或者是您将定期使用的一段代码，那么可能会将其视为维护的一部分，以进行一些重构或文档，或者您想要描述不良代码的位置变成了不那么糟糕的代码，因为这会节省你的时间。

Answer 4

重构是我通过开发不断做的事情，而不是我计划的事情。每当代码表明它可以以某种方式更好地构造时，我会进行适当的更改。

你永远不会期望让设计完全正确。实际的细微差别在实施过程中显露出来，通过不断的重构，您总是努力达到更好的设计和分解代码。

Answer 5

我认为正确的答案是：始终！ 在处理新功能的同时，如果我看到一段我可以重构的代码，我就去做吧。 因为我使用TDD，所以我不担心旧功能会停止工作。

Answer 6

当您的代码smells

时

Answer 7

除非我知道我要复制代码，否则我通常不会这样做。因此，在编写新功能时，如果我发现自己说“嗯我在其他地方做了类似的事情......”我试着看看如何重构原文以尽可能多地重用代码。

Answer 8

我一直在重构，我试着保持快速和安全 - 代码区域的测试越好，我就能越快速，安全地做到。

此外，我标记了我认为需要进行更大规模检查的区域或架构问题，并尝试单独安排这些较大的会话 - 通常，使它们变大的原因是缺少测试，这意味着我必须花一些时间添加这些测试我需要的。

Answer 9

要解决一个特定的问题：有一个项目会在几个月内编写一些不良代码（即使是不再在公司的人）。完全重写是不可行的，我无法向客户或管理层解释。

所以我想知道在对该模块进行更改之前重构某个模块是否可以接受。

我知道这不是最好的情况，但上下文是一个特殊情况（代码已经破坏，无法重写所有内容）。

Answer 10

我会说我也在寻找代码味道，但我想更具体一点。我正在使用我的设计框架，该框架随着每个项目的发展而不断发展。在项目的早期，我将倾向于重构和重新设计（训练自己保持这些是我正在做的事情）并且当我接近截止日期并且更接近解决任何问题或代码气味时我会放松和专注于我的具体实施。当我这样做时，我会经常发现（或创造）更多的东西，虽然功能齐全，但我并不完全满意。我将记录这些并在下一次迭代通过项目我将解决这些问题。

当我回到代码时，我有时会发现有一种更优雅的方式来处理这种情况，并且因为没有尽快看到它而踢我自己。有时，我会发现有更好的方法，但这不是我原先设想的方式。有时我发现它的方式很好，改变它会过度设计。其他时候我发现在修复别的东西时，我原来的问题已经消失了。

Answer 11

1. 当我准备对代码进行功能更改（功能，错误修复，性能等等）时，我首先会问自己，如果代码的理想结构能够做出改变，那会是什么样子。

2. 然后我在那个方向重构

3. 我现在进行功能改变。

4. 最后，我再次重构以清理我的改变带来的丑陋。

我总是希望平衡我的重构工作与其他因素（截止日期，此代码的重要性，测试覆盖质量等）。

Answer 12

如果您不需要更改该代码（它可以工作，不需要扩展它），请不要这样做。随它去。换句话说，如果它需要更改它，请编写一些测试重构它并包含您的更改。

Answer 13

我认为自己是一名新手程序员（我此刻一直只是为了维持生活而编程6个月）而且我注意到只要查看代码，你就应该感觉它是否需要重构

据我所知，有些人将此称为“代码味道”，但我会说这是一种不公正的感觉，即你没有尽力使用你正在关注的代码。您可能不确定该怎么做或如何改进代码，但如果您对代码不完美有任何疑问，那么很可能不是。

Answer 14

您通常可以使示波器比模块更小。有时，单个函数将成为孤立重构的明显候选者，即使它只是重命名局部变量，通过使代码自行解释来消除对注释的需求，就像这样。

如果您可以识别需要更改的区域，请在更改之前和期间清理该区域。通常我发现我需要执行一些重构才能充分理解代码以进行更改。

我会把自己的声音添加到其他人那些说要围绕代码进行某种测试的人身上。尝试至少覆盖一组合理的“正常”案例并实现一些自动化（几乎所有语言都有框架），以便在每次小的更改后都可以轻松快速地运行测试。我希望在我第一次开始代码清理活动时，我想到/了解测试框架......

Answer 15

如果我在修复错误时一遍又一遍地访问相同的代码，我认为是时候重构它了。如果我加入了一个新项目或负责新代码，我也会坐下来开始重构。如果我正在扩展某些内容，那么在进行任何重大更改之前，我首先会重构所有旧问题（在它们变得过于根深蒂固之前）。

当您达到某个目标级别normalization时，您已完成重构。如果它只是一般的清理：1,2或3就足够了。如果您要扩展代码，则4或5更好。如果你真的想在很长一段时间内利用现有的工作，那么6就是你要走的路。

保罗。

Answer 16

回答你问题的一部分：我已经重申了其他一些人已经提出的观点了 - 一般来说，如果你没有一套可重复的测试，你可以运行以确保你的改变没有破坏代码 - 那么你可能根本不应该重构。

你说代码已经坏了。您最初可能会尽可能少地进行小的更改，以使其“正常工作”。麻烦的是，如果没有测试，你怎么能说它真的“有效”？

祝你好运！