流行に乗って、大規模開発との違いを書いてみたりする

　大規模開発について、書いてあるブログが多い気がするので、ウィリアムのいたずらも流行に乗って？？１つ。

　一番大きな違いは、全体を見切ることが出来ないこと。
　システム全体も（全体概要は、わかったとしても）、プロジェクトマネージャーまでは、だれがいるか、わかっても、プログラムを作っている人は、見たこともないし、そもそも、どこで開発しているかもわからない（協力会社で、持込可の場合など。わかんない）。

　こういう状況の場合、訂正が効かない。

　仮にクラスのメソッドを修正するとき、直接プログラムに修正をかけてしまうと、（業務でも、完全に業務内容を作っている場合は、影響少ないけど、共通部分を作っている場合など）どこまで影響が出るかわからない。

　なんていうと、プロジェクトマネージャーに聞けばいいじゃん！？と思うかもしれないが、プロジェクトマネージャーも中身を把握してないケースがあって、そうすると、修正を簡単には出来ないし、修正するための手順ノウハウみたいなのがある
（さっきのブログで示した、返り値のハッシュマップに変更前の値も入れるような話）

---

　そのほか、これは、プロジェクトマネージャーの能力に起因してしまうんだけど、大規模開発では、このブログで、おっしゃるとおり、ドキュメントが多い。

　そして、そのドキュメントは、こんなふうにわけられるかな。。。

（１）ガイドラインとして、与えられているもの
　　　→実は、守んなくっても、それほど問題がない
（２）世間一般のことがまとめられているもの
（３）事務管理もの
（４）システムの設計上、重要なもの
　　４－１、ＤＢ構造など、今回の開発に必要なデータ、業務内容などの記述
　　４－２、パターンの開発思想など、標準化の考え方、方法についてかかれたもの
（５）インストールマニュアルなど、作業手順が書かれたもの


　おおざっぱな、独断と偏見だから、抜けもあるかと思うけど。。。
　で、問題は、プロジェクトマネージャーは、（３）は、自分にかかわるから、かならず忘れないのよ。（５）も、必要だと気がつくのよ。４－１も、このシステム独自だから、気づくのね。
　問題は、（１）と（２）と４－２の区別がつかず。。
　さらに最悪なのは、４－２の資料が、どれに相当するかわかならいプロジェクトマネージャーがいるのよ。

　そうすると、いろいろ資料を持ってきてくれるのはいいんだけど、肝心な資料が抜けちゃったり。。。

---

　大規模になればなるほど、
・システム全体の考え方や、
・フレームワークと、外部入出力・各開発部分の位置づけ、
・なぜ、そういうパターンやフレームワークを採用し、
・そのパターン・フレームワークを採用すると、どこに問題があるのか
　を早めに知って、それに対応しないといけない（あとで修正が効かないから）。

　だから、パターンに関する標準化資料（開発標準）というのが重要なんだけど、ひどい場合、その標準化の資料を渡してくれるのを忘れたりさあ。。。

　あきらかに、いくつかのソースコードをみると、
　　・標準化されているはずで、
　　・その標準化も途中変わり、
　　・その連絡が、途中で消えている（届いていない）
　つー状態で、「ここの標準化のドキュメントは？」って聞くと、「ありません」って、返事されたり
（ないのではなく、あるのを忘れているんだと思う）。

　そのへんの、どのドキュメントが重要で、仕事を出すのに、なにを見ないといけない、なには、省略しても大丈夫という境界線をプロジェクトマネージャーさんが理解しきっていないと、最悪の現場の混乱を招くっていうことがあると思う。

---

　あと、大規模の場合、どのレベルでパターンを切り上げて、部隊に渡すかの切り口とか、間違えると、えらいことになる部分があるんだけど（かならずしも、ソフトウェア工学でいわれている部分で切るのが、いいとは限らないこともあるし。。たとえば、クラスを細かく割って詳細化していくよりも、パターンに落とし込んで、継承させて、一部しか、いじれないようにするほうが、部隊への展開は楽なときがあるよね）。。。

　まあ、基本的には、一番大きな違いは、全体を見切ろうとしても、見切れないところに起因した問題が多い気がしますな。。。

　で、プロジェクトマネージャーが、「だから文書化だ！」などといって、容易に文書化したり、どっかのえらーい外国の先生の考えを単純に導入しちゃうと、「部隊を動かすのには、何が必要か」という部分が抜けてしまって、結局大混乱！なんていうことになるわけですな。

　小さいと、この辺、訂正が効くんだけど、大きいと、訂正したとたんに、なおさら大混乱になる。部隊に出す指示は、１度言い切りにしないと、わけわかんなくなる（小規模だと、お前が考えろでも、極論するとＯＫ）

　なんて、いうのが違いかな？と、独断と偏見で、思ったりします。

JAVAでRDBにアクセスするとき、SQL文、全部書きます？自動生成させます？？

　JAVAでデータベースにアクセスするとき、たとえば、

Statement stmt = con.createStatement();
String sql = "SELECT * FROM KAIGI_TBL";
ResultSet rs = stmt.executeQuery(sql);

　のような感じで、ＳＱＬ文を、「全部」自分で書きますか・・・？？

　私は、てっきり、書かないのが、普通だと思っていたんですよ(@_@!)
　つまり、
　　1.SELECTなり、UPDATEなり、ＤＢアクセスするための共通メソッドがあって、
　　2.その共通メソッドに設定する値は、ある程度自動設定し、
　　3.そのための設計書は、Excelで作られている。。。

　こういう開発ばかり（例外：この前の、ActionクラスからSQLを直接書いちゃう人）なので、最近は、そういう風に書くものかな？って思ってました。

　なので、前のブログに書いたように意識あわせのために、この記事を書きました。

　そうしないと、以前のブログなんかで、なんで、ExcelからJavaのプログラムが必要なのか、ぜんぜんわかんないですもんね！！

---

　一応、上記１～３について、説明しておきますね。

■■１について

　たとえば、データベースアクセスのSELECTをする場合（他もおなじようなもんなんでSELECTだけ説明します）、まず、こういうメソッドを、システム共通として用意しておきます。
（下のは、こんなかんじという雰囲気。正しいかどうかは確認しておりません）

　public Vector selectData(String[] komoku,String[] tbls,Vector whereKu,String[] sortKu) throws Exception
{
　// 中身は、こちら
　// メモ帳で書いて、チェックしてないので、間違えとかあるかも？？
}

これで、たとえ、どんなＳＱＬ文でも、返り値のVectorの中に、
　１レコード１エレメント（項目）で、
　　　　　　１レコードの中身は、ハッシュマップで、
　　　　　　　　キーは、カラム名、
　　　　　　　　値は、そのレコードにおけるカラムの値が、String型で
入っていることになります
（数値型のものは、Stringになっているので、使うとき、型を変える）

---

■■２、３について
　１で、komoku,tbls,whereKu,sortKuを、自動生成すれば、ＳＱＬ文がかけるということになった。
　で、そこでなんですけど、たとえば、Excelで、こんな雛形を用意して、


komoku[0] = "*";（全部検索）
tblsは、「アクセステーブル名」に書かれているテーブルをセット
whereKuの　１レコード目は項目名
　　　　　２レコード目は条件１、
　　　　　３レコード目は条件２を、（縦にみて）セットし、
sortKuを、ソートの順番をみて、設定するように、

　Excelファイルを読み込んで、Javaのプログラムを書き出す、自動生成プログラムを作ります。
　昨日までのブログで、この辺のものが作れることは、示しました。
（ここにまとめてある）
　ちなみに、ウィリアムのいたずらの主な仕事は、こういうものを作ることなので、ExcelからJava変換が重要だったのです。

　もちろん、条件式には、引数で渡された値をセットする
（たとえば > args[0]） みたいなときもあるので、すべて自動化で書かないほうが、
効率的かもしれない（それでも、自動化したほうがいいかな？？）

---

　で、よく、テーブルの項目名が変わったときっていうのが、問題としてあがっているけど、そんなもん、項目名をすぐに変えたら、いたるところで問題が起こる。

　なので、上記のselectDataメソッドの場合、返り値にVectorを返し、その要素の中のHashMapに値を入れているので、前の値も、そのハッシュマップにセットして置くようにするっていうのが、ウィリアムのいたずらがかかわった仕事ではおおいな。

（具体的にいうと、検索項目 heyaMeishoがroomNameに変わった場合、
Vector allData = selectData(komoku,tbls,whereKu,sortKu):
for(int i = 0 ; i <allData.size() i ++ ) HashMap mp = (HashMap)allData.elementAt(i);
mp.put("heyaMeisho",mp.get("roomName")); // 古い名称をセットしておく
　　allData.set(i,mp);
}

　みたいな感じで、新しい項目名の値をとってきて、前の項目名にもセットしてあげる）
　そうすれば、この返り値をもらった上位のメソッドでの変更はない。
　この名称変更はあまりないので、ここを自動生成させるメリットはあんまりないと思うけど）

---

　実際の開発では、どこまで自動化するかっていう問題がある。
　ここまできれいにやらない場合もあるし（ウィリアムのいたずらの場合、ここまでしないかな？？）
　逆に、テーブル構造が修正になったら、上記のselect内容を記述したExcelファイルを読み込み、修正があったら伝えるみたいな機能を付けることなど。。さまざまある。

って、ここまで書いて、結局結論としていいたいことは、

　だから、テーブル変更があったからって、修正が頻繁に入るっていうわけではないと思う。適切にプログラムを書いて、適切なパターン、ドキュメント規約が出来ていて、自動化するプログラムが出来てれば、ＲＤＢでも、修正箇所は、そんな目くじら立てていうほど、多くはないと思うぞ。

O/Rマッピングを否定している人をみつけっちゃたよ！

昨日のブログで、「うん、なんか、とんでもないことが書いてありそうな予感のページを発見したじょ！」の中身です。

　サイトをぐるぐるしていたら、O/Rマッピングを否定している人をみつけっちゃたよ！
　ここ(ただしＰＤＦ）にあるんだけど、この人の意見によると（この人の意見であって、ウィリアムのいたずらの意見ではない）

・O/Rマッピングは、本来不要で（シート６枚目）、
・O/Rマッピングで、本来不要なオブジェクトを追加しなくてはならず、
・その結果、コード量が増え
・テーブルスキーマ変更時の変更箇所が多い（シート７枚目）

なので、ＲＤＢを使わないで、開発するそうな（ここの会社のなんかをつかうらしい）

で、事例なんだけど、
・２０５クラス
・４１１５３行（自動生成２３４６４）行
での実績があがっている。

---

　Ｏ／Ｒマッピングがいけないから、ＲＤＢを廃止するっつーのは、すごい発想だ。
　自動車事故が多いから、自動車をなくすという考え方で。。。

　ある意味、場合によっては、ありなのかもしれない。
　この程度の中規模（小規模？）の開発だと。。。
　（シーケンシャルファイルでいいじゃん！っていう開発でも、ＲＤＢ使うこともあるしね。
　　掲示板とかみたいなので。。）


　ただ、言語が入り乱れちゃうような開発（ＶＣ＋＋とＪａｖａがあって、みたいなシステム）とかどうするの？っていう問題もあるんだけど、それより、
　大規模開発において、いがぴょんさんのブログで指摘されている、
オブジェクト指向やデザインパターンのなかの多くの技は「構造化」という観点からは リレーショナルデータベースにおける「逆正規化」に相当しているのだという点です
ほうが、気になります。

---

　大規模開発だと、他の人が、どこで、なにを開発しているのか、見えないことがあります（プロジェクトマネージャーまではわかっても、その先、だれが、どんなプログラムを作ってるか不明。中国に発注すると、お国柄、とくにそうだと思う。。独断と偏見）。

　そんななかで、オブジェクト指向をつかって、完璧に隠してしまうと、本来、関連しているはずのデータまで、隠れてしまうことがある。

　たとえば（極端な例だよ。こんな、お馬鹿なやつ、絶対いないと思うけど！）、

　・今月、商品の合計５０００円以上お買い上げの方は、プラチナ会員
　・商品の合計は、値段を足して合計を出した後、消費税をかける

　といった場合、この条件だと、会員（プラチナ会員）のオブジェクトと、商品合計を求める（買い物かなあ？）オブジェクトは、たぶん、別です。で、２つのオブジェクト間で、やり取りされるのは、合計値です。

　そのとき、消費税の規定が変わって、
　・商品の合計は、消費税をかけた内税値段を足して合計をだす

　という規定に変わった場合、商品合計を求めるオブジェクトを修正すると、問題なく動いてしまう。。。。

　それって、問題でしょ！

　プラチナ会員の条件は、「消費税を含まない」合計値が５０００円、含んじゃったときも５０００円でいいの？？
　じゃあ、５２５０円にすればいいじゃん！って？
　端数処理から考えると、そういうわけにもいかないですよね（５％割り戻すのも、同じ話）
　というわけで、問題があるんだけど、データが隠れてしまい、加工されたデータでやり取りすると、まったく、わかんなくなっちゃうことがあるのよ。

---

　ただし、こーんなにわかりやすい、おばかなはなしは、もちろんないよ！

　だけど、データが隠れてしまうと、これに似たような、もっと複雑な話で、加工されたデータだけ、受け取った場合の問題っていうのが、生じるのよ。

　ＲＤＢの場合、正規化するので、このような計算で求めるような項目は、本来、第三正規形だったかな？で入れてはいけないことになっているし、第三正規形までしなかったとしても、データを求めるのに必要な値は、（データベースの共用性の規定により）基本的にＤＢにいれて、公開するのがふつう。

　つまり、ＲＤＢの場合、永続的データの全体像が、テーブル上に表現されていることが多い。
　それによって、情報共有が図られ、なので、大規模でも、矛盾が発見しやすいというメリットがあるわけなのですよ。
　だから、正規化って、重要なんだけど、オブジェクト指向の場合、正規化しなくても（情報を抱え込んで、隠しちゃっても）ＯＫっていうことなんで、その辺、どーなのどーなの？？
　やっぱ、ＲＤＢも、大規模になると、大切じゃないの？？

　なんて、思ってしまいます。

---

　ただ、さらに、もっと気になった論点。
・テーブルスキーマ変更時の変更箇所が多い（シート７枚目）

かあ？？これ、たしかに、ＳＱＬ文を、ばかみたいに、書いていたら、修正、多いよ。
　でも、いまって、ハッシュマップをつかって、ＱＢＥグリッドみたいな感覚で指定するから、どれほど、修正、いらないんじゃないかなあ。。。
　あれ、その方法って、一般的でない？？ひょっとして？？意識あわせが必要（お、大規模っぽくなってきました！）

　じゃ、こんど、気が向いたときに、みなさんと、意識あわせしましょう！