リファクタリングブラウザ

『リファクタリングブラウザ』というツールのジャンルが確立されつつあるようだ．
私が初めてこの単語を聞いたのは，サークルの後輩であるohaiくんがRuby Refactoring Browserのプロジェクトを立ち上げるときの説明で，もう1年は前になる．例としてこのRuby Refactoring Browserを機能を紹介すると，

• 変数/定数の名前を変える
• クラス名/モジュール名の名前を変える
• 特定クラスの指定されたメソッドの名前を変える
• メソッドを別のクラスに移動する
• コードの一部分をメソッドとしてくくり出す

といった作業を，Rubyのソースコードに対して自動的に行ってくれるというものだ．これが便利かを判断するには，まずはプログラマの一日を丹念に振り返ってみるのだよいだろう．
この様な作業――いわゆるリファクタリング――は，意外と多くの時間をプログラマから奪っている*1．実際，今週一週間私が研究室で過ごした時間の大半は，年代物のFortranのソースコードからSun Fortran 77固有の部分を書き換えるという仕事に費やされた．さすがに量が多いのである程度は機械的に書き換えるための簡単なツールをC#で作って対処している．しかし，所詮書き捨てのコード，構文木解析などは使えない．やっているのはディレクトリを再帰的に辿りながら行ごとに正規表現によるパターンマッチ程度である．当然これで対応できない問題には手作業で対応することになり，それが思った以上に時間を消費することがある．このように場合によってはある程度複雑な構文も機械的に対処した方が早いこともあり，その見積もりを瞬時に行う必要がある．この様にエディタのマクロを使って書き換えるかそれとも手作業で書き換えるかふと立ち止まって悩んだ経験は，多くのプログラマに心当たりがあるのでないかと思う．
現在C#やJavaなどを対象としたリファクタリング用のツールが増えてきている．次期VisualStudioこと"Whidbey"にもリファクタリング機能が追加される，と発表されている．
リファクタリングの自動化の難しさが言語の特性に大きく依存するのは間違いない．今後ビジネス市場を狙う言語は，入力支援のしやすさ・デバッグのしやすさ・自動リファクタリングのしやすさといった特性を無視できないように思う．一例としてVisualC++ .NET 2003とVisualC# .NET 2003のIntelliSenseの精度の違いが挙げられる．ヘッダファイルやマクロ関数など構文解析を阻害する機構を排除したことは，何もビルド時間短縮にのみ役立っているのではない．この様なリアルタイム性が要求される入力支援において大きな差をもたらしている．

*1:たいして頭を使わずに出来る作業なので，考えようによっては休憩時間を与えているとも言える