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

Question

我有一个刚刚发货的应用程序。自从我写这篇文章以来，我已经了解了amfphp和propel。在应用程序中使用这两种方法都是很好的，但我不能说在这一点上它是必需的。

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

Answer 1

我应该吗？

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

现在，如果我们正在讨论重构代码，因为我已经在特定的代码块中，并将其作为缺陷解析或代码维护的一部分工作，这完全是另一回事。但重构只是为了重构？这听起来像繁忙的无聊工作。当然，你没有一个空白的缺陷列表。

Answer 2

有重构后检查代码的单元测试。

Answer 3

需要付出的努力与收到的利益以及与其他工作优先适合的地方。

Answer 4

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

Answer 5

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

Answer 6

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

在privious项目中，我们其实记录的所有进入的数据14天，在这14天的开始和结束保存督促数据库的快照，我们就能够比较使用旧代码数据库的状态和新的代码。但单元测试肯定会消除一些恐惧:-)

Answer 7

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

由于软件技术需要很酷的名称，如敏捷或设计模式，我称之为犬重构。

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

Answer 8

我有多大可能打破现有功能？单元测试在这里是一个很好的安全网，自动重构工具也是如此。

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

Answer 9

我必须给Drejc +1。如果你没有单元测试，那么为什么不重构的唯一最重要的原因就是它。但即使这并不意味着你不应该重构。我应该说我的工作方式是代码功能，然后总是重构来处理设计债务。重复恶心。

“足够好”的模式可能是地球上最常用的编程方法，这就是为什么我们的软件是越野车和杂乱的原因之一。我们不是选择最少的能量“路径”，而是选择最少的能量“步骤”。

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