ホソカワです。
解説、ありがとうございます。私のコメントです。
on 2000/03/15 2:39 PM, firo at firo@....jp wrote:
> 矢崎です。Section1のChapter９についての解説です。
>
> 間違い等ありましたら、ML上でどんどんご指摘いただければ幸いです。
>
> [矢崎のコメント]
> このChapterでは、システム開発の基本的なActivityとして、Coding、
> Testing、Listening、Designingの４つをあげ、XP的な観点から、各
> Activityを簡単に説明しています。
>
> ここで基本的なという意味は、このChapterの最初に書いてある以下
> の文からすると、これらのActivityを除くともはやシステム開発が成り
> 立たなくなる、絶対に行わなければならないもの、そのような意味で
> しょうか？
>
> p.43より引用
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 安定して予測可能なシステム開発を行うためには、行わなければな
> らない全てのことを行いたいと思う。しかし、余分なことをする時間はな
> い。開発の４つの基本的Activity（basic activities）は、coding、testing、
> listening、designingである。
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ”車の運転を学ぶこと(Lerning to Drive）”、４つのValue、両手いっぱ
> いのPrincipleを学んできたので、もう、ソフトウエア開発のDiscipline
> の開発をスタートさせるための準備はできている。まずはスコープを
> 決めるところから始めよう。システム開発には、４つの基本的な
> Activityがある。それはCoding、Testing、Listening、Designingである。
>
「value」は、「価値観」と訳した方がいいと思います。プログラマーのせいか
「value」と書いてあると「値」と読んでしまいます。第七章で話が出ますが、XPの
４つの価値観は、「Communication, Simplicity, Feedback and Courage」ですね。
>
> [Coding]
> それを行わなければ、もはや何事も行われなかったといわざるを得な
> いという意味で、コーディングは基本的なActivityの１つである。あなた
> が、コードを生成するダイアグラムを描いていようが、ブラウザを使って
> タイプしていようが、いずれにしろ、あなたはコーディングしているのだ。
>
> コードから次のことを得ることができる。
> １）学習
> 学習する方法は、考えることである。そして、それがよい考えである
> かどうかを見極めるために、テストすることである。コードはそれを行
> うために、ベストな方法である。コードはそれが書いてあるとおりにし
> か動かないので、レトリックや、学歴や、給料の多さには影響を受け
> ない。コードが思ったように動かない場合は、それはコードのせいで
> はなく、書いたあなたの問題である。
>
> ２）明確かつ簡潔なコミュニケーション
> コードはまた、明確かつ簡潔なコミュニケーション手段になり得る。も
> し、あなたがアイディアを持っていて、それを私に説明した場合、私は
> それを聞いて、簡単に誤解してしまうかもしれない。しかし、私たちが
> いっしょになって、そのアイディアをコード化したら、そのロジックの
> 中に、あなたのアイディアの正確な形を見ることができる。相手のコー
> ドを見て、アイディアがわけばそれをまたコードで表す。これを繰り返す
> ことで学習が促進される。
>
> 我々はソースコードを持たなければならないので、それをできる限り、ソ
> フトウエアエンジニアリングの多くの目的のために、使うべきである。コー
> ドは、戦術的な目的を表現する、アルゴリズムを記述する、将来の拡張お
> よび縮小が可能な個所を示すといった、コミュニケーションの手段に使うこ
> とができる。また、ソースコードはテストを表現することにも使用できる。そ
> のテストでは、システムの操作を客観的にテストしたり、全てのレベルにお
> けるシステムの有益な操作上の仕様を提供する。
>
毎日自分で書いている、見ているソースコードであれば、何が書かれているのか大体
わかるが、何年か経ったら、わからなくなるのではないでしょうか？コメントなど充
実しているのでしょうか？
>
> [Testing]
> 私は、私が書いた全てのものについて、それをテストするまでは信用しな
> い。テストは、私がほしいものに関して、そのインプリメントを無視して考え
> ることを可能にする。そして、私がインプリメントしたと考えたものを本当に
> インプリメントしたかどうかを教えてくれる。
>
> 自動化テストは、機能のテストに限定されない。パフォーマンスのテストな
> ど、機能以外の部分についての自動化テストを書くこともできる。
>
> テストはあなたが、いつプログラムを完了したかを教えてくれる。テストが
> 全て終わったら、プログラムを完了したことになる。逆にいえばテストが全
> て終わらなければ、あなたはプログラムを完了したことにはならない。
>
> ほとんどのソフトエアは、自動化テストを使って開発されていない。ならば、
> Testingが基本的なActivityであるということについて、本当にそう言えるの
> か疑問が生ずる。Testingが基本的なActivityであると言えるのは、以下の
> ２つの理由からである。１つは短期的な観点のもので、もう１つは長期的観
> 点のものである。
>
> １）長期的な観点
> 長期的観点からの答えは、テストはプログラムの寿命を長く保つという
> ことである（テストが実行され、また保守されていけばという前提つき
> で）。
> 長い間にわたり、システムの信頼度は高まりつづける。
>
> ２）短期的な観点
> テストを持っていてプログラミングすることは、テストを持たない場合に比
>
> べてより楽しいものである。それは、より自信を持って、コーディングする
>
> ことができるようになるからである。ある機能を追加し、テストをし、結果
>
> が正しければ、その都度自信も新たにして、次に進んでいくことができる。
>
> プログラミングとテストをいっしょに行うほうが、プログラミングだけを行うよ
>
> りも開発スピードは速くなる。一度、テストを習慣にしてしまえば、生産性に
> 関する違いにすぐに気づくだろう。生産性の向上は、デバッグに費やされる
> 時間の減少からもたらされる。バグを発見する時間が非常に短縮される。
>
> テストには危険もある。正しくないテストは、悪しき楽観主義を生む。テスト
> は全てうまく行くっているのだから、それでシステムがOKであると誤解して
> しまうからだ。
>
> テストには、Unit TestとFunctional Testの２種類がある。Unit Testは、プロ
> グラマが、自分が作ったプログラムが思ったとおりに動くことを、自分自信で
> 確信するために行う。Functional Testは、顧客が、システム全体が期待どお
> りに動くことを確信するために、顧客自身が書く（あるいは少なくとも仕様を
> 書く）ものである。
>
まったくその通りだと思います。しかし、単体テストの枠組みを作るのはおっくうで
はないでしょうか？「クラスの単体テストを行うために、このクラスを使用するクラ
スを書いてからテストしよう。」 とどんどん先送りしていませんか？
>
> [Listening]
> プログラマはビジネス・ピープルが関心を持っていることを何も知らない。
>
> そのことを考えると、プログラマとしてのあなたは、ビジネス・ピープルから聞
>
> くということが重要になる。Listeningは、ソフトウエア開発の基本的な
> Activity
> の１つである。
>
> Listeningは単に聞くという受動的な面だけでなく、能動的な面も持たなけれ
> ばならない。プログラマが顧客へフィードバックすることがそれである。このフ
>
> ィードバックは、顧客がビジネス上の問題をより理解できるのに役に立つ。
>
> 「お互いによく話を聞くべきだ。また顧客の話をよく聞くべきだ。」と言うだけ
> で
> は、あまり役にたたない。我々は、必要な事物が、必要な時に、必要な詳細さ
> で伝えあうことができるように、コミュニケーションを組み立てなければならな
>
> い。同時に、それは、役に立たないコミュニケーション、内容が本当に理解さ
> れる前のコミュニケーション、重要な部分がわかりにくくなるほどの詳細すぎ
> るコミュニケーションが、促進されないようになっていなければならない。
>
これもそのとおりですね。製品開発を行う中で、business people（営業部門？）と
話し合う割り合いは少ないかもしれませんね。もっと密にコミュニケーションを取り
たいですね。
>
> [Designing]
> 聞いて、テストを書き、テストを実行する、の繰り返しでは、うまくいかない。
> 始
> めはうまくいっていても、いずれは行き詰まる。次のテストを完了するには、そ
>
> れまでのどこかを壊さなければならなくなる。テストが価値をもたらす以上に、
>
> トラブルをまねいてしまうようになる。
>
> これを避ける唯一の方法がDesigningである。Designingは、システムの中のロ
> ジックをオーガナイズする構造を作ることである。よい設計は、以下の特徴を
> 持つ。
>
> １）システムの１つの部分の変更が、常に他の部分の変更を要求する、そう
> いうことがない。
>
> ２）システムのロジックのどの断片も、たった一ヵ所に記述されている。
>
> ３）ロジックを、それが扱っているデータの近くに置く。
>
> ４）システムの拡張を、たった１ヵ所の変更だけで可能にする。
>
> 悪い設計は、ちょうどこれらの反対である。以下のようなものである。
>
> １）１つの概念的な変更が、システムの多くの部分の変更を要求する。
>
> ２）ロジックが重複せざるを得ないような設計である。
>
> ３）ある変更に対する影響がどこに波及するのかが明確でない。
>
> ４）現在の機能を壊すことなく、新しい機能を追加することができない。
>
> また、複雑さは、悪い設計のもう１つの源である。説明のつかない複雑さがあ
> れば、それは悪い設計である。
>
> XPのDesigningは、他のソフトウエアプロセスのDesigningとは、大きくちがって
>
> いる。Designingは、コーディングの最中にあるXPプログラマにとっては、毎日
> の業務の一部である。また、Designingは、オプションではない。ソフトウエア
> 開
> 発が効果的になるために、設計はまじめに考えられなければならない。
>
ここでは、「局所的なコードの書き直しだけではなく、全体的に構造が変だったらな
おしましょう。」といってますよね？安定したシステムだったらいいですけど、なか
なか開発途中で全体の設計を変更するには勇気がいりますよね。
>
> --
> 矢崎博英 firo@....jp
>
>
ちょっと気になるのは、XPでは、「Documenting」が基本の一つになっていないこと
です。私の言っている「Documenting」は、ソースコードの文書化と製品の文書化で
す。ソースコードの文書化とは、コメントを書く、機能仕様書を書くと言う事です。
製品の文書化は、ヘルプとかユーザーズガイドを書くことです。XPでは、これらをい
つ行うのでしょうか？必要無いのでしょうか？スコープ外にして楽な問題を解いてい
るのでしょうか（ちょっといじわるな質問）？
「Extreme Documenting」はないのかな？
--
Kaoru Hosokawa
khosokawa@....com