如何抉择重构?

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

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

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

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

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

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

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

This entry was posted in 未分类. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s