2005
6
7
8
9
10
11
12
2006
1
2
3
4
5
6
7
8
9
10
11
12
2007
1
2
3
4
5
6
7
8
9
10
11
12
2008
1
2
3
4
5
6
7
8
9
10
11
12
2009
1
2
3
4
5
6
7
8
9
10
11
12
2010
1
2
3
4
5
6
7
8
9
10
11
12
2011
1
2
3
4
5
6
7
8
9
10
11
12
2012
1
2
3
4
5
6
7
8
9
10
11
12
2013
1
2
3
4
5
6
7
8
9
10
11
12
2014
1
2
3
4
5
6
7
8
9
10
11
12
2015
1
2
3
4
5
6
7
8
9
10
11
12
2016
1
2
3
4
5
6
7
8
9
10
11
12
2017
1
2
3
4
5
6
7
8
9
10
11
12
2018
1
2
3
4
5
6
7
8
9
10
11
12
2019
1
2
3
4
5
6
7
8
9
10
11
12
2020
1
2
3
4
5
6
7
8
9
10
11
12
2021
1
2
3
4
5
6
7
8
9
10
11
12
「xUnitを使ったTDDは、Compile-Driven Developmentと 大して違わない」という話があった。 しかし、個人的には、compileとrunとの間には大きな 違いを感じる。コンパイルが通っても大してうれしく ないが、runすればうれしい。 しかし、xUnitでrunされるコードは完全な製品ではない。 製品と同じコードが使われるが、製品と全く同じという わけではない。ならば、xUnitのrunでもたらされるうれしさは 偽者なのだろうか？ -- 狼少年は本当にウソをついたのだろうか？ 狼少年がウソをついたかどうかは、狼少年しか知らない。 周囲が「アイツはウソばかりつくヤツだ」と思うように なったとき、本当にウソをついていたかどうかにかかわらず、 狼少年は黙ることだろう。 -- 『裸の王様』 http://ja.wikipedia.org/wiki/%E8%A3%B8%E3%81%AE%E7%8E%8B%E6%A7%98 「王様は裸だよ！」と叫んだ少年は、その後どうなったの だろうか？ 正直者として称えられたのか、それとも、捕えられて断首台に かけられたのか。
どうもTwitterだと聴衆を意識しちゃって書けなくなるね (笑)。 自分の場合、長年の習性で書きながら考えるんで、書かなく なると考えなくなっちゃう (笑)。 -- 不具合の多さは自分らの活動の質の低さを示してるん だから、朝会をなくして時間を稼ごうとか、小賢しい マネをしても仕方ない。 実戦である以上、ある程度フォームを崩されても結果を 出すことは大切だ。でも、なんといっても、活動は リリースで終わるわけじゃない。次のリリースも、その 次のリリースもある。それがプロジェクトでも同じこと。 次のプロジェクト、その次のプロジェクトがある。 だから、できるだけ踏ん張ってフォームを崩さない ようにする。崩されたフォームを元に戻すのは驚くほど 難しいんだよ。 -- 気をつけなきゃいけないのは、悪循環なんだよ。 悪循環は断つのが難しい。だから、悪循環に入らないことが 肝心になる。 フォームを崩すっていうのは、そういう悪循環の入口に なるんだよ。
少なくともXPは、個々の実践を寄せ集めたものではない。 価値と原則に基づく実践という体系を持つ。 この価値と原則を定めることは、アジャイルをやるか どうかに関係なく大切なことだ。サッカー日本代表の 岡田監督はそれを「フィロソフィー」と呼んでいる。 実は僕はどこのチームの監督をやる時でも、フィロソフィーを作っていたの ですが、日本代表だけは「たまに集まるチームだから、そんなのやってもしょ うがない」と思って作っていなかったんです。そしてこの時(キリンチャレン ジカップ2008でウルグアイに負けたとき)、初めてフィロソフィーを作りまし た。http://bizmakoto.jp/makoto/articles/0912/14/news010_4.html XPはXPのフィロソフィーを持つ。それをそのまま受け 入れることができれば、それでもいい。でも、それが 受け入れられないのであれば、自分たちで作るしかない。 実践よりもまずやらなければいけないことは、自分を 見つめ、何に価値を見出し、何を守るべきか決めること ではないだろうか。 -- もちろん、形から入ることを否定するわけじゃない。 それはそれで悪いやり方じゃない。しかし、学びて 思わざればすなわち暗し。その実践の意義を考える ことも大切。
たとえば、2つのクラスが同じ名前のインスタンス変数を 持っていたとする。しかもDRYに反する気がする。このとき、 インスタンス変数を1つのクラスに寄せるのがもっとも 一般的なリファクタリングとなる。しかし、ときには、 一方の名前を変えてやるほうが適切なことがある。変数の 名前が同じでも、使われ方や役割が違う場合にこれが当て はまる。 -- 複数のバージョンを平行して開発しているときに恐いのが マージ漏れ。マージ漏れをどうやって見つけるか。 ストーリーを洗い出すのが基本。さらに、ストーリーの テストを回す。 -- ああ、上のを書いて思ったんだけど、ユニットテストじゃ マージ漏れは見つけられないんだね。 -- ストーリーのテストはまとめ方や順番を工夫する。 バージョンごとにまとめる。機能ごとにまとめる。 新しいもの、最近修正されたものから先にやる。 -- 短いイテレーションでやってると、長期的な視点、 リリースまでのスケジュールを忘れてしまいがちだ。 管理者は知っていても、それがみんなに伝わっていない。 -- メタファーとしての学習。予習、復習。 『今日、コード・レビューだったよね？ ちゃんと予習 してある？』
Copyright © 1905 tko at jitu.org