最近、今のシステムを人に紹介する機会が2度ほどあった。
・新規参入者とかお客さんの新人とか向け：約20人。2日間で1時間ずつ
・自分の部署のアーキテクチャグループの人向け：10人チョイ。40分くらい
説明してるときのリアクションみるだけで、
うち部署のアーキテクチャグループのレベルの高さがわかります。
やっぱりこういう技術屋の集いは必要かなぁと思います。
さて、本題です。
説明をするにあたって、改めてシステム全体の概要を見渡すと
“青写真自体は非常によくできている！”
ってのがよくわかる。
某巨大SIerの優秀なアーキテクトが当初はいたんだろうなぁ。
(もう3年くらいやってるらしいんで。このプロジェクト。)
今の全然正規化されていないデータモデルが、
データベースのパーティション化とリンクしたプロセス多重実行
のためにわざとそうしていることや、
(I/O待ちを設計段階でここまで意識できるJava屋は今までみたことない)
オンライン処理用のサーバーにおいて
RAC(RealApplicationCluster)構成における
Oracleのインスタンスが2台でも、3台でも、4台でも、6台でも、8台でも
いけるように拡張性を持たせていることや、
(24時間365日稼動で、且つ、拡張性があるってのはこういうことだ)
バッチ処理用のサーバーにおいて
デュアルコアのCPU20発積んで、100ギガ近いメモリを積んでる箱
を足していけば、処理対象件数が増え続けても、
同じ時間内で全てを処理できるようになっていること。
(理論上、業務ロジックの難易度が高い数億件の処理も一晩で十分さばける)
Webは一般的なStrutsの仕掛けだけど、
できるだけプログラマがソースを書くとこをとことん減らすって思想や、
なんでもかんでも自動生成したコードを使って定数化することで、
コンパイルレベルで判別してエクセプションを回避させそうとするやり方とか。
WebサーバとAPサーバの負荷分散とか、
後々の拡張性を考えた構成になってる。
バッチはかなり男前な仕掛けで、
バッチのくせにstruts-configまがいのXMLを記述することで、
XMLに部品の組み立てを処理順に記述すれば勝手に処理が流れていく
クラスに渡すパラメータは実行時にApacheのDigesterが
setterインジェクションしてくれる。
クラス間の値の持ち回りはServletコンテキストまがいの、
バッチコンテキストなるオブジェクトが担当する。
せっかく、こんなイケてるアーキテクチャにも関わらず、
(もしこれが一般的なのだとしたら、明らかに俺の周りは勉強不足だが)
ベンダー間のくだらない契約上の理由で、
アホみたいにラッパークラスが増えて、
プログラマにとって非常にトレースしずらくなっている。
それだけでなく重要なフレームワークの上位クラスを
低レベルな開発者によって実装されてたもんだから
(あんま人のこと言えないけど)、見るに耐えない実装も存在する。
Webアプリケーションの分割単位も、
何にも考えないであっちこっちにコネクション張ったりするもんだから、
拡張性が十分考慮された疎結合アーキテクチャが台無しだ。
(Webサービスってのはこういうとこで使うんだと思う…)
場当たり的なツギハギだらけのこのシステムは
もはや救いようがない。
(俺がこんなこと言ったらおしまいだけど…)
あー、勿体ねぇなーって。
でも、Javaを使った本当の意味でのエンタープライズなシステム。
勉強させてもらいました。こんな経験なかなかできません。
それでも技術の移り変わりってほんとに早くて。
時代はXML地獄からの脱却。Conversion Over Configration。
XMLで疎結合ってのも、やりすぎはよくないよねってなってきてる。
ってかJava自体重くない？って。
巷じゃ、まつもとゆきひろ氏作成のRubyが大ブレイク。
Ruby On RailsはLinuxが世の中にスパークした前兆と
同じものを感じると言われてる。
まぁ細かい技術は家でお勉強すりゃいい話。
大事なのは、どうやったら素敵なシステムの青写真描けるようになるか。
—
最近は、Ora！オラ！Oracleな事ばっかで。。。
やっぱりアーキテクチャがやりてぇよぅ。
コメント