佃＠原書発注中です。
質問とコメントを書きます。
Yutaka Kamite wrote:
>
> 上手＠データ通信システム です。
>
> ●メタファー（例）
> それぞれのXPソフトウェアプロジェクトは頭上の輝くアーチとなるメタファー
> （例）によって導かれる。例は時にはうまく機能しないこともある、例えば
> 契約、顧客、契約違反などの専門用語で語られる契約管理システムが
> そうだ。また例は時にはちょっと説明を要する場合もある、例えばコンピュ
> ータはデスクトップのように見えるとかとか、年金計算はスプレッドシート
> のようなものだと言ったりする。実際に”そのシステムはプレッドシートだ”
> とは言っていないのだから、これらは全て例だ。例は、プロジェクトの全員
> が基本的な要素とその相互関係を理解するのに役立つ。
>
> 技術的なエンティティを識別するのに使われる用語には、いつも例を選ん
> でこれを使うべきだ。開発が進行するにつれて例がこなれて（成熟して）
> くると、チームの全員が例を使うことに新しいインスピレーションを見いだ
> すようになる。
>
> XPにおける例は他の人たちが”アーキテクチャ”と呼ぶもののほとんどを
> 置き換える。10000ｍにも見える（？）システムのアーキテクチャに当たる
> 際の問題点は、アーキテクチャが必ずしもシステムをわかりやすく見せて
> くれないことだ。アーキテクチャはととも大きな箱と関係の集合だ。
> ”駄目なのはアーキテクチャが駄目だからだ”という声が聞こえるが、我々
> は、自然でわかりやすいストーリー、その中で仕事をし、ビジネスマンも技
> 術者もたやすく共に担えるストーリー、を全ての人に与えつというアーキテ
> クチャのゴールを強調しておきたい。例を求めることにより、我々は伝える
> のも追加するするのも容易なアーキテクチャを得られそうだ
メタファーとアーキテクチャの関係がよくわかりませんでした。
メタファーそのものも、よくわかってません。
メタファーとは具体例で説明することでしょうか？
メタファーはアーキテクチャに代わるのもでしょうか？
>
> ●テスティング
> 自動化されたテストの無いプログラム機能は存在しない。プログラマは、
> プログラムの動作についての自信がプログラムそれ自身の一部になる
> ことができるように、単体テストを書く。顧客も、プログラムの動作につい
> ての自信がプログラムの一部になることができるように、機能テストを書
> く。その結果、プログラムは時間が経過するにつれ、より満足のいくもの
> になる−変化をより多く、より少なくではない、受け入れることができるよ
> うになる。
> あなたの書いたそれぞれのメソッドについて、テストを書く必要は無い、
> 止まる可能性のある生産メソッドだけで良い。
テストは誰が書くのでしょうか？
ＸＰでは、メソッドを追加したときに開発者が単体テストのコード
も書くと思っています。
これは、メソッドの内部ロジックを変更した場合の話でしょうか？
>
> ●リファクタリング
> プログラム機能を実装している時、プログラマはいつも、その機能を単純
> に追加するための、既存のプログラムを修正する方法があるのではない
> かと問う。機能を追加した後、プログラマは、こんどは、まだテストケース
> が動いているのに、プログラムをより単純にするにはどうするかを問う。
> これはリファクタリングと呼ばれる。
> これは、動いているある機能を得るために絶対的に必要とされるよりも多
> くの仕事を時々する、という意味では無いことに注意せよ。そうでなく、こ
> の様に仕事をすることで、次の機能を、そしてその次も、その次も、合理
> 的な量の努力で追加することが出来ることが確実になる。しかしリファクタ
開発者は、常によりよい構造にしておけば、修正が楽になることは
わかっているんですよね。
でも、ついつい目先の内部リリースなどの納期の圧力に屈してしま
う。
この部分だけ取り入れようとしても、強力なプロジェクト管理者が
いないと、なかなか実現しない。
ペアプログラミングなどの他のプラクティスも導入する必要があり
ますね。
>
> ●ペアプログラミング
> 全ての生産コードは二人で、一つのマシン、一つのキーボード、一つの
> マウスを使って書かれる。
> それぞれのペアには二つの役割がある。パートナーの一人、キーボード
> とマウスを使っている人はこのメソッドを実装する最も良い方法を考える。
> 別のバートナーはより戦略的に考える：
この方法、採用してみたい。
実装で熱くなっている側に、冷静に検討している人がいれば、熱く
なっている人の暴走を止めることが出来る。
ペアプログラミングは一見無駄なようだが、たくさん利点がありそ
う。無駄のように見える部分のコストと利点により削減できるコス
トを比較した資料ってないのかなあ。
>
> ●継続的インテグレーション
> ２、３時間から最大でも１日の開発の後、コードは統合されテストされる。
最大で一日でしたか。すごい。
>
> ●週４０時間
> 私は毎朝フレッシュで意欲に満ち、毎晩疲れていて満足していたい。金
> 曜日には、疲れていてたっぷり満足していたい、土日の２日間を仕事以
> 外のことについて考えられるように。そして月曜日には火の玉（fire)と沢
> 山のアイデアに満ちて戻って来たい。
残業、休日出勤で疲れた人間が集中して仕事できる分けがないのだ
から、是非ともこうしたいものです。
しかし、現実のプロジェクトマネージャは「残業、休日出勤なし」
などと口が裂けても言えない、、、、
いつもでなくてもいいから、たまには宣言してほしい。
＃ちなみに私は過酷な労働はしていません。
--
佃 軍治 tsukuda@....jp
日立製作所システム開発研究所第２部