Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

アジャイルとか言う前に、サブシステムへの分割について、もっと議論しないといけないんじゃないのかなぁ。

カテゴリ:システム考
更新日:2013-01-26
> データモデル自体はアジャイルなのだが... - 極北データモデリング

私のようなデータベース中心主義者から見れば、データモデルは非常に俊敏なシステムの構成要素であって、それを参照するアプリケーションこそがアジャイルではない、ということになる。

「データモデル」と「アプリケーション」という用語が示している範囲が、いまいちよく分からん。単純に「データベース」と「プログラム」というふうに読み替えても意味が通じてしまうみたいなんだけど、それは意図にあってるのかしらん?

ようするに、「データモデル≠データベース」だよね?ってこと。

オブジェクト指向だとクラス図などで表現されるけど、あれだって「データモデル」だ。オブジェクト指向とRDBで、それぞれデータモデルがあるから、インピーダンスミスマッチという問題が出てくる。「データモデルの変更」って、それをひっくるめて、ということじゃないのかな?「データモデルの変更」は、データベースの変更だけじゃなくて、プログラムの修正が伴う。結果、データモデルの変更はコストが高い、ということじゃないのかな?

私がスキーマレスでDBを使うようになったのは、まさに「プログラムとデータベースの変更コスト」を減らすため(主に、開発環境と本番環境の同一性の保持が理由)だった。だけど、スキーマレスだからといって「データモデル」を変えれば、やっぱりプログラムは変えなきゃいけなくて、どうあっても修正コストが減らないというのはよく分かる。実際、プログラムの修正範囲を考えて、データベースの設計を変えるかどうか決めることはよくある。そのプログラムの変更だけで済むのであれば、そのほうが明らかに安いからだ。(実行速度など、他の要因が問題にならなければ、だけれども)

> データモデル自体はアジャイルなのだが... - 極北データモデリング

代わりに
・データモデル変更の影響範囲を極力狭めるようアプリケーションをレイヤリングする
ことが重要(というか、不十分なんだけどそれぐらいしか打ち手がない)、と考える。

いろいろ考えていくと、これしかないとは私も思う。だけど、レイヤリングじゃないんだよなぁ・・・


> データモデリングなきアジャイル開発は危ういか? - An Agile Way(ITmedia オルタナティブ・ブログ)

そんなわけで、高リスク制約と思われているものでも、最近は後で変更が可能となってきたものが多い。それに、工夫すれば後で変更するオプションをできるだけ維持しながら開発できる。こう考えることで、できるだけ、ユーザに見える動くソフトウェアを、すばやく提供すること、すなわち、ケーキを縦に作ることが可能になってきた。

レイヤリングというと、ケーキを横に切る、という事じゃないかと思う。だけど、データモデル変更の影響範囲を狭めるというのは、ケーキを縦に切る、ということなんじゃないだろうか?

そして、ケーキを縦に切る、ってのは、今までだって考えられていた。サブシステムに分割するのがそれだ。

私が考える理想的なサブシステムの単位というのは、サブシステム単位でごっそりと捨てて、作り直せる、ってことかな。

例えば、印刷システム。

そりゃ、帳票の数が膨大だと、いっぺんに全部変えるってのは大変だけどさ。でも、仕組み的には切り替えやすいよね。それは、参照しかしないからだ。データを持ってきて、決まったフォーマットに印刷するだけ。

フィードバックがないってのは、独立させやすいってことだ。逆にフィードバックがある部分をサブシステムに分けると大変そうだ。つまり、フィードバックが最小限になるように、細く細く切り分けることができれば、データモデル変更の影響反映も小さくなるってことだ。まぁ、実際には、なかなか難しいだろうけど・・・


> 優れた仕様を決定するために必要なこと - GoTheDistance

「ソフトウエアの設計=仕様の設計+コードの設計」になりますが、現実問題としてこの2つを同時にできるSI案件って少ないのではという気がします。

私は、大規模システムってのには、プライムはもとより、孫請け、ひ孫請けなんてレベルでも関わったことがないから、実情がどうなっているかは想像でしか無い。だけど、問題がありながらも、それでもなんとか作ってこれてるのは、サブシステムの分割がそれなりにできているからだと思う。デカいシステムをデカいまま作るなんて無理だよね?そんなの人間業じゃない。

だから、このレベルの設計ってのは、実は、結構やってるんじゃないかなと思う。みんな、オレオレライブラリとか、オレオレフレームワークとか、持ってるよねぇ?それって、小規模でも、このレベルの設計をやってきたから、あるんじゃないのかな。

あまりやる機会がない設計ってのは、実は「サブシステムへの分割」だと思う。

大規模システムに対して小規模だと、なんで開発しやすいのか?それは、小規模なシステムにかせられた「現実」という制約条件のためだと思う。現実というものがはっきりと見えているからこそ、作りやすい。小規模なシステムってのは、現実によってサブシステム分割がされている、って考えてもいいんじゃないかな。

てことは、大規模システムだって、同じように現実基準でサブシステムへ分割すればいいんだよね。ところが、いろんな理由で、それができていない。できていないってのは、サブシステムのインタフェースが現実ほど強固じゃないってことね。強固じゃないから変更される。ようするに仕様変更。で、その変更が、そのサブシステムだけの変更で収まればいいけど、そうならないと波及する。で、しっちゃかめっちゃか。

大規模開発ってのは、上流でしっかりと分割してくれないと混乱する。ほんとに最上流でやることだから機会もない。機会がないから、考えることもない。経験がたまらないから、何時まで経っても上手くならない。

プログラムは、隠蔽化とか、オブジェクト指向とか言ってるのに、プロジェクトは、まったく隠蔽化も、オブジェクト指向もできてないんだものなぁ。ちゃんと分割できてれば、そのサブシステムのプロジェクトでアジャイルだってやれるだろう。

サブシステムへの分割技術ってのは、本当は、もっと議論されないといけないんじゃないのかなぁ。

> サブシステムの「なに?」「なぜ?」「どうやって?」(前編) - @IT:The Rational Edge (22)
> サブシステムの「なに?」「なぜ?」「どうやって?」(後編) サブシステムとはモデリング概念である - @IT:The Rational Edge (22)
スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

フリーのシステムエンジニア兼プログラマです。趣味はガーデニングとカメラ。2017年4月にα7IIを買いました。フルサイズ一眼初心者です。

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。