你什么时候重构代码？

Question

当你在代码中做其他事情时，你会这样做吗？

当你的经理批准时？ （似乎这种情况从未发生过）

我猜其中一些取决于变化的影响。如果我改变了代码并且它对课程之外的任何事情都没有影响，对我来说影响很小。

它改变了什么？什么时候影响X对象或X项目？

我只是好奇其他人如何解决这个问题......

Answer 1

• 作为原始开发的一部分（红色/绿色/重构）
• 代码审核人员建议时
• 当我们注意到设计痛点时
• 进行其他更改时，如果重构影响很小，即通常不会影响任何其他文件。

如果它影响公共API，我通常喜欢使重构成为单个源代码提交，它不会改变行为（然后将新行为构建到另一个提交中）。如果它也影响其他项目，则需要就此达成共识，并且我希望获得更改其代码的权限以进行相同的重构提交。

Answer 2

当你已经在代码中时进行重构有时是最简单的，特别是如果你的经理不支持这个计划，但如果你只改变一小部分它会破坏与周围部分的一致性。在这些情况下，最好是有选择性，并且如你所说，做一些影响很小的事情。将long select / switch语句重构为函数并延迟重构内部代码可能会有所帮助。

在以前的工作中，我是经理，所以无论什么时候我都会重构。在我目前的工作中，我是一名分析师，所以大部分代码都不是我的责任。当我编写代码时，我会避免影响我不写的任何内容。我有一个完全由我自己控制的项目，每当我学会更好的做事方法时我都会重构。

Answer 3

我发现在重新编写代码（可能是为了添加/扩展功能）后3个多月我重构了。

如果我花了超过2分钟的时间来辨别出一大块代码在做什么，我会将它分开以使其更容易理解（或者只是添加更多注释。）

Answer 4

一旦所有测试都运行。

Answer 5

我在一个大型系统工作，所以我只改变我必须做的事情。变化很容易产生不良副作用。

我将重构那些性能不佳，工作不正常或需要新功能的代码段。

我从不决定解决问题，我永远不会做。如果它有效，没有人要求改变或抱怨问题，继续前进。生命太短暂无法解决所有问题。

Answer 6

我经常在用户需求更改或错误修复时重构我的代码。然后，人们就有机会审查您的更改。

否则，即使它闻起来，我通常也不会触摸可行的代码。

Answer 7

我们发现在我们处理一些代码时最好进行小的重构 - 做必要的事情，最好配对。

对于更大的事情，我们在墙上有一个技术债务部分 - 如果你发现某些东西并且没有时间来解决它，或者它需要一些讨论才能解决，你可以将它添加到墙和他们将安排在未来的迭代（或空闲时间出现）。

Answer 8

我们尽可能经常重构。进行单元测试以确保在重构​​之前和之后一切正常有效。

Answer 9

代码审核流程通常对此有所帮助。如果我触摸一些代码，它会得到审查，审稿人会问，“你为什么这样做？”，我说，“我不得不因为（在这里插入丑陋）”。这表明代码应在审核完成后立即重构。

Answer 10

看看我们公司，我们已经决定我们即将推出的应用程序版本主要用于性能优化而不是新功能。这是我们认为需要的东西，也是一些客户要求的。 因此，我们花了很多时间来识别应用程序中的性能瓶颈，并查看代码并重构代码以使运行更快。

因此，在我们的案例中，我们之所以这样做，是因为管理层批准我们为此新版本执行此操作，因为我们向他们展示了可以获得多少性能提升。

Answer 11

需要时重构：

• 当您需要更好地理解您正在处理的代码时（配对通常有帮助），例如：重命名，方法提取等。
• 当前设计不允许“干净”更改时：此时您实际上可以与您的经理争论价值（例如，这个新功能对项目有什么价值）

Answer 12

我总是在我的代码中进行小型重构。我知道，只要我进行了单元测试，以确认事后一切都能正常运行，我认为这样做不会有任何伤害。这样，每次使用它时都不会产生那种模糊的“需要重构”的感觉。

现在，如果它需要大量重构，最好为此做好计划并留出一些时间。

Answer 13

似乎大多数其他海报都对refacotring mercilessly有抵抗力。当然，如果您正在使用的系统不通过大量的单元测试来支持这一点，那么这是不可能的。但总的来说，如果我能够看到一个机会，在不花费超过几分钟或几小时的情况下使代码变得更紧，我就会去做。如果我不确定我应该做什么，我会寻找重构的东西。

Answer 14

我在修复错误或添加功能时重构，重构过程使代码更易于阅读和维护。

Answer 15

强烈遵循DRY原则通常会成为我重构的触发器。

Answer 16

经常不足，从而增加技术债务。

很伤心，但也是如此。

按照我的说法，不要像我工作的团队一样。