JavaであってJavaにあらず
JavaBlackさんの日記にコメントしたついでに。
某大手SI業者に勤める知人から聞いた話。そこではJavaを使っているけれど、なんか変だ。
- staticばかり。staticなクラスにstaticなメソッドにstaticな変数。
- 妙にでかいクラス。妙にでかいメソッド。なんでも2000行を越えるメソッドがあったとか...
- if文が深い深い入れ子になっている。
- やたらとフラグを多用する。
- 変数名が全部大文字だったりする。
- クラス名や変数名は意味不明な文字列で、仕様書を見ないと何の用途かわからなかったりする。
- (追記)コピペ＋書き換えしたコードが山のようにあるが、継承を活用したコードはほぼ皆無。
なぜこんなことになってしまったのか？ その会社の標準化がそうさせたのか、はたまたプロジェクトマネージャの知識に合わせたらそうなったのか... まあ、過ぎた事はしかたない。詮索はやめよう。
でも問題なのはこういうコードの品質と保守性だ。
staticばかりということは、それらのクラスはstatefulと思ってよい。statefulなクラスのテストは難しい。というか、テストケース数をいくつ用意したら良いのか見当すらつかないことになりかねない。つまり、テストしきれないと思ってよい。また、変数がグローバル宣言されているようなものだから（まあ、COBOLな人にはそれが当然なんだろうけど）、どこかをいじくると必ず副作用が発生する。つまり、保守性も著しく低下している。
巨大クラス・巨大メソッドやif文の深い深い入れ子も、抱える問題はほぼ同じ。仮にstatelessなクラスであっても、規模がでかければテストしきれないことになる。
そして何より、こういうコードを書くプロジェクトではまずjunitみたいなテスト機械化ツールは使われていないと思ってよい。仮にjunit使おうとしても、巨大クラスではテストケースすら列挙できないはずだし、statefulなクラスが相手なら問題はもっと厄介だ。おそらくは本番業務で使うあたりを徹底的に手作業でテストさせて、その周辺のバグは取ってある、というところだろう。[*1]
こうして、保守性も品質も低い（ただし本番で使う分にはとりあえず問題ない）コードを開発することで、プロジェクトが肥大している、というのが今の日本のシステム業界の現実ではなかろうか。
と、これは産経の記事に突っ込む前振りだったりする。（つづく）
