ご説明ありがとうございます。
参考になります。
> そして、考えているモデルは、UML ではなくソースとして目の前のコードに反
> 映されます。自分のモデルと異なれば、そこで指摘ができます。そうやって、互
> いの頭の中のモデルを修正しながらよりよい設計を目指す…、と捉えてみてはど
> うでしょうか？
結構、あてはまるかもしれないです。
> ソースのコメントも似たようなものですが、「それを他人が読んで理解できる
> か」という観点で考えてみると、なぜドキュメントとソースで同期を取る必要が
> あるのか分かると思います。
他人が理解する。。。のに、UMLの設計書と、ソースだけでは、たとえ両者が完
全に
一致していても、理解は難しいのではないかと、私は思います。
自分が思い出すときは、ソースだけでは、理解が難しいですが、UMLの設計書は
かなり
役にたちます（現に立ちました。）
結局、
”自分が思い出す != 他人が理解する ”
であり、他人が理解するには、 最終成果物である、UMLモデルとソースコード
以外に、
開発者の経験を記したもの（なぜ、それが必要？なぜ、それを作った？。どんな
経緯で？。なにを調べて？）が、
必要であると思います。
XPでも、新しいメンバーが加入した場合、説明するだけで、かなりの時間がかか
る、と説明されています。
（ただし、XPでは、プロジェクトを引き継ぐということはせず、プロジェクトを
保守することに優位性を示している為、
メンバーの入れ替えは、考えていないようですが。。。）
これが、開発者の頭にまさるものはない、といわれることだと思うのですが、
これが、ソフトウェア開発のもつ、問題点
ではないかと考えています（って、いやですよね。質問すると、さも自分しか
そのことをわかっていないように、
得意げに、ぺらぺらと言われて、ものすごい自分が劣等感をかんじるのっ
て。。。）。
この頭の中にあるもの、を如何にして、取り出すか？
今の自分の中の解答としては、
”日記をつける”
というのがあります。
”日記”というのは、DR議事録もあり、調査したネットのHPの記録あり、S／W
ライブラリのヘルプの参照箇所あり、、、
と、とりあえず、その日、一日おこなったことを、細かに記録することです。
しかも、なぜ、それを調べて、
何をして、結果として、何が得られて、そして、この機能が実現して。。。と
いった物語風な感じに。。。
ってなことを思ったりしたのですが、どうなんでしょうか？
> ペアプログラミングに絞った本も出版されていることですし、簡単に諦めず、
> 手を変え品を変え頑張って会社で布教してみましょう (^^)
QC活動ででも、一回やってみようかな・・・・
----- Original Message -----
From: "Akira SASAKI" <fabi@....jp>
To: <extremeprogramming-jp@....jp>
Sent: Saturday, June 28, 2003 5:56 PM
Subject: [XP-jp:04503] Re: はじめまして
> どうも、佐々木と申します。
>
> 最初に。
>
> 設計、製造、テスト、再設計、製造、テスト…
>
> というサイクルは、RUP に近いイメージを持ちました。巷では XP を含めたアジャ
> イルプロセスが人気ですが、RUP も覚えておいて損はないと思うので、もしご存
> じでなければ調べてみる価値はあると思いますよ。
>
>
> On Sat, 28 Jun 2003 11:21:40 +0900
> "Hideo Konishi" <shilkhat26@....jp> wrote:
>
> > とありますが、開発工程に、プラクティスの１つである、”テスティン
グ”だ
> > けを取り入れることは、危険なのでしょうか？
>
> 私は、とりあえず単体テスト工程に、テストファーストを取り入れています。
> もっと言えば、テストファーストでなくとも、単体テストの際には必ず JUnit
> を使っています。
>
> テスティングに限らず、XP のプラクティスの一部を切り出して導入する、と
> いうのは、多くの人々が実践していることと思います。
> XP の導入事例でも、よく見られますよ。
>
>
> > 2. 、『XPエクストリーム・プログラミング懐疑編』 では、
> >
> > ”使った後で、手を洗うのであれば、UMLダイアグラムを使ってもOK”
とい
> > う人もいると
> >
> > 書かれていますが、設計で、UMLをもちいて、クラス分析をおこなうこと
は、必
> > 須であるとしか思えません。
>
> ここで言っている「使ってもOK」というのは、プログラマの中には UML で
> （明示的に）モデリングせずに作る人もいる、という認識で良いと思います。
>
> ですので、モデリングツールで UML を作成しても良いし、ホワイトボードに
> 書いてもいいし、メモ用紙の隅っこに書いてもいいし、頭の中（！）でモデリン
> グしてもいい、ということだと思っています。
>
> 重要なことは、UML を使うかどうかではなく、ペアであーだこーだ言いながら
> 分析・設計すること、そして必要とあらばリファクタリングを行う、ということ
> だと思います。
> ペアで議論するときに UML を使った方が良いのであれば使うし、会話だけで
> 済むのであればモデリングしない、という風にとらえています。
>
>
> 将棋のプロ棋士は、盤と駒がなくても頭の中で将棋が指せます。これは、お互
> いに頭の中で駒を配置した将棋盤があるからできるのだそうです。
>
> もし、お互い頭の中でモデリングしているという前提に立てば、UML で図を画
> 面上や紙に明示するということは、頭の中に描かれているモデルを明示するとい
> うことですよね。そして、お互い同じモデルが頭の中にあれば、いちいち画面上
> や紙に表すことはないと思いませんか？
> そして、考えているモデルは、UML ではなくソースとして目の前のコードに反
> 映されます。自分のモデルと異なれば、そこで指摘ができます。そうやって、互
> いの頭の中のモデルを修正しながらよりよい設計を目指す…、と捉えてみてはど
> うでしょうか？
>
>
> > 3. ソースコードの変更が設計書に反映されないため、設計者は、意味がないも
のに
> > なる、といわれていますが、
> >
> > 設計書 ・・・・生成物に意味があるのではなく、考えをまとめる際
に、
> > 役に立つ。あいまいでもいい。
> > ソースコード ・・・・実際に動かすために、厳密に書く必要がある。
> >
> > となり、設計書と、ソースコードは、意味がことなるため、最終的に、完全
に一
> > 致する必要はないとおもうのですが。
>
> 設計書の位置づけがどういうものか、によると思いますね。
>
> もし、その設計書が使い捨てで、今後も参照されないのであれば、おっしゃる
> とおり一致する必要はないでしょう。
> ですが、多くの場合設計書は引き継ぎ資料として後世ずっと大事にされ、こと
> あるごとに参照されて不幸（！）のタネになります。
>
> 今稼働しているソースが現状の仕様を反映しているんだけど、設計書は違う、
> どうしてこの差異が生まれたのか？ ということに頭を悩ませるわけです。
>
> ソースのコメントも似たようなものですが、「それを他人が読んで理解できる
> か」という観点で考えてみると、なぜドキュメントとソースで同期を取る必要が
> あるのか分かると思います。
>
>
> > 4. ペアプログラミング は、やってみたいのですが、会社では、できそうにあ
りま
> > せん。
> > だれか、ネット上で、共有ファイルを使って、一緒に、ペアプログラミング
やり
> > ませんか？
>
> 私もペアプロの経験はありませんが、おそらく最初はネット越しよりも実際に
> 近くにいるメンバーと行ったほうが良いような気がしています。
> ペアプログラミングに絞った本も出版されていることですし、簡単に諦めず、
> 手を変え品を変え頑張って会社で布教してみましょう (^^)
>
>
> それでは。
>
>
> --
> Akira SASAKI <fabi@....jp>
>