ホソカワです。
上手さん、コメントありがとうございます。
on 2000/05/31 10:46 PM, Yutaka Kamite at y-kamite@....jp wrote:
> ホソカワさん、上手です。
> ちょっとコメントさせてください。
> ＃１６章は「コメントすることがなかった」のでコメントしてません。
>
> On Tue, 30 May 2000 21:32:51 +0900
> Kaoru Hosokawa <khosokawa@....com> wrote:
>
>> ホソカワです。
>>
>> 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
>>>
>>> 複雑なデザインはシンプルなデザインより伝達することが難しい。従って、シンプル
>>> な
>>> デザインが得られるようなデザイン戦略を作らなくてはならない。しかし、デザイン
>>> の
>>> 要素は重要なデザインの様相を伝達するものでなくてはならない。
> aspect は見方とか視点の方が良くないですか。こんな感じで。
> 見方（視点）を伝える
>
「視点」にします。
>>>
>>> ・Simplicity
>>>
>>> デザイン戦略自身もシンプルでなくてはならない。簡単に実行できると言う事ではな
>>> く
>>> 、戦略の表現がシンプルでなくてはならない。
>>>
>>> ・Feedback
>>>
>>> XPを実践する前は、いつデザインが正しいのか間違っているのかわからなかった。シ
>>> ン
>>> プルなデザインは、この問題を解決している。シンプルなデザインは素早く作成する
>>> こ
>>> とができ、コードを書き、コード（デザイン）をすぐ評価することができる。
>>>
>>> ・Courage
>>>
>>> 「少しのデザインで止めて、必要に応じてデザインの追加ができる自信を持つ。」こ
>>> れ
>>> より勇気のある行動がありますか？ [コメント：デザイン時に見えていないところ
>>> が
>>> あってもデザインを完結しないでコーディングに入るということですよね？]
> 後で繰り返し出てくる、「必要な時にリファクタリングを行い良く出来る」という
> 自信だと思います。
>
「リファクタリングを行う事で、デザイン追加が突然必要になっても、問題ない」と
いうことですね。
…
>>>
>>> 「リファクターによる設計」はどのように機能するのでしょう？（How Does
>>> "Designing Through Refactoring" Work?）
> Fowler本も「リファクタリング」なので、それで統一したらどうでしょうか？
>
はい、そうします。
…
>>> これはうまく行くのでしょうか？（How Could This Work?）
>>> -----------------------------------------------------
>>>
>>>
>>> いままでの戦略は、修正の確率とコストを下げる事で、ソフトウェアの開発コストを
>>> 下
>>> げようとしていました。XPはこのアプローチとはまったく逆で、修正で成り立ってい
>>> ま
>>> す。開発にはリスクが伴います。第３章で話したように、不確実性があるのであれば
>>> 、
>>> デザインをしないでなにもしないで待つ事がいい場合があります。
>>>
>>> しかし、もし明日修正を加えるコストが非常に高いのであれば、見積もりが正しいか
>>> も
>>> しれないので今日作業するべきです。もし、デザインに必要な勢いが低いのあれば
>>> （非
> inertia は文字どおり”慣性”と考えて、こんなニュアンスかなと思います。
> 力を使わないでも楽々デザインを続けられる（デザインを続けるのに全く苦労が無い）
>
「もし、簡単にデザインできるのであれば（非常に優秀な人たちがいれば）…」にし
ます。
>>> 常に優秀な人たちがいれば）、看板方式のデザインのメリットは低いです。もし、あ
>>> な
>>> たが非常にすぐれた予想屋であれば、今日すべてのデザインを行って下さい。でもこ
>>> れ
>>> らにあてはまらない私達は、「今日のデザインは今日行い。明日のデザインは明日行
>>> う
>>> （today's design should be done today and tomorrow's design should be done
>>> tomorrow）」以外の道はありません。
>>>
>>> 設計での絵の役割（Role of Pictures in Design）
>>> ---------------------------------------------
> ここで言っている”絵”は、UMLによる分析・設計図のことのようですが、
> うまい訳がありませんでしょうか？ ＞ALL
>
>
Beck氏は、手書きのニュアンス、さらさらと丸や矢印を書く感じを伝えたかったので
はないかと思います。分析/設計図でしたら、「diagram」と言っていると思います。
>>> 絵で設計するなとは言っていません。絵や図で考えることが得意な人もいます。絵で
>>> デ
>>> ザインをすることはコードを書くより速い場合もあります。絵でデザインすることの
>>> 問
>>> 題点は、フィードバックを得る事が出来ないことですーテストケースがパスするかど
>>> う
>>> かわかりません。
>>>
>>> XPのprinciplesに戻って、絵でデザインするための戦略を考えてみましょう。
>>>
>>> ・少ない初期投資ー必要最小限の絵を描きましょう。
>>> ・勝つために実行するーデザインがわからないという恐怖感から絵を使用するのは止
>>> め
>>> ましょう。
>>> ・敏速なフィードバックー絵が正しいかどうかただちに見極めましょう。
>>> ・人の直感も使うー絵で考える事のできる人たちに絵でデザインは任せましょう。
>>> ・変化を抱擁して、軽装で動くー絵は保存せずに使い終わったら、捨てましょう。
>>>
>>> 絵でデザインをしたければ、そうしてください。ただ、コードで表現できるようにな
>>> っ
>>> たら直ちにコードに移って下さい。絵でソースコードを表現する事ができるのであれ
>>> ば
>>> 、編集、保守を絵でおkなって下さい。ただ、絵とソースコードと両方で同じ情報を
>>> 整
> ＊入力ミスです。
>
直します。
>>> 合性を取らなくてはならないような状況はいけません。
>>>
>>> システムのアーキテクチャー（System Architecture）
>>> ------------------------------------------------
>>>
>>> システムのアーキテクチャーはXPでも大事です。アーキテクチャーの一部は、システ
>>> ム
>>> メタフォーでとらえています。最初のイタレーションでシステム全体のアーキテクチ
>>> ャ
>>> が見えるストーリーを選択します。これらのストーリーを実装すれば、アーキテクチ
>>> ャ
>>> ーを得る事ができます。全体のアーキテクチャーが見えるストーリーが集まらない時
>>> は
>>> 、必要な箇所だけ作り、後で変更できる事能力があることを信じましょう。
> ＊入力ミスです。
はい、直します。
--
Kaoru Hosokawa
khosokawa@....com