小野です。
>> Regarding [XP-jp:01662] Re: XP で再利用できますか？; YAMADA Masaki <masaki@....jp> adds:
> 山田＠メタボリックスです。
..
> 「同期をとる」と言ったのは、クラスとRDBのスキーマとの
> 同期の意味でした。
> リファクタリングなどをしてクラスの構造が変わるたびに
> スキーマを切り直さなければならないとしたら、
> 「下流での再作業のコストがそんなに高くない」というXPの前提を
> 満たさないだろうと思ったのです。
データベースを用いたプロジェクトと、XP の変更カーブに関して、昔か
らちょっと思っていたことがありました。
データベースの場合、最初にスキーマを下手に切るとデータが「腐る」
ので、再作業のコストは指数的に増えてしまうのではないか、というこ
とです。このスキーマ設計だけは、「前払い設計」を認めざるを得ない
のでは、と考えています。
---------------
XP では、なるたけ短い期間でまずは稼働にこぎ着けることを重視します。
稼働した後でも開発のイテレーションは継続して、いろいろと発展させ
ていくわけです。その際に変更のコストカーブを小さくさせる手段を講
じるわけです。
一方、一旦稼働したということは、最初のイテレーションで設計したス
キーマに基づいたデータが、DB にどんどんたまっていくことを示してい
ます。
スキーマ変更が起きて、最初は気づかなかった属性の変更なり追加なり
を行うと、その変更を行ったイテレーションまでに蓄積された過去のデー
タが、使えなくなることになります。
変更の種類によっては、対応できることもあります。
健康管理を目的としたデータベースで、各利用者の属性として「体重」
「身長」を取るようなスキーマを切っていた時に、あとから「BMI(Body
Mass Index)」を加えることは簡単でしょう(BMI は体重／身長から計算
できる)
しかしあとから「体脂肪率」を属性として追加すると、過去に遡って体
脂肪率をはかり直すわけにもいきませんから、その変更をした以前のデー
タと以後のデータとの間に不連続性ができます。この不連続性に対応す
るためには、ソフトウェアの変更も含めて、かなりのコストがかかるこ
とが期待されます。
私は、クラス構造の変更と RDB の同期をとることは、「何らかのメカニ
ズム」で可能だと思うので、これがリファクタリングの本質的な障害に
はならないだろうと楽観的に考えています。しかし DB のスキーマだけ
は、実運用に回すまでにカッチリと固定するくらいの気持で「前払い」
設計をしなくてはいけないので、リファクタリングできない == XP は
適用出来ないのではと予想していますが、でもなんかいい方法ないかな〜
とも考えています。
// Tsuyoshi ONO //
e-Communications Div, CSNC / SONY Corporation
email: ono@....jp
"In computer programming we say that a project will always run
out of time but never run out of excuses."
-- Eliyahu M. Goldratt, 'Critical Chain' p26