ホソカワです。
MLまでたどり着いていなかったようです。
--
Kaoru Hosokawa
khosokawa@....com
----------
> From: Kaoru Hosokawa <khosokawa@....com>
> Date: Mon, 29 May 2000 01:01:12 +0900
> To: Extreme Programming JP <extremeprogramming-jp@....jp>
> Subject: XP Chapter 17 Design Strategy の解説
>
> ホソカワです。
>
> 17章の解説です。
>
> デザインはシンプルにする事と必要なデザインしか行わない。この２点がこの章の論点
> です。裏付けなしではなく、valuesやpracticesからデザイン戦略を導いているところ
> が特筆するべき点でしょう。
>
> ----
>
> Chapter 17 Design Strategy
> ==========================
>
> うまく行くであろう最も単純なこと（The Simplest Thing That Could Possibly Work
> ）
> ------------------------------------------------------------------------
>
> 少し戻って「Four Values」の観点からこの考え方を導く。
>
> ・Communication
>
> 複雑なデザインはシンプルなデザインより伝達することが難しい。従って、シンプルな
> デザインが得られるようなデザイン戦略を作らなくてはならない。しかし、デザインの
> 要素は重要なデザインの様相を伝達するものでなくてはならない。
>
> ・Simplicity
>
> デザイン戦略自身もシンプルでなくてはならない。簡単に実行できると言う事ではなく
> 、戦略の表現がシンプルでなくてはならない。
>
> ・Feedback
>
> XPを実践する前は、いつデザインが正しいのか間違っているのかわからなかった。シン
> プルなデザインは、この問題を解決している。シンプルなデザインは素早く作成するこ
> とができ、コードを書き、コード（デザイン）をすぐ評価することができる。
>
> ・Courage
>
> 「少しのデザインで止めて、必要に応じてデザインの追加ができる自信を持つ。」これ
> より勇気のある行動がありますか？ [コメント：デザイン時に見えていないところが
> あってもデザインを完結しないでコーディングに入るということですよね？]
>
> 「Four Values」に従うと、
>
> ・シンプルなデザインができるデザイン戦略の作成
> ・デザイン戦略の質を確かめる方法をすばやく見つける [コメント：戦略がシンプル
> であれば簡単に戦略を評価できるということですね？]
> ・学習した事をデザインにフィードバックする
> ・プロセス全体のサイクルタイムの極限まで短縮する
>
> 「Principles」もデザイン戦略に作用している。
>
> ・少ない初期投資（Small initial investment）
>
> デザインには最小限の投資で見返りを得るようにする。
>
> ・シンプルなデザインを仮定する（Assume simplicity）
>
> 我々はシンプルなデザインがうまく行く事を仮定している。この仮定が間違っていても
> 、仮定することによって完璧な仕事をする余裕を得ている。その間、複雑さから出るオ
> ーバーヘッドを持たなくても良い。
>
> ・徐々に更新する（Incremental change）
>
> 我々は少しづつデザインを行う。完成したデザインなどは永遠にない。デザインは、常
> に変化の対象となっている。
>
> ・軽装で動く（Travel light）
>
> デザイン戦略は余分なデザインは作成しない。現時点で必要最小限であるべきである。
> 変化を掌握するのであれば、シンプルに始め、継続的に磨きをかける。
>
> 「いつ、追加デザインを行うのか？（When do you add more design?）」
>
> 一般的な答えは、「明日を視野にいれてデザインする」である。しかし、この戦略に不
> 確実性が作用すると、明日のためのデザインが永遠に使用されないかもしれないし、ま
> た、よりシンプルな方法（デザイン）を発見してしまうかもしれない。どちらにしても
> 、必要のないコードの修正コストを払うか、複雑なデザインを持ち続けるか、しなくて
> はならない。
>
> このような状況にならないように、「今日の問題は今日デザインし、明日の問題は明日
> 行う」ようにするべきである。従って、下記の戦略が導かれる。
>
> 1.テストを最初に書く。書く事によって、コードの完成がいつかがわかる。ある程度の
> デザインを行わなければ、テストは書けない。
>
> 2.テストをパスする為に必要最小限なデザインとコーディングを行う。
>
> 3.くりかえす
>
> 4.デザインをよりシンプルにできるチャンスを発見したら、行う。
>
> この戦略はばかばかしいほどシンプルです。しかし、シンプルですが、ばかばかしくは
> ありません。この戦略で大きくきわめて高性能なシステムを作成することが可能です。
>
>
> 「リファクターによる設計」はどのように機能するのでしょう？（How Does
> "Designing Through Refactoring" Work?）
> --------------------------------------------------------------------
>
> この戦略を実践すると違和感を感じるかもしれない。最初のテストケースを取り上げる
> 。このテストケースを満たすには、一つのオブジェクトと二つのメソッドが必要なので
> それらを実装して、完成。システムの全体のデザインは、このオブジェクト一つだけで
> ある。次のテストケースを取り上げる。今度は、リストラクチャ−が必要なので、まず
> リストラクチャ−を行い、最初のテストケースがパスする事を確認して、二つ目のテス
> トケースに取りかかる。
>
> 二、三日するとシステムが二組のペアでもお互いに干渉しないぐらい大きくなります。
> その後、もっと大きなチームがこのスタイルで開発できるシステムになります。
>
> 時折、不快感（crud has been creeping behind them）を受けるようになります。見積
> もりが定期的に外れたり、修正しなくてはいけないとわかっていながら手を付けていな
> い箇所が心をいためたりし始めます。こんな時は、「タイム」と言って、システムを修
> 正します。
>
> 簡単に修正できない場合もあります。そのような大きなリファクタリングは、少しづつ
> 、小さなステップで進んで行きます。何時の間にか大きかったリファクタリングが小さ
> なステップになっています。
>
> XPでの設計は多数の絵を描いて、それに準拠するシステムを作る事ではありません。自
> 動車をスタートして、こっちに向けたり、あっちに向けたり、またこっちに向けて運転
> する事です。
>
>
> 何が最も単純なのでしょう？（What Is Simplest?）
> ----------------------------------------------
>
> 最も単純とは以下のような事です。
>
> 1.システム（コードとテストケース）から必要な情報はすべて読み取ることができる。
>
> 2.システムは重複するコードを含まない。（1.と2.を合わせて「Once and Only Once
> Rule」と言う。）
>
> 3.システムを構成するクラスの数は最小限に抑える。
>
> 4.システムのメソッドの数も最小限に抑える。
>
> システムを伝達手段と見なした場合、重要な概念にオブジェクトやメソッドを当てはめ
> ます。クラス名とメソッド名は協調するように選びます。重複を取り除くことが一番難
> しい作業です。まず、重複するロジックを見つけ、それを排除しなくてはなりません。
> 重複を排除する作業は、小さいオブジェクトと小さいメソッドを多数作成する事になり
> ます。そうでなければ、重複がある事を意味します。だからと言ってむやみにたくさん
> のオブジェクトを作る事でもありません。なにもしないクラスやメソッドは削除します
> 。
>
> 正しく機能しているシステムから必要のないものをすべて削除します。残ったシステム
> が「simplest design that could possibly work」です。
>
> これはうまく行くのでしょうか？（How Could This Work?）
> -----------------------------------------------------
>
> いままでの戦略は、修正の確率とコストを下げる事で、ソフトウェアの開発コストを下
> げようとしていました。XPはこのアプローチとはまったく逆で、修正で成り立っていま
> す。開発にはリスクが伴います。第３章で話したように、不確実性があるのであれば、
> デザインをしないでなにもしないで待つ事がいい場合があります。
>
> しかし、もし明日修正を加えるコストが非常に高いのであれば、見積もりが正しいかも
> しれないので今日作業するべきです。もし、デザインに必要な勢いが低いのあれば（非
> 常に優秀な人たちがいれば）、看板方式のデザインのメリットは低いです。もし、あな
> たが非常にすぐれた予想屋であれば、今日すべてのデザインを行って下さい。でもこれ
> らにあてはまらない私達は、「今日のデザインは今日行い。明日のデザインは明日行う
> （today's design should be done today and tomorrow's design should be done
> tomorrow）」以外の道はありません。
>
> 設計での絵の役割（Role of Pictures in Design）
> ---------------------------------------------
>
> 絵で設計するなとは言っていません。絵や図で考えることが得意な人もいます。絵でデ
> ザインをすることはコードを書くより速い場合もあります。絵でデザインすることの問
> 題点は、フィードバックを得る事が出来ないことですーテストケースがパスするかどう
> かわかりません。
>
> XPのprinciplesに戻って、絵でデザインするための戦略を考えてみましょう。
>
> ・少ない初期投資ー必要最小限の絵を描きましょう。
> ・勝つために実行するーデザインがわからないという恐怖感から絵を使用するのは止め
> ましょう。
> ・敏速なフィードバックー絵が正しいかどうかただちに見極めましょう。
> ・人の直感も使うー絵で考える事のできる人たちに絵でデザインは任せましょう。
> ・変化を抱擁して、軽装で動くー絵は保存せずに使い終わったら、捨てましょう。
>
> 絵でデザインをしたければ、そうしてください。ただ、コードで表現できるようになっ
> たら直ちにコードに移って下さい。絵でソースコードを表現する事ができるのであれば
> 、編集、保守を絵でおkなって下さい。ただ、絵とソースコードと両方で同じ情報を整
> 合性を取らなくてはならないような状況はいけません。
>
> システムのアーキテクチャー（System Architecture）
> ------------------------------------------------
>
> システムのアーキテクチャーはXPでも大事です。アーキテクチャーの一部は、システム
> メタフォーでとらえています。最初のイタレーションでシステム全体のアーキテクチャ
> が見えるストーリーを選択します。これらのストーリーを実装すれば、アーキテクチャ
> ーを得る事ができます。全体のアーキテクチャーが見えるストーリーが集まらない時は
> 、必要な箇所だけ作り、後で変更できる事能力があることを信じましょう。
>
> --
> Kaoru Hosokawa
> khosokawa@....com