どうも、佐々木と申します。
最初に。
設計、製造、テスト、再設計、製造、テスト…
というサイクルは、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>