重构/重写代码还是继续？

Question

我刚刚完成了一段复杂的代码。它适用于规范，它符合性能要求等，但我对此感到有点担心，并正在考虑重写和/或重构它。我应该这样做（花费时间可以用在用户实际会注意到的功能上吗？）

我对代码感到焦虑的原因是：

1. 类层次结构复杂且不明显
2. 某些课程没有明确定义的目的（他们会做一些无关的事情）
3. 有些类使用其他内部（它们被声明为友元类）来绕​​过抽象层以获得性能，但我觉得它们通过这样做打破了封装
4. 有些类泄漏了实现细节（例如，我之前将地图更改为哈希映射，发现自己必须修改其他源文件中的代码才能使更改生效）
5. 我的内存管理/池化系统有点笨拙且不够透明

它们看起来是重构和清理代码，帮助未来维护和扩展的绝佳理由，但可能非常耗时。另外，对于我写的任何代码，我都不会非常满意......

那么，stackoverflow会怎么想？清理代码或处理功能？

Answer 1

我认为如果你觉得有必要重构这段代码，那么你还没有“完成”它。

我认为随着你的进行重构要好得多（假设你有测试并遵循TDD的红色，绿色，重构方法），但考虑到你的位置，告诉你“你应该”的内容没什么意义。已经完成了。

我建议你重构一下。然而，我的实用主义者会给出以下警告 - 代码永远不会“完成”，所以这次你的重构时间框（所以给自己一两个小时，保持测试通过，然后称自己为“现在完成”）和然后每次你接触代码时都要按照boy scout rule并在每次检查时清理一下代码。随着时间的推移，你将清理这段代码 - 并且将来尝试重构代码作为开发过程的一部分，而不是在开发结束时做的大任务。

Answer 2

现在重构它。

由于您甚至考虑重构，听起来您可以腾出时间。如果你将它留待以后，你可能会忙于其他事情并失去这个机会。当计划变得紧张时，客户可以了解您是否需要一些额外的时间来完成新功能。当你告诉他们你需要额外的时间来重写已经有效的东西时，他们就不那么理解了。

Answer 3

从我可以告诉你的是一些完美主义者，并希望尽可能保持你的代码清洁，一个有价值的特性，但在商业中你必须考虑你正在做的成本效益分析。如果代码符合规范并且还有更重要的功能可供使用，请记下您要重构代码并继续操作。如果你有空闲时间，你可以回来。

Answer 4

如果此代码已经通过QA，那么也许您应该按原样释放它并接受代码债务。如果有时间花在它上面，我会选择最恶劣的部分并尝试重构这些部分，例如包装你的哈希表实现。否则，列出要改进的事项列表，并根据您未来的变更请求进行改进。

了解自己，您将不会对代码感到满意，这是很好的。请记住，所以你不要让你的完美主义妨碍定期发布。

Answer 5

在你的一条评论中，你说“很多代码都会建立在它之上。”你说它运作正常，但如果它是草率的，并且在糟糕的设计原则上起作用，随着时间的推移，改变任何东西都会变得越来越难。一般来说，一段代码越重要，它应该设计得越好。在您添加内容之前（在合理范围内）获取设计。

另外，编写软件的主要目标之一（在我看来）是管理复杂性。如果你有工作，你就完成了一半的工作。另一项非常重要的工作就是让事情变得相当容易理解和改变。如果没有这些，您将创建对更改无法很好响应的软件。软件需要改变。常。

我的公司有一些软件在它的婴儿时期非常笨拙地建立起来，并且多年来添加的每一个小变化都已经在已经邋foundation的基础上被轻易地钉上了。现在它正处于人们要求简单事物的地步（例如鼠标滚轮支持滚动），而首席开发人员回应“你不知道为了做到这一点我将不得不改变多少”。但是，如果代码在写入时（或之后不久）被清除，我们就不会有这个问题。

如果你现在有一些草率，设计不佳的代码，它会在以后咬你。特别是如果有很多其他代码写在它上面。

Answer 6

其他人是否有可能遭受你所遭受的恐怖？当我有可怕的代码即将被释放到野外我倾向于清理它，但如果我是唯一一个将受到维护和处理它的人，我会让它恶化一段时间，因为它运作得很好，如果我坐在它上面，我甚至可能想出一个比我受到启发立即“修复”它的更好的解决方案。

当然，恕我直言。

Answer 7

“有些类泄漏了实现细节（例如，我之前将地图更改为哈希映射，发现自己必须修改其他源文件中的代码才能使更改生效）”

这足以让它值得付出努力。根据定义，这是用户实际注意到的东西。

需要考虑的其他一些重要事项：

• 可维护性 - 修复任何不可避免的错误会有多容易？
• 可测试性 - 将代码转换为更可测试的形式是重构它的好方法。然后添加单元测试意味着您可以更改它并确切知道什么是中断。
• 可扩展性 - 您认为您是否需要添加新功能？

真的唯一一次你不想考虑让你的代码变得更好是如果你确定你永远不需要再次触摸它（即从不ALMOST）。

Answer 8

“我刚刚完成......”

听起来你正在积极编写遗留代码，这不是一件好事。您已经强调了许多可能需要重构代码的原因，但正如您所说，它适用于规范，因此不需要保留现有成本。

从好的方面来说，代码如何工作（并且应该工作）可能在你的脑海中是新鲜的，所以现在的重构可能比后来的重构更便宜;另一方面，稍后重构后会考虑实际的变更请求，这会增加重构方向的可能性。

将来，我会认真考虑在编写代码时放慢速度并提前思考。你去的时候重构（或保理！）要容易得多，你没有“但它有效”的压力来保持原样。

观看。如果您发现某个课程似乎正在承担多重责任，请停下来思考您是否需要将职责分离到不同的课程中。

如果您注意到要进入类的内部，请停止并确定类之间的接口应该是什么，这样您就不需要知道并使用具体的类'internals。

Answer 9

研究稍后会导致错误的方面。不要金板。

Answer 10

实际上并没有那么复杂。请遵循以下规则：

经常重构代码。每当可能时重构。

因此，如果您认为可以重构代码，那么您应该立即执行此操作，之后在所有代码紧密结合后变得更加复杂。

Answer 11

现在你有了推荐实施。如果你有动力，那就去重构一下吧。不要害怕扔掉，继续前进或重新开始。

也许根据消费者代码重做api /接口并自上而下重构。

您不应该被拥有公共数据成员所困扰。人们写了太多的访问者，这些访问者最终都是为了好玩而打字，坦率地说是真正愚蠢和令人沮丧的错误的来源（唯一没有错误的代码是从未编写过的代码）。这太刺激了。仅封装以保护脆弱状态（当成员数据状态耦合时）。

Answer 12

  

那么，stackoverflow会怎么想？   清理代码或处理功能？

我在这里看到的问题是，如果你重构，你必须支付的价格与不支付的价格。

如果你保持原样，那么任何维护都会花费你（额外的时间，每次更改增加新缺陷的可能性增加）和作为开发人员的声誉（任何其他编程人员可能会诅咒你:) ）。

如果你可以保证没有人再次触摸那个代码（不是因为它太可怕了;））你可以放心地保持原样。 （作为开发人员10多年来，我从未发现过可以保证这种情况的情况。）

在所有其他情况下，你最好还是重构。

  

他们看起来很有理由   重构和清洁代码，帮助未来   维护和扩展，但可以   非常耗时。

您无需使代码完美。实际上，您应该一次更改一次，并在迭代中重构，如果您这样做，它将不会影响任何其他代码。

这意味着您应该能够根据您的可用时间进行重构，而不是相反。

例如，如果您只在三个或四个单独的类中打破一个多用途类并使用它更新代码，那么您将使其余代码与以前一样工作。如果你没有完成这个改变的时间，你可以保持原样（只是在一个区域更清晰）。

如果您有更多时间，可以进行下一次重构并重复。

此外，如果您使用分支源控制系统，您甚至可以并行工作以进行重构并以相对较少的额外成本添加新功能（并在您有更多时间的情况下继续重构）。

Answer 13

我总是说重构。每一行额外的代码和所有那些唠叨小小的陷阱都会回来并咬你的屁股。

将来你甚至可以随心所欲地进行重构 - 时间永远不会过时 - 即使你扔掉它，你仍然学会了如何做得更好。

Answer 14

如果您有一组测试来验证您的代码现在是否正常工作，并且在您重构之后，那么我会说，如果您有时间，请修复它，因为它会花费您更多时间。但是，如果时间紧迫，那么将其作为代码债务并在更好的时间回归它是完全可以接受的。如果代码有效，你现在可以用它来完成一个非常好的释放，并在你有更多的时间和更少的压力时再回到它。

Answer 15

如果您有一组自动化测试可以验证您的代码是否正常工作，那就太棒了 - 继续并重构它;现在是最好的时间，虽然它在你的脑海里是新鲜的。如果你不这样做 - 使用这个时间，虽然它在你脑海中是新鲜的，但是要编写测试。如果你有时间只进行测试或重构：编写测试，以便以后重构更容易（有些人会说可能）。

TDD周期 RED-GREEN-REFACTOR ，它表示在设计良好之前你没有“完成” - 也就是说，直到它不再需要重构为止