iRefactoring

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

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

我们便不得不一边咬着牙恨恨骂着，“当初是谁写的这么烂的代码，等完事以后一定要好好重构一下”；一边给它加上一个if/else。但事情过后，我们往往就会安慰自己说，“这个类改起来太麻烦了，能用就行了，以后应该也不用动了。”可是还没等时间抹平心底的伤痕，这个类就又要改变……

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

如果，如果能有一些数据会说话。它来告诉我们哪些地方被修改的次数最多，复杂度又高，测试覆盖率又低，是不是我们就再也没有逃避的空间，正视“必须动手重构”的事实？

于是，就有了iRefactoring这个工具。它可以根据代码的提交次数和圈复杂度/测试覆盖率生成报表。

* Installation

. install ruby (1.8.7) 

. install rails 2 (2.2.2 or above)

* Configuration

 * 配置文件

项目的配置文件为config/project.yml。

假如你有两个项目，project1和project2，它们同处在同一版本仓库的trunk目录下，它们用的都是c#（iRefactoring目前不支持多语言项目），使用的版本控制工具是Hg，则project.yml应该写成这样：

   :vcs: Hg

   :language: csharp

   :projects:

      - project1

      - project2

* 数据导入

系统报表需要三部分数据：代码提交的log，测试覆盖率，圈复杂度。

log文件需要放在projects目录下，你可以用hg log -v >> hg.txt，或者svn log -v >> svn.txt，git log --name-status >> git.txt 来得到log文件，然后复制到projects目录。

测试覆盖率和圈复杂度的数据文件都需要自己写脚本解析度量结果生成，前者命名为coverage.txt，后者命名为complexity.txt。其中每一行都是一个类的度量结果，格式为 classname:89% 或者 classname:100 。可以参见projects/example目录下的文件。

注意：生成数据文件的关键点在于类名要跟log文件中的文件名保持一致。不相符的地方要进行转换，比如数据文件中用的是绝对路径，而 log中用的是相对路径，这就要在脚本中处理了。

配置文件中有一项classpath是特别为java项目设置的，因为java的静态分析数据通常为 org.irefactoring.model.xxx这样的格式，而log文件中则会是全路径名，例如/src/main/java/org /irefactoring/model/xxx.java，于是你就需要进行这样的设置：

    :classpath:

        - /src/main/java

然后系统就可以进行适当的转换了。