如何重构？

Question

我想知道其他开发人员是如何开始重构的。你的第一步是什么？如果你重构不属于你的代码，这个过程(重构)会有什么不同？你会在重构的同时编写测试吗？

Answer 1

你的第一步是什么？

第一步是运行单元测试以确保它们都通过。实际上，如果在修改代码之前就已经破坏了测试，那么您可能会浪费大量的时间来寻找哪些更改破坏了测试。

如果你重构了不属于你的代码，这个过程会有什么不同？

当重构不是我写的代码(或者我很久以前写的代码)时，我当然是在做较小的步骤。我还可以在继续之前验证测试覆盖率，以避免依赖于总是通过的单元测试……但这并不能测试我正在研究的领域。

你在重构的同时写测试吗？

我通常不会，但我可能会在以下情况下添加新的测试(列表不是详尽的)：

新测试的想法在我的脑海中闪闪发光(“如果……会发生什么?”- write a test to know)

• 发现测试覆盖范围中的漏洞

它还取决于正在执行的重构。当提取一个函数时，如果可以像以前一样以不同的方式调用它，我可能会创建一个新的测试。

以下是一些一般性的建议：

第一件事是维护在处理代码时注意到的code smells的列表。这可以让人从记住代码中看到的东西的负担中解脱出来。另外，

当单元测试没有完全通过时，金科玉律永远不会重构。

在代码稳定的时候重构，在添加一些你知道会受到未来重构影响的东西之前，在集成之前，最重要的是在说你的已经完成之前。

在没有单元测试的情况下，您必须对您想要重构的代码部分进行测试。如果单元测试很难改进，就像通常的情况一样，那么您可以按照每个Michael Feathers in 的建议创建characterization tests。简而言之，它们是端到端的测试，允许您确定代码的当前行为(并不是一直都能完美地工作)。

不要害怕一小步一步来。不要同时做两件事。如果你评论了一些需要重构的东西，把它记下来，不要马上修复它，即使它看起来很容易。

当测试通过时，经常检查。这样你就可以恢复一个糟糕的重构，而不会丢失之前做过的事情。

请记住，重构不会为您的客户增加价值(这一点可以讨论)，但客户不会付钱让您重构。一条经验法则是在对代码进行更改或添加新功能之前进行重构。

Answer 2

我接受垃圾，让它不那么垃圾。:-)

我是认真的。我不会重构来创建新的功能。重构发生在新事物之前。如果没有测试，我会编写测试以确保重构不会破坏任何东西。如果有测试，我会使用那些测试。如果测试不充分，我可能会编写更多的测试，但我会考虑将其与重构分开，并首先进行。

对我来说，第一步是注意到我可以抽象一些东西，使它更通用(在其他现在需要功能的地方也很有用)，或者我注意到一些东西是不好的，可以更好(主观)。我不会无缘无故地重构为泛型。YAGNI principle适用。

我们有共享所有权的概念，所以代码始终是我的--我可能没有写过它，但在重构时我不会考虑这一点。如果目的不明确，在决定需要重构之前，我可能会尝试理解一些东西--尽管这几乎总是重构本身的理由。

Answer 3

阅读Martin Fowler的书"Refactoring“

顺便说一句，这是Martin Fowler自己的Amazon exec链接，如果你想知道:)