業務系システムを軽く作る

JavaとWebサイトの親和性 を見てもやもやと考えてしまった。

「WWW系」と「業務系」の区分 っていうのはなんとなく明確にあるのだけども、時代の流れとしてはどんどんボーダレスになっていくというか。
JavaはLLへの接近を図ろうとし、PHPは業務系システムへ乗り込もうとしているし。
Blogの業務系への展開が最近の流行みたいだけど、多分それ以前はナレッジ共有システムなんて名称で同じ目的に使われるものが割高な開発手法で構築されていたことは想像に難くない。

多くの業務系プロジェクトにおいては、頭数を揃えるというのがまずプロジェクトのミッションとしては重要視され、個々人の質の高さに依存するというのはニの次となっている。
そして誰もが同程度のスキルでプログラムが出来るように実装手段を平坦化するような開発手法をとり、担当者への負荷を下げ、交換性を高める･･･というのがある種の理想だろう。
複雑度規模の大きさからそういったことが好ましいと思われているようだが、その結果、実際の開発現場から生み出されているものは相当貧弱ではないか。

複雑度規模を下げ、業務系システムを軽く作ることが個人的には大いに興味がある部分。
複雑度規模の大きさって抽象的に書いたけど、情報化対象要素の多さであり、つまりこういうことだと思う。

・画面数が多いこと
・テーブル数が多いこと
・機能が多いこと

「画面数が多いこと」はどうだろうか。
画面からロジックを引き剥がしてしまえば、他の部分と比べても複雑度はそれ程高くないし･･･というか画面で重要なことってもっと別だと思うし･･･なんとかなるだろうか。
･･･個人的にはせいぜいパラメータ埋め込み式のテンプレートを想定していて、ＪＳＰでもいいのだけども、なんかテンプレートシステムと言い切るには自由度高すぎませんかＪＳＰって。

「テーブル数が多いこと」はどうだろうか。
O/Rマッピングも「多いこと」に対応する一つの方策だと思う。
っていうか、結合時の負荷とかもあるだろうけど、「ファクタテーブルの分だけマッピングオブジェクトがあればいい」って誰か言い切ってほしい。
ただもっとうまいやり方がありそうな気もする。

「機能が多いこと」はどうなんだろうか。
ちょっと思いつかないな、保留。

あとは小さな事からコツコツと 作ることもひとつの指針だろうか。

っていうかこの記事続き書くかも。