保守不能ソースに立ち向かう

（Java+Eclipseが前提）

保守不能ソースに絶望しても、それに立ち向かわなくてはいけない時、
解読可能な状態に修正したいのだが、
リスクを取らずに定型的に行えることがある。

１）変数とメソッドのスコープを必要最低限にしてみる。

protectedや無印になっている変数をprivateにしてみたり、
内部からしか呼ばれていないくせにpublicなメソッドをprivateにしてみたり。
無駄なSetterだったり。

すると、実は使ってない変数やメソッドが浮かび上がってくるので、それらを思い切って削除する。
削除まで行かなくとも、外部から操作される可能性を絞る事ができる。

２）privateで一回しか呼ばれないようなメソッドは展開してしまう。

３）privateで数回呼ばれているけど、数行しかないメソッドは思い切って展開してしまう。

４）２，３をしたことによって判明した無駄なエラーチェックや重複している処理を省く。

メソッドにわかれているが故に無駄なnullチェックをしている場合がある。

５）Beanを使っている場合、そのSetterが消せないかどうか検討する。

この場合、BeanとはSetterとGetterをpublicで装備しているクラスを指す。
例えばInputStreamからBeanを作成するような場合、Setterを消して、Beanにファクトリメソッドを作成するのが有効。それだけで、外部から操作される可能性を消すことができる。

６）直感的に判りにくいクラス名や変数名は、Eclipseのリファクタリング機能でおもいっきり判りやすい名前に変える。

ローマ字だっていいじゃないか。"銘柄"を示すクラスを"Meigara"としてみるとか。

７）無駄に使い回されているローカル変数は、中カッコを駆使する等して、いちいち宣言しなおすようにする。

アセンブラのレジスタじゃないんだから変数を無駄に使いまわすのはやめようぜ。
これにより、ロジックの切れ目が判りやすくなる。

８）メンバにする必要のない変数は、メンバから外しローカル変数とする。

９）パッケージがかなり細かく分かれている場合、特にinterfaceとかlistenerとかで分かれている場合、思い切って全部一緒にしてしまう。

クラス分けに失敗している場合、どうあるべきかを考えなくてはいけないが、パッケージの区分けが考えの邪魔をしている事が多々ある。

１０）用途が限られているちっちゃいクラスやインターフェースについて、内部クラスにできないかを検討する。

もちろんスコープを絞るのが目的だが、別の効能として、パッと見ためにjavaファイルの数が減るだけで保守不能ソースに立ち向かう勇気が出てくるというのがある。