在大多数发布日期由业务需求决定的世界中，程序员通常会发布有效的代码。通常，当您知道代码有效时，所交付代码的结构和效率就变得没有意义了。除非指定了生产质量（例如算法的 API），否则对于运行到几百行的代码，可交付代码等于有效的代码。
我的问题是：给一个特性一个 ETA，你会在特性工作并完成之前编写代码吗？或者你会让它尽快工作并重构发布质量吗？
我倾向于后者，尽管这听起来像是更多的工作。当为了算法效率和模式而将有效的代码分开时，将它们放在一起是一种快乐的体验。此外，它得到了所有非功能性的喜爱——更少的错误、高性能、可扩展、安全。我认为我不擅长第一次编写最好的代码。所以这种方法对我很有效。
我想知道哪个是首选，为什么？我不是在寻找全行业的方法，只是在寻找个人倾向，这样我就可以衡量思想的相似性。
我更喜欢在发货前后进行重构。
将任何重构推迟到发布之后，这听起来非常像您可能永远不会真正去做（通常情况下，会出现对业务更关键的事情）。但即使你在发货前完成了，你的代码也不是完美的，你也没有什么可以改进的了。之后也是如此（只要代码保持到任何程度）。
对我来说，将代码重构为更简单、更干净的东西是任何软件开发工作持续且自然的一部分。
编辑：显然，在决定在给定时刻重构多少和多长时间时，您需要考虑业务限制。
编辑2：至于“如何说服我的经理重构”这个问题（见评论），这里有一些资源可能会有所帮助：
问题是，如果你倾向于只在发货后重构，你永远不会这样做；）
我倾向于看到“完成”，包括精心设计的代码。
如果存在涉及大量工作的非常大规模的重构，则此规则有例外。为了满足最后期限，您可以推动下一次开发迭代。
如果您正在进行测试驱动开发。通常，您首先编写最简单的东西，然后在添加其他功能时进行重构（AKA Red、Green、Refactor）。
不过，这个问题显然有一个很大的灰色区域。如果你正在交付一个无法维护的混乱，那么也许你应该首先回顾一下你是如何编写代码的。应该出于某种目的进行重构——例如使代码更灵活以允许新类型的产品。不要仅仅因为你觉得你应该重构。
在我们的团队中，我们认为未重构的代码没有“完成”。换句话说，“代码已经重构”是我们定义 Done的一部分，它是我们可交付代码的标准之一。
我宁愿在发货前重构。你是对的，我的第一个代码通常不是最好的设计。但是，如果您对代码进行了通过测试，那么之后直接重构的风险应该很小。
稍后再做的问题只是“如果在发布之前，则在发布之后”。根据我的经验，没有理由希望在发布后有时间进行清理。
对我来说，重构应该在交付后完成，确保所有功能都正常工作，并将其留给代码构建的下一次迭代。如果您在发货前开始操作代码，您最终可能会做很少的优化，最后留下无效代码。
我最初尝试编写最好的代码，但始终发现一旦进入生产环境，重构是不可避免的。由于用户反馈，通常在代码发布后进行重构已成为常态。