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

ホーム

2010年07月17日

「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

「王様は裸だよ!」と叫んだ少年は、その後どうなったの
だろうか?

正直者として称えられたのか、それとも、捕えられて断首台に
かけられたのか。

本家Permlink


2010年07月04日


本家Permlink


2010年07月01日2

どうもTwitterだと聴衆を意識しちゃって書けなくなるね (笑)。

自分の場合、長年の習性で書きながら考えるんで、書かなく
なると考えなくなっちゃう (笑)。

--

不具合の多さは自分らの活動の質の低さを示してるん
だから、朝会をなくして時間を稼ごうとか、小賢しい
マネをしても仕方ない。

実戦である以上、ある程度フォームを崩されても結果を
出すことは大切だ。でも、なんといっても、活動は
リリースで終わるわけじゃない。次のリリースも、その
次のリリースもある。それがプロジェクトでも同じこと。
次のプロジェクト、その次のプロジェクトがある。

だから、できるだけ踏ん張ってフォームを崩さない
ようにする。崩されたフォームを元に戻すのは驚くほど
難しいんだよ。

--

気をつけなきゃいけないのは、悪循環なんだよ。

悪循環は断つのが難しい。だから、悪循環に入らないことが
肝心になる。

フォームを崩すっていうのは、そういう悪循環の入口に
なるんだよ。

本家Permlink


2010年07月01日1

少なくともXPは、個々の実践を寄せ集めたものではない。
価値と原則に基づく実践という体系を持つ。

この価値と原則を定めることは、アジャイルをやるか
どうかに関係なく大切なことだ。サッカー日本代表の
岡田監督はそれを「フィロソフィー」と呼んでいる。

  実は僕はどこのチームの監督をやる時でも、フィロソフィーを作っていたの
  ですが、日本代表だけは「たまに集まるチームだから、そんなのやってもしょ
  うがない」と思って作っていなかったんです。そしてこの時(キリンチャレン
  ジカップ2008でウルグアイに負けたとき)、初めてフィロソフィーを作りまし
  た。http://bizmakoto.jp/makoto/articles/0912/14/news010_4.html

XPはXPのフィロソフィーを持つ。それをそのまま受け
入れることができれば、それでもいい。でも、それが
受け入れられないのであれば、自分たちで作るしかない。

実践よりもまずやらなければいけないことは、自分を
見つめ、何に価値を見出し、何を守るべきか決めること
ではないだろうか。

--

もちろん、形から入ることを否定するわけじゃない。
それはそれで悪いやり方じゃない。しかし、学びて
思わざればすなわち暗し。その実践の意義を考える
ことも大切。

本家Permlink


2010年07月01日

たとえば、2つのクラスが同じ名前のインスタンス変数を
持っていたとする。しかもDRYに反する気がする。このとき、
インスタンス変数を1つのクラスに寄せるのがもっとも
一般的なリファクタリングとなる。しかし、ときには、
一方の名前を変えてやるほうが適切なことがある。変数の
名前が同じでも、使われ方や役割が違う場合にこれが当て
はまる。

--

複数のバージョンを平行して開発しているときに恐いのが
マージ漏れ。マージ漏れをどうやって見つけるか。
ストーリーを洗い出すのが基本。さらに、ストーリーの
テストを回す。

--

ああ、上のを書いて思ったんだけど、ユニットテストじゃ
マージ漏れは見つけられないんだね。

--

ストーリーのテストはまとめ方や順番を工夫する。

バージョンごとにまとめる。機能ごとにまとめる。

新しいもの、最近修正されたものから先にやる。

--

短いイテレーションでやってると、長期的な視点、
リリースまでのスケジュールを忘れてしまいがちだ。
管理者は知っていても、それがみんなに伝わっていない。

--

メタファーとしての学習。予習、復習。

『今日、コード・レビューだったよね? ちゃんと予習
してある?』

本家Permlink


Copyright © 1905 tko at jitu.org

バカが征く on Rails