前些日子在InfoQ看到篇文章 "抛砖引玉——重构是必要的浪费"
http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.
文中认为 “重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。
个人觉得这样的解读很牵强,也有悖于精益的基本精神。
我觉得问题核心在于重构对于客户创造了什么价值。
近日从金融学的角度来进行分析,略有所悟。
重构其实提供了“需求变化”的“看多期权”(call)--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大,这份期权就价值越高。而在金融市场上充满了明码标价的期权交易。
以TDD的三步骤(不可运行,可运行,重构)为例,可以看做实现一个功能的“现货价值”并附加该功能需求变化的“看多期权”。 而只完成功能要求程序,不进行重构,只能看单纯含有一个功能的“现货价值”。
对于客户而言,附加有“需求变化看多期权”的程序价值要高于只含“现货价值”的程序。
对于“需求变化看多期权”最坏的情况也就是“需求不变化”,这份期权就没必要行使。
这就是“需求稳定项目(如:学校大作业)”和“需求总是与时俱进的项目”在开发行为上存在差异的原因之一。
事实上,我觉得软件项目开发,充满了时间序列上的发生的不确定性,项目的过程中需要不断的吸收这种不确定性,并追求项目达到更高的价值。这种情况很适合以金融学的视角进行分析。
--------------------------------------------------------------------
有人回复EMAIL,做点补充:
引用
Steven Mak <
[email protected]>
回复
[email protected]
发送至 敏捷中国 <
[email protected]>
你說的其實跟文中其中一位討論者差不多呢:
-------------
Dec 18, 2007 1:13 PM by Kent Beck
While it's true that refactoring doesn't deliver features to
customers, features aren't the only source of value in software.
Another source of value is the option value of the software--software
that could be made to do any one of five things next is more valuable
than software that can only be made to do two things next. Refactoring
can add to the option value of software. This perspective can also
help teams select the most valuable refactorings out of the seemingly
infinite pool of possibilities. Perform refactorings that add to the
set of available and useful options, defer those that don't.
此回复是在出现在该文的英文版中
http://www.infoq.com/news/2007/12/refactoring-is-waste
提出的时间也要早得多,本来还以为想出点新意,却原来早有前人。