不要なstaticメソッドの見分け方。。

質問

実は既に構築されているJavaアプリケーションで異様にstaticを多様しており
要・不要を分けてstaticの意味がないものはstaticを削除する事になりました。

staticの変数だけでも1300以上あり、まずは機械的に振分けたいと思っています。

思いつくのは、アクセス修飾がprivateか、省略されている場合にはローカル
使用と判断してstatic不要と判断出来ると思っているのですが。。。

その他によい見分け方がありましたら、是非、ご教授下さい。

実は、私が作ったものでもなく、突然の依頼でオロオロしているため、
アドバイス等でも何でも頂けると嬉しいです。

どうぞ宜しくお願い致します。

回答No.5

sasadora · ベストアンサー

それは大変ですね。始めに作った人はなにも考えずにstaticにしたんでしょうね。

>実は、実際にstaticにしていた為の障害が発生してしまったのです。
>その箇所は修正したのですが、他にこのようなケースがないかを

大変重要なことだと思います。対応するのは非常に大変ですが、対応漏れがあると、また同様の障害が発生するかもしれませんね。
仕様が分からないnsakurakoさんがやるのは、理不尽だと思いますが、そこは、やらなければいけない仕事と割り切って、やることを考えてみました。

1)static宣言している箇所を、漏れなく列挙する
　→「修正対象の候補」の列挙
2)列挙した「修正対象の候補」を利用している箇所を全て列挙する
　→「利用箇所」の列挙
3)列挙した「利用箇所」のstatic要・不要を仕様から判断する　（機械的にできない一番大変なところ）
4)不要なstaticを除去する

こんな感じで考えてみました。
大変なのは2)と3)です。
3)は仕様を知らないと判断が難しいと思いますが、2)によって利用されている箇所が“全て”分かっていれば、かなり判断がつきやすいと思います。

そこで2)を楽に行なう方法ですが、
eclipseを使っていれば、ある変数を参照している箇所を簡単に検索することができます。(他のツールでもあるかも知れません）
変数を選んで、[検索]-[参照]-[プロジェクト]とするとプロジェクト内でその変数を参照している箇所が分かります。
これを使うことで、2)の作業は機械的に行なえると思います。

また、nsakurakoさんが、static変数についてよく理解しておく必要があります。No.1の方が指摘するような間違った修正をしてはいけませんからね。
私が思うに、サーブレットを使っていて、定数以外に対しても、意味も分からず、ついstatic変数を使ってしまった輩がいるケースではないでしょうか？
意図的にstatic変数を使っている箇所は０ではないのか？というわけです。
＃書いた人が、グローバル変数代わりにstatic変数を使っているようなケースだったらアウト。

であれば、static final以外のstaticをすべて取り除いて、全テストやり直し！っていうのも
最も安心できるやり方の一つだと思いますよ。

お礼

お礼が遅くなりまして申し訳ありませんでした。

アドバイスは是非、参考にさせていただきます。
やはり、キチンとした調査に必要な工数を別途調整してもらう方向で
進めていきたいと思います。

ただ、アドバイスの通り、現段階までで調べた限りは
staticに意図的にしているのは1300件中2，3件だろうと
推測されますので、staticを取り除いて全テストの方が
工数的には早いだろうという気はとてもしています。

丁寧なアドバイスを本当にありがとうございました。

回答No.4

pcbeginner

心中お察し致します。

まずstatic変数だけでも1300以上あるとのことですので、
単純に機械的に要・不要を分けるのを考えると
1.
staticメソッドをgrepしてみて、
もし1回も呼ばれていなければ(まずあり得ないと思いますが…)
static以前に不要なメソッドです。

2.1.同様にgrepしてみて
すべてstatic参照されていなければ
「(どういう設計意図があったかは分かりませんが、今のところ幸か不幸か)staticをとっても構わないメソッド」
です。

3.～static final～な変数、つまり定数
これは定数なので調査対象からは外していいと思います。

とりあえず今、自分が思いつくのはこんなところです。
もし的外れなことを言っていましたら申し訳ありません。

上記以外は他の方も仰っているように、
1つ1つちゃんと見ていくしかないと思います。

これで少しでも減るといいのですが。
がんばって下さい。

お礼

お礼が遅くなり申し訳ありませんでした。

教えて頂いたアドバイスを参考にさせて頂きます。
丁寧な解説をありがとうございました。

回答No.3

torakiyojp

実際に作業しなければならないとなると、余り良い考えは浮かびませんが、考えてみたことを書きます。

> 要・不要を分けてstaticの意味がないものはstaticを削除する事になりました。

これは危険すぎます。
staticじゃまずいものだけ削除するようにした方が、危険は減ると思います。

1300以上ですか、大変ですね。
まず、Stringクラスでfinal宣言されている変数。
これは、放っておいても悪さしないでしょう。
これを除くとどれ位残りますか？

正直、答えきる自信は余りないです。

お礼

返事が遅くなりまして大変に申し訳ありませんでした。

> まず、Stringクラスでfinal宣言されている変数。

final宣言を差し引いて1300件あります。（T*T;）

製造者さんは悪気があって使用した訳ではないと思いますが、
事実上、全箇所の調査はやはり非現実的ですよね。。とっほ。

> 正直、答えきる自信は余りないです。

いえ、このように回答頂けただけでも本当に心強いです。
ありがとうございました。

回答No.2

sha-girl

>申し訳ないです。説明不足でした。
>例に出して頂いたようなクラスの場合にはstatic不要と判断して
>下記のように修正するつもりです。
>
>class B{
>private int i = 0;　←★privateにする！！
>public int Get(){
>return i++;
>}
>}

むやみにstaticをprivateにすると挙動が変わるかもよと言いたかったのですが。
わかっているとは思いますが念のため

B b1 = new B();
B b2 = new B();
System.out.println( b1.Get() + "\n");
System.out.println( b2.Get() + "\n");

staticのままだと
0
1
と表示されていたのがprivateにすると
0
0
になります。

変更していいかどうかは、そのメソッドが何をしたいのかを把握しなければ
無理ですね。。。

お礼

度々、丁寧な回答を本当にありがとうございました。

おっしゃる通りです。
私の勘違いでした。

あやうく、とんでも修正をする所でした。
親切な解説をありがとうございました。

でも、やはり、自分で1300個を判断しないとダメなのですね。。。
うぅぅ。。

回答No.1

sha-girl

つまりstatic宣言が不要なのにstaticをつけている？
どういうソースなんだか、よくわかりませんが、
別にstaticだからパフォーマンスが下がるわけではないと思いますし
ほっといたのでよいかと思います。
まずいえるのは機械的にstaticの要、不要の判断をするには
コンパイラを作る以上に高度な事です。事実上不可能。

>アクセス修飾がprivateか、省略されている場合にはローカル
>使用と判断してstatic不要と判断出来る
class B{
static int i = 0;
public int Get(){
return i++;
}
}
こんなクラスがあってstaticを削除したら大変でしょう。
プログラム全体が動かなく可能性があります。

お礼

早速の回答をありがとうございました。

> まずいえるのは機械的にstaticの要、不要の判断をするには
> コンパイラを作る以上に高度な事です。事実上不可能。

そうなんです。"o（>。<）o"
私もその旨を上司に伝えたのですが納得してもらえず。。。。。

実は、実際にstaticにしていた為の障害が発生してしまったのです。
その箇所は修正したのですが、他にこのようなケースがないかを
調べろとの依頼が仕様も知らない私にやってきました。。とっほ。。

２つ、３つなら、いやいや数十個ならば、自力でソースを追いかけて
自力で判断しても良いのですが、1300以上となるとまさに非現実的で。。

>> アクセス修飾がprivateか、省略されている場合にはローカル
>> 使用と判断してstatic不要と判断出来る

> こんなクラスがあってstaticを削除したら大変でしょう。
> プログラム全体が動かなく可能性があります。

申し訳ないです。説明不足でした。
例に出して頂いたようなクラスの場合にはstatic不要と判断して
下記のように修正するつもりです。

class B{
private int i = 0;　←★privateにする！！
public int Get(){
return i++;
}
}

もし、また、何かありましたら、是非、宜しくお願い致します。
少なくとも非現実的だという意見を頂けて救われる思いでした。
ありがとうございました。