矢崎です。かなり亀レスです。ごめんなさい（＾＾；；；
Kaoru Hosokawaさん wrote:
>
> > ”車の運転を学ぶこと(Lerning to Drive）”、４つのValue、両手いっぱ
> > いのPrincipleを学んできたので、もう、ソフトウエア開発のDiscipline
> > の開発をスタートさせるための準備はできている。まずはスコープを
> > 決めるところから始めよう。システム開発には、４つの基本的な
> > Activityがある。それはCoding、Testing、Listening、Designingである。
> >
>
> 「value」は、「価値観」と訳した方がいいと思います。プログラマーのせいか
> 「value」と書いてあると「値」と読んでしまいます。第七章で話が出ますが、XPの
> ４つの価値観は、「Communication, Simplicity, Feedback and Courage」ですね。
>
そうですね。意味的には「価値観」でOKだと思います。ただ私としては、
基本的な用語（名詞）については、原著そのままにしておきたいという気
持ちがあります。絶対的にそれにこだわるわけではありませんが。。。
というわけで、しばらくはValueとさせてください。もし、このMLで「価値観」
という言葉が市民権を得たら、そちらに変えたいと思います。
>
> まったくその通りだと思います。しかし、単体テストの枠組みを作るのはおっくうで
> はないでしょうか？「クラスの単体テストを行うために、このクラスを使用するクラ
> スを書いてからテストしよう。」 とどんどん先送りしていませんか？
>
JUnitはダウンロードしたのですが、まだ本格的には使っていません。
確かにJUnitを使っても、実際のテストのロジックはコーディングしな
ければならないので、簡単にテストができるようになるというイメージ
は、まだ私にはありません。
テストをできるだけ複雑にしないために、「Simlicity」（つまり、その
時点で必要な機能だけを開発する、ことで、都度のテストケースの数
を減らす）ということなのかもしれませんが、果たして、そううまくいくの
かどうか、、、これは実際にやってみないとわからないですね。
>
> ここでは、「局所的なコードの書き直しだけではなく、全体的に構造が変だったらな
> おしましょう。」といってますよね？安定したシステムだったらいいですけど、なか
> なか開発途中で全体の設計を変更するには勇気がいりますよね。
>
その勇気と、それができるようになるためのPracticeが必要なのでしょうね。
Practiceとしては、Refactoringがその代表なのでしょうが、これも実際にやってみ
ないと、なんとも評価ができません。
>
>
> ちょっと気になるのは、XPでは、「Documenting」が基本の一つになっていないこと
> です。私の言っている「Documenting」は、ソースコードの文書化と製品の文書化で
> す。ソースコードの文書化とは、コメントを書く、機能仕様書を書くと言う事です。
> 製品の文書化は、ヘルプとかユーザーズガイドを書くことです。XPでは、これらをい
> つ行うのでしょうか？必要無いのでしょうか？スコープ外にして楽な問題を解いてい
> るのでしょうか（ちょっといじわるな質問）？
>
私の現時点での考えを述べます。
まずプログラミングそのものには直接関係しない、ユーザーズガイドは、
まったくの対象外でしょうね。当然プロジェクトの最終製品の１つには
ちがいないのですが、XPではその部分はまったくかやの外でしょう。
プログラミングに関する「Document」については、あくまでも私の想像で
すが、XPではコードのみが最終のDocumentであると考えているので
はないでしょうか？コード以外のDocumentは、補足的に作成されるこ
とはあっても、必須ではないし、あるいは不要になったら捨ててもよいと
考えられていると思います。
例えば、XPなFowler氏は、この前行われた日本講演（お題はUMLと
アナリシス・パターンです）で、次のようなことを言っていました。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
（講演の話やファウラー氏の著作によれば、全てをインタラクション図
で表現するとは考えないということですが、表現しない部分はどうする
のですか？という会場からの質問に対して）プログラムコードで表して
十分なところは、インタラクション図を描く必要はない。そのまま（プロ
グラムコード）でよい。インタラクション図は有効な方法だが、やたらと
使いまくることはしないほうがよい。たくさんドキュメントを書けばいいと
いうものではない。大切なことはコミュニケーションであり、そのために
必要なものだけを作成すればよい。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
また、彼の著書「UMLモデリングのエッセンス」の日本語訳では、
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(134ページ）
「これらの図（矢崎注：シーケンス図やコラボレーション図のこと）は芸術
作品である必要はありません。私はよく紙切れや小さなホワイトボードに
大まかに描いてしまいます。クラスの振る舞いを明確にするのに役立つの
で、その図を最新の状態に保つ価値がある、と思うときだけ、ドローツール
（やCASEツール）を使って図を書き直します。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
とか、
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(143ページ）
「実際には私は、相互作用のだいたいの形を作るため、ふつうはシーケンス
図を使い、コードを書きながら変更を加えます。相互作用が重要な場合は、
文書の一部としてシーケンス図を更新します。シーケンス図があってもコード
がさらに明確にならないと思うときは、ファイルキャビネットにそのラフなシー
ケンス図をファイルしてしまい込んでしまいます。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
とか、書いています。
また、Fowler著「Refactoring」では、コメントが必要なのは、そのメソッドが長す
ぎるからで、コメントがいらないようにメソッドを小さくしろ、というような指針が
書かれてあったような記憶があります。
実は、私は、今この考えにはまっているのですね。。（＾＾）
--
矢崎博英 firo@....jp