2009-03-10 :-)
_ 朝ッ
0500 起床
_ 仕事
0830 出勤。
_ 服がバタコ臭い
タバコ臭い
「アリスです」
「テレスです」_ [main]main 関数がどーのこーの
Binary 2.0カンファレンス2006[ 20061215#p11 ]のときの「呼ばれない main 関数」 のネタを思い出した。
Hello, binary world - 佐藤祐介( PDF )
_ [アート・オブ・アジャイル デベロップメント]アート・オブ・アジャイル デベロップメント
fkino さんのサイン本
XP について手取り足取り解説している。デブサミ2009[ 20090213#p07 ]のときに「アジャイルになるためには XP のプラクティスを全部やればいいのさ」と fkino さんが紹介していたけどそれが分かった。むしろ全部必要なのである。車輪の両輪のように、XP のプラクティスをどれか 1 つやれば十分なのではなく全部やってこそ XP の真価が発揮される。その辺りの話は本に書いてあるから割愛。
以下 新たに知った言葉たち
インテグレーションテスト
「ユニットテストするのはいいけどファイルを読み書きしたり他の計算機と会話したり基板を使ったりすることもあるはずなんだがそういう場合もユニットテストしてるんだろか」と疑問に思ってたんだが、それはユニットテストではなくインテグレーションテストと呼ぶようだ。うん。インテグレーションテストなら呼吸しつつやってるよね。そいやファイル読み書きする処理をユニットテストしたときは read した内容を write して 2 つのファイルを diff するとかいうことをやったことがある。
Fail-Fast
フェイルファースト。失敗するなら早いうちに失敗してしまえそのほうが傷が浅くて済む、という考え。あとになって取り返しがつかない失敗( 担当者が入院したり逃亡したり客から訴えられたり会社が潰れたり )をするよりも早いうちに
「ペロ。これは...デスマーチ...！」
というように早期発見するための手段としても使える。デスマーチの味を感じたらどうすればいいかと言うと、それを説明するためには残りの紙面が足りない。ところで Fail-Fast という言葉自体は XP よりもけっこう古い言葉でありいろいろなところで引用されてるようだ。ちょいとグーグル検索しただけでもチラホラ見かける。
つまり「とりあえずやってみる」という考え方だ。
以下本書より引用。
失敗を避けようとするのではなく、失敗を受け入れよう。「もしこのプロジェクトが失敗するのが確実なら、できるだけ早く知りたい」と思うようになるんだ。プロジェクトが失敗する可能性に関する情報を手に入れるための方法を探そう。リスクがある領域において、実際に失敗した場合にどうなるのかを確かめるために実験をしてみよう。絶望的なプロジェクトをできるだけ早く中止すれば、それに費やす時間や労力、お金も少なくて済む。( p.395 )
XP でもっとも重要なのはここの部分なのではないか。
Microsoft .NET Framework にも FailFast というメソッドがあるんだがこれとは違うので間違えないように。
Environment.FailFast メソッド (System)
FailFast メソッドは、message パラメータを使用して、ログ エントリを Windows アプリケーションのイベント ログに書き込み、アプリケーションのダンプを作成してから、現在のプロセスを終了させます。
計画
計画や見積もりについては「アジャイルな見積りと計画づくり」がじつに素晴らしい本なのであわせて読みたい。むしろ計画と見積りだけでなくプロジェクト全体について触れているのでかなりお得な本。
4839924023
失敗するなら早いうちにとは多くの人間が感じている<br>点ではないかと推測します。<br>が、どの口がそんなことを明言できるのでしょうか。<br>アジャイルやらXPな本は読んでいませんが、それを<br>客に対しても言うという事ならば、おたく手元にある<br>受託契約書には何書かれているんだい？！<br>ってなことを思ったり。(チーム内部の話なのカナマナ？)
坊T＠さん：<br>受託契約書にはなんと書かれてるんですか？