出厂前重构还是出厂后重构？

Question

在大多数发布日期由业务需求决定的世界中，程序员通常发布工作正常的代码。通常，当你知道代码的工作原理时，代码的结构和效率就会变得毫无意义。除非指定了产品质量(例如，对算法的api)，否则对于运行数百行的代码，可发货代码等于可以工作的代码。

我的问题是:给出一个特性的ETA，你会在特性工作和完成之前编码吗？或者你会让它尽可能快地工作，并重构发布质量吗？

我倾向于后者，尽管这听起来像是更多的工作。当为了算法效率和模式而拆分可以工作的代码时，将它们放在一起是一种愉快的体验。此外，它得到了所有非功能性的错误，性能，可扩展性，安全性..我不认为我第一次就能写出最好的代码。所以这种方法对我来说很有效。

我想知道哪一个是首选的，为什么？我不是在寻找全行业的方法，只是个人倾向，这样我就可以衡量思想的相似性。

Answer 1

我更喜欢在之前重构，在发布之后使用。

将任何重构推迟到发布之后听起来就像你可能永远不会真正去做一样(通常情况下，会出现一些更关键的业务)。但是，即使你在发布之前做了这件事，你的代码也不是完美的，你已经没有东西可以改进了。之后也是如此(只要代码在一定程度上得到维护)。

对我来说，将代码重构成更简单、更干净的东西是任何软件开发工作中持续和自然的一部分。

编辑:显然，在特定时刻决定how much and for how long you refactor时，您需要考虑业务约束。

编辑2:关于“如何说服我的经理进行重构”这个问题(请参阅评论)，这里有一些可能会有帮助的资源：

• Explaining Refactoring to Management at InfoQ
• Martin Fowler的开创性著作“重构”( Refactoring，似乎是available online in its entirety)中有一节的标题是"What do I tell my manager?“。实际上，无论如何我都推荐阅读本书的前几章，因为它们比我见过的任何其他内容都更清楚地解释了重构的基本概念。

Answer 2

在我们的团队中，我们认为未重构的代码不是“完成”的。换句话说，“代码已被重构”是我们对Done的定义的一部分，它是我们对可发货代码的标准之一。

Answer 3

问题是，如果你倾向于在发布后只重构，你永远不会这样做;)

我倾向于看到“完成”，包括良好分解的代码。

这条规则也有例外，如果有一个非常大规模的重构，需要付出很大的努力。为了在最后期限前完成，你可以推到下一次开发迭代。