SI業界、例えばの話

とあるシステムがありました。Javaで動いています。CalcManagerクラスとCalcクラスがあります。そのCalcクラスは取引先ごとに計算が違うのでそれぞれ実装が違っています。なんか新しい取引先が出来るたびに、CalcManagerとCalcと依存先クラス全部、つまりパッケージごと全部コピーしてCalcManagerとCalcの実装のコードを変更して対応したりする。確かに１から作るより効率的だ。だがね、その計算は仕様変更がバンバン発生する。その度に場当たり的な変更に次ぐ変更。同じクラス名なのに、内部の振る舞いは全く違っているファイルがあっちこっち存在。問題はCalcやManagerの粒度、つまり全うすべき責務の範囲がまったく違っていること。とにかく意図がわからなくなるんですよ。他人が見たときに。

こういうケースの場合、CalcはインターフェースにしてCalcの実装は違う名前でそれぞれ用意して(極端な話が「取引先名＋Calc」って名前でいいでしょう？)、CalcManagerはインターフェースCalcに依存するようにとかはじまっていくはずです。あまりにも当たり前な話なんですが、ずっと今までこうしてきたから、こうします。というか、インターフェースって何？みたいなことはあるわけですね。その場合にはそんなことは始まっていかない。例えばの話。ていうか、Managerっているか？とかさ？出てくるだろうはずなのに出てこない。

テストはしにくいし、Junit書いたって、結局Calcの責務は曖昧で無駄に肥大化してて、ばりばり依存してて、そんでnew()しようにもコンパイルエラーで、それだけでは全く動かない。依存Jarぐらいくださいよとか叫びたい状況とかね。例えば。

責務の粒度が大きすぎないか？小さすぎないか？とかは、オブジェクト指向を理解した人間が悩むのと、意図せず粒度が大きくなってたり、小さかったりっていう形で存在するものとの違いって半端でなく大きいよね？一生懸命ビジネスロジック書けばそれでいいのですか？じゃぁ何でJavaなの？　分かってる人はそんなコード見たら、真剣に考えてしまうと思うよ。この意図なんなんだ？新手のスタンダード手法か？俺って遅れてる？とかさ。無駄に心臓に悪い。

いつまでたっても、IT化できないIT企業というのは笑い話ではない。最近気づいてしまったんですが、ある部分(でも結構広い)のみなさんが設計設計言ってるものは、結局要件定義のことに過ぎないんだなってこと。UMLで考えたらユースケースとアクティビティ図くらいの範囲に過ぎない。昔はよかったのかもね。でもね、Javaって誰が書いても同じコードになんかならないんだな。要件定義は大事ですよ。そんなことは当たり前。

絶対的な淘汰の波がやってくる。淘汰された先に僕の前に広がる光景が良いものであるように。そうするには他力は当てにならないんで、勉強しているつもりです。ねむい。