ホソカワです。
on 2000/03/22 6:06 PM, firo at firo@....jp wrote:
> 矢崎です。かなり亀レスです。ごめんなさい（＾＾；；；
>
> 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」（つまり、その
> 時点で必要な機能だけを開発する、ことで、都度のテストケースの数
> を減らす）ということなのかもしれませんが、果たして、そううまくいくの
> かどうか、、、これは実際にやってみないとわからないですね。
>
実際にやってみたいですね。ML上でできますかね？
>>
>> ここでは、「局所的なコードの書き直しだけではなく、全体的に構造が変だったらな
>> おしましょう。」といってますよね？安定したシステムだったらいいですけど、なか
>> なか開発途中で全体の設計を変更するには勇気がいりますよね。
>>
>
> その勇気と、それができるようになるためのPracticeが必要なのでしょうね。
> Practiceとしては、Refactoringがその代表なのでしょうが、これも実際にやってみ
> ないと、なんとも評価ができません。
>
>>
>>
>> ちょっと気になるのは、XPでは、「Documenting」が基本の一つになっていないこと
>> です。私の言っている「Documenting」は、ソースコードの文書化と製品の文書化で
>> す。ソースコードの文書化とは、コメントを書く、機能仕様書を書くと言う事です。
>> 製品の文書化は、ヘルプとかユーザーズガイドを書くことです。XPでは、これらをい
>> つ行うのでしょうか？必要無いのでしょうか？スコープ外にして楽な問題を解いてい
>> るのでしょうか（ちょっといじわるな質問）？
>>
>
> 私の現時点での考えを述べます。
>
> まずプログラミングそのものには直接関係しない、ユーザーズガイドは、
> まったくの対象外でしょうね。当然プロジェクトの最終製品の１つには
> ちがいないのですが、XPではその部分はまったくかやの外でしょう。
>
ここは残念に思っています。ただ、どこかで読んだ記憶がありますが、（XP本かな？）
Beckが本を書く時もpair writingではないがだれでも変と思ったくだりは自由に直し
ていいなどXPのpracticeを取り入れたとか。うる覚えですみません。夢かも？（ちな
みにJUnitにユーザーズガイドはありますか？）
このMLでextreme writingの手法を開発してみてもおもしろいですね。
> プログラミングに関する「Document」については、あくまでも私の想像で
> すが、XPではコードのみが最終のDocumentであると考えているので
> はないでしょうか？コード以外のDocumentは、補足的に作成されるこ
> とはあっても、必須ではないし、あるいは不要になったら捨ててもよいと
> 考えられていると思います?
>
> 例えば、XPなFowler氏は、この前行われた日本講演（お題はUMLと
> アナリシス・パターンです）で、次のようなことを言っていました。
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> （講演の話やファウラー氏の著作によれば、全てをインタラクション図
> で表現するとは考えないということですが、表現しない部分はどうする
> のですか？という会場からの質問に対して）プログラムコードで表して
> 十分なところは、インタラクション図を描く必要はない。そのまま（プロ
> グラムコード）でよい。インタラクション図は有効な方法だが、やたらと
> 使いまくることはしないほうがよい。たくさんドキュメントを書けばいいと
> いうものではない。大切なことはコミュニケーションであり、そのために
> 必要なものだけを作成すればよい。
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> また、彼の著書「UMLモデリングのエッセンス」の日本語訳では、
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (134ページ）
> 「これらの図（矢崎注：シーケンス図やコラボレーション図のこと）は芸術
> 作品である必要はありません。私はよく紙切れや小さなホワイトボードに
> 大まかに描いてしまいます。クラスの振る舞いを明確にするのに役立つの
> で、その図を最新の状態に保つ価値がある、と思うときだけ、ドローツール
> （やCASEツール）を使って図を書き直します。
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> とか、
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (143ページ）
> 「実際には私は、相互作用のだいたいの形を作るため、ふつうはシーケンス
> 図を使い、コードを書きながら変更を加えます。相互作用が重要な場合は、
> 文書の一部としてシーケンス図を更新します。シーケンス図があってもコード
> がさらに明確にならないと思うときは、ファイルキャビネットにそのラフなシー
> ケンス図をファイルしてしまい込んでしまいます。
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> とか、書いています。
>
> また、Fowler著「Refactoring」では、コメントが必要なのは、そのメソッドが長す
> ぎるからで、コメントがいらないようにメソッドを小さくしろ、というような指針が
> 書かれてあったような記憶があります。
>
> 実は、私は、今この考えにはまっているのですね。。（＾＾）
>
私もコメントは書かない方なので良くわかります。
XPでは、新人には必ず以前からいたチームメイトがつくように配慮されているのでコー
ドのわからない部分はその人に聞くのでしょうね。このようにドキュメントがなくて
もコードは受け継がれていくのですね。
逆にKnuthのLiterate Programmingのようにコードより説明文が多いコーディングス
タイルもありますよね。このスタイルでしたら一人でじっくり本を読む感じで、コー
ドを理解することができるのでしょうね。
--
Kaoru Hosokawa
khosokawa@....com