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

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

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

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

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

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

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

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

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