Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
iRefactoring可以通过对比代码提交次数和复杂度,指示项目中哪些代码需要重构。它的由来是Micheal Feather的文章: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=16679&tth=DYN&tt=siteemail&iDyn=2
branch: master

This branch is 60 commits behind xiaodao:master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
app
backup
config
db
lib/tasks
log
projects
public
script
spec
vendor
README
Rakefile
TODO
commit

README

每个项目都有可能出现遗留代码,或早或晚。

每个类都有可能是个很大的坑,动一动就会不小心掉进去。于是人们常说:如果它还能工作,或者是不怎么需要改动,那就先不碰它。

但墨菲定律总是会起作用的。那些避之唯恐不急的类,总是令人惊恐的出现在我们面前。这里要做hot fix,那里要加一个新功能──而且时间总是很短,短的来不及读懂这陀逻辑,来不及做上一点点重构。

我们便不得不一边咬着牙恨恨骂着,“当初是谁写的这么烂的代码,等完事以后一定要好好重构一下”;一边给它加上一个if/else。

也许这次比较幸运,很快就调试成功,我们松了一口大气,安慰自己说,“这个类改起来太麻烦了,能用就行了,以后应该也不用动了。”可是还没等时间抹平心底的伤痕,这个类就又要改变……

因恐惧而产生的不切实际的期盼,在周而复始中支离破碎。

如果,如果能有一些数据会说话。它来告诉我们哪些地方逻辑最混乱,被修改的次数最多,是不是我们就再也没有逃避的空间,正视“必须动手重构”的事实?

于是,就有了iRefactoring这个工具。它可以根据代码的提交次数和静态分析得到的圈复杂度生成报表。

图右上角的部分是问题最严重的代码,提交次数最多,复杂度也最高。出现这种现象常常是因代码逻辑已经让人没法产生重构的勇气,只能每次都是修修补补;但偏偏职责也很多,经常都要改动到。这通常是亟需改进的点。
Something went wrong with that request. Please try again.