iRefactoring代碼重構(gòu)輔助工具

每個(gè)項(xiàng)目都有可能出現(xiàn)遺留代碼，或早或晚。每個(gè)類都有可能是個(gè)很大的坑，動(dòng)一動(dòng)就會(huì)不小心掉進(jìn)去。于是人們常說：如果它還能工作，或者是不怎么需要改動(dòng)，那就先不碰它。

但墨菲定律總是會(huì)起作用的。那些避之唯恐不急的類，總是令人驚恐的出現(xiàn)在我們面前。這里要做hot fix，那里要加一個(gè)新功能──而且時(shí)間總是很短，短的來不及讀懂這陀邏輯，來不及做上一點(diǎn)點(diǎn)重構(gòu)。

我們便不得不一邊咬著牙恨恨罵著，“當(dāng)初是誰寫的這么爛的代碼，等完事以后一定要好好重構(gòu)一下”；一邊給它加上一個(gè)if/else。但事情過后，我們往往就會(huì)安慰自己說，“這個(gè)類改起來太麻煩了，能用就行了，以后應(yīng)該也不用動(dòng)了。”可是還沒等時(shí)間抹平心底的傷痕，這個(gè)類就又要改變……

因恐懼而產(chǎn)生的不切實(shí)際的期盼，在周而復(fù)始中支離破碎。

如果，如果能有一些數(shù)據(jù)會(huì)說話。它來告訴我們哪些地方被修改的次數(shù)最多，復(fù)雜度又高，測(cè)試覆蓋率又低，是不是我們就再也沒有逃避的空間，正視“必須動(dòng)手重構(gòu)”的事實(shí)？

于是，就有了iRefactoring這個(gè)工具。它可以根據(jù)代碼的提交次數(shù)和圈復(fù)雜度/測(cè)試覆蓋率生成報(bào)表。

* Installation

. install ruby (1.8.7) 

. install rails 2 (2.2.2 or above)

* Configuration

 * 配置文件

項(xiàng)目的配置文件為config/project.yml。

假如你有兩個(gè)項(xiàng)目，project1和project2，它們同處在同一版本倉庫的trunk目錄下，它們用的都是c#（iRefactoring目前不支持多語言項(xiàng)目），使用的版本控制工具是Hg，則project.yml應(yīng)該寫成這樣：

   :vcs: Hg

   :language: csharp

   :projects:

      - project1

      - project2

* 數(shù)據(jù)導(dǎo)入

系統(tǒng)報(bào)表需要三部分?jǐn)?shù)據(jù)：代碼提交的log，測(cè)試覆蓋率，圈復(fù)雜度。

log文件需要放在projects目錄下，你可以用hg log -v >> hg.txt，或者svn log -v >> svn.txt，git log --name-status >> git.txt 來得到log文件，然后復(fù)制到projects目錄。

測(cè)試覆蓋率和圈復(fù)雜度的數(shù)據(jù)文件都需要自己寫腳本解析度量結(jié)果生成，前者命名為coverage.txt，后者命名為complexity.txt。其中每一行都是一個(gè)類的度量結(jié)果，格式為 classname:89% 或者 classname:100 。可以參見projects/example目錄下的文件。

注意：生成數(shù)據(jù)文件的關(guān)鍵點(diǎn)在于類名要跟log文件中的文件名保持一致。不相符的地方要進(jìn)行轉(zhuǎn)換，比如數(shù)據(jù)文件中用的是絕對(duì)路徑，而 log中用的是相對(duì)路徑，這就要在腳本中處理了。

配置文件中有一項(xiàng)classpath是特別為java項(xiàng)目設(shè)置的，因?yàn)閖ava的靜態(tài)分析數(shù)據(jù)通常為 org.irefactoring.model.xxx這樣的格式，而log文件中則會(huì)是全路徑名，例如/src/main/java/org /irefactoring/model/xxx.java，于是你就需要進(jìn)行這樣的設(shè)置：

    :classpath:

        - /src/main/java

然后系統(tǒng)就可以進(jìn)行適當(dāng)?shù)霓D(zhuǎn)換了。