在重构代码之前你会考虑什么？

Question

我有一个刚刚发货的应用程序。自从我写这篇文章以来，我已经了解了amfphp并推动了它。两者在应用程序中使用都很“不错”，但我不能说此时需要它。

在重构代码之前，您会考虑哪些类型的事情？

Answer 1

进行单元测试以在重构后检查代码。

Answer 2

需要付出的努力与收到的福利以及与其他工作优先相符的地方。

Answer 3

我应该吗？

只是因为我可以重构代码并不意味着我应该重构代码。在许多情况下，还有许多重要的事情需要做。像修复缺陷一样。

现在，如果我们正在讨论重构代码，因为我已经在那个特定的代码块中，并将其作为缺陷解决或代码维护的一部分进行处理，这完全是另一回事。但重构仅仅是为了重构？这听起来像是因无聊而出生的繁忙工作。当然，你没有空缺陷清单。

Answer 4

重构代码的可维护性如何。后见之明是20/20，但随着产品的发布，优雅而神秘的设计可能是一个难以维持的噩梦。此外，重构设计的灵活性允许功能增强非常重要。

Answer 5

我有多大可能破坏现有功能？与自动重构工具一样，单元测试是一个很好的安全网。

之后代码是否真的更容易理解和维护？这可能是一个难以回答的问题，需要经验才能更好地回答它。

Answer 6

为源代码管理中的当前生产代码库创建一个fork，并在源代码管理的实验分支中执行所有重构。

Answer 7

单元测试非常好，但是如果单元测试没有涵盖代码，你应该有其他方法来确保不破坏代码。如果你能够掌握生产数据库的副本，甚至可能是一些现场生产数据，你应该有一个公平的机会。

在一个私密的项目中，我们实际记录了所有进入的数据14天，并在这14天的开始和结束时保存了prod db的快照，然后我们能够使用旧代码和旧代码比较db的状态。新代码。但单位测试肯定会消除一些恐惧： - ）

Answer 8

我嗅探代码。如果我不喜欢这种气味（换句话说，它没有像我一样的气味），那么我会把它全部撒尿，直到我喜欢它。

由于软件技术需要像Agile或Design Patterns这样很酷的名字，我称之为Canine Refactoring。

重写代码后，我自己使用它一段时间，吃我自己的Dogfood。

Answer 9

我必须给Drejc +1。没有重构的最主要原因是你没有进行单元测试。但即使这并不意味着你不应该重构。我应该说我的运作方式首先是代码功能，然后总是重构来处理设计债务。重复ad-nauseaum。

“足够好”的模式可能是地球上最常用的编程方法，这也是我们的软件出错和混乱的原因之一。我们总是选择能耗最小的“步骤”，而不是选择能量最少的“路径”。

但是，要小心！没有适当的工具进行重构（这将取决于语言和IDE）就像锤击螺丝：你可以到达那里，但它不会有效（并且你可能遇到麻烦）。