如何抉择重构？

重构是一种改变软件系统的过程，在不修改代码外部行为的情况下，改善其内部结构。在大多数敏捷团队中，改善已有代码的想法是受欢迎的。毕竟，持续改善是这些团队为之奋斗的事情。但是，改善已有代码牵涉到时间和金钱。这样做值得吗？

重构涉及到的成本有这些：

• 做重构的成本
• 测试更改的成本
• 更新测试和文档的成本

同时，如果单元测试以及测试工具没有达到标准，系统会有引入新缺陷的风险。 在极限编程项目中，总是假设项目有很好的单元测试，这种风险就很低。另一方面， 重构有一些好处：

• 添加新的功能不会破坏系统的结构
• 可以提高对系统的理解
• 更容易测试
• 更容易找出、隔离以及修正缺陷

影响重构的决定有哪些参数呢？

John Virgolino 认为，用金钱去衡量重构带来的利益，这道数学题并不复杂：

你无需做复杂的业务分析，保持其简单。重构需要多少时间？再乘以一个按小时或按天算的成本因子就可以了。 $60000 薪资 × 1.25 = $75000 负担成本

$75000 成本 / 12 个月 / 22 个工作日 = $297.61 (每天的成本)

现在，3 天时间做代码重构 × $297 = $891 重构成本（这就是你的投资）

下一次做代码改动时，之前没有重构的话需要 5 天时间（5 × $297 = $1485），而重构过的话只要 1 天时间就可以做相同的代码改动（1×$297 = $297）

$1485 - $297 = $1188（节省）- $891（初期投资）= $297.00 总共节约成本

此时，投资已经自我偿还了，而且未来会带来很多意外的成本节约，并且可用于提高其他产品、项目、文档、计费工作等等的生产率。

做类似定量分析的 Simon Johnson 认为， 重构后生产率必须有一定比例的提高， 这样才能调整重构成本，Simon 说：

对于重构，为了让它同把钱存在银行而言成为一种更好的投资，你必须提高 5-8% 或更高的生产率。这是一个相当大的要求，我非常怀疑这样的目标在实践中能否达成。如果你的机会成本远高于“帐户 B”描绘的数目，那么你最好把钱花在其他地方，比如新的功能或者减少缺陷的方法。

不过，除了成本，还有其他因素可能导致重构不是可行的策略。

Mark Needham 在重构困境上做了评论，他举出了最后期限很紧张的项目作为例子。如果团队在某个指定时刻开始重构，他们不会看到重构带来的任何回报。Mark 认为，尽管重构有一些好处，但是，他很少看到仅仅由于重构让代码在今后易于维护，就赶上交付日期的情况。

John 也提出了类似的场景，那时重构可能不是一种好的选择：

虽然总得来说，管理层可能也有很好的理由不做重构。这可能与金钱或时间都无关，可能是一个战略决策，甚至是合同的原因（比如政府工作）。确保你自己也了解整个故事。我也见过很多人在讨论你要在工作之余做重构。这无疑表明你对重构技术的信念和喜爱，但我不会在真空中做重构。我见到过程序员去做重构，结果导致团队其他成员和整个项目陷入混乱。

Mark 同时还指出，有时候项目周期可能太短了，不值得为重构投资。为这种项目做重构投资可能是徒劳无功的练习。

因此，尽管引入重构必然会有好处，是否决定在特定时间、特定情况下去做重构，必须谨慎对待。关键在于权衡利益，然后判定哪一个会带来最高的商业价值。

查看英文原文： The Decision to Refactor