久々に java-ja 行ってきた
java-ja＠東京の真面目なイベントは久々ですね。実に半年ぶり？(ﾉ ∀`) 僕のエントリも半年ぶり。いやホントすんません。
今回はドワンゴの会議室にお邪魔しました。本来なら土日は空調が止まっちゃうんだけど，無理言って動かして貰ったと聞きました。ドワンゴ++。id:coji++。
50 人ぐらい入れて，無線 LAN 完備の会議室ってなかなか無いんですよねぇ。ああ，無線も私物でしたっけ。重ね重ねありがとうございます。
TDD は黄金の回転
前半は id:t-wada による TDD 講座。だいたいいつもの奴をなぞった感じだなぁｗ 予習が生きた。
「TDD は黄金の回転である」というのは元ネタが SBR であることを意識すると実はものすごく深い言葉だということにようやく気づけた。黄金の回転はスタンドではない。スキルだ。つまり TDD は努力によって手に入れることが出来る技術なのだ。
「タワーズ・クエストのロゴは TDD をイメージしている」というのは初耳だった。すげぇ……！
リファクタリング重要
今回新しかったのは「黄金の回転の中で一番重要なのがリファクタリングである」と明言された点ですね。
リファクタリングを怠り，単に Green <-> Red の繰り返しのみで TDD を行っていくとリファクタリングのコストが極大に向かう。Green -> Red -> Green の流れはそれなりに染みついてきたとは思うんだが，結構 Refactor はおろそかにしがちなので改めて「Red -> Green -> Refactor」の三つの矢印を意識し直したいと思う。
いつコミットすべきか
今回は専用の subversion が用意されていた (準備乙！) こともあり，TDD の黄金の回転の中でいつバージョン管理システムにコミットすべきか，ということにも言及があった。
結論から言うと Red -> Green -> Commit -> Refactor -> Commit を基本の流れにすべきである。もちろん 仮実装をコミットすべきかどうか等，その場の状況にもよるが Green になったらコミットする文化は大事にしたい。細かくコミットするのは良いことなので。
テストのフォーカス
@Test
public void 足し算() throws Exception {
Calculator calculator = new Calculator();
assertEquals("1と2を足したら3になる", 3, calculator.add(1, 2));
}
@Test
public void 引き算() throws Exception {
Calculator calculator = new Calculator();
assertEquals("3から2を引いたら1になる", 1, calculator.sub(3, 2));
}
のようなコードがあるとき (メソッド名が悪いのはとりあえず置いといて)，共通部分 (Calculator calculator = new Calculator();) を @Before に追い出すべきかどうか。
考えるべきはテストのフォーカスである。テストしたいのは Calculator object の生成ではなく，add メソッドだ。今回のように new するだけなら良いけれど，準備に何行もかかるようなら追い出した方が add メソッドをテストしているということをはっきりと示せる。
が，メソッド内だけで完結することもテストのフォーカスを示す上で意味があると言えるのでやはり臨機応変に空気読んで書くべし。
JUnitMax
id:kompiro による JUnitMax のデモ。保存されたらテストが自動で走るのは良いですね。CSS を保存したらブラウザをリロードとか，.as ファイルを保存したらブラウザリロードとかやってるんだから，それが Eclipse で，テストで出来ない理由は無いよなぁ。
それ以上の利点はイマイチ見て取れなかったなぁ。あ，fastview の位置に TDD のバーがあるのは正しいと思う。こういう常に参照したい情報は，ビューのタイトルよりももっと分かりやすい場所に出ているべきだよね。
System.out.println か assert か
ライブラリの動作を確認するために書いているテストなど，とりあえず System.out.println して動作を目で確認することをよくやるんだが，どういうときに assert と使い分けるのか，という質問。
もし System.out.println で出している内容が有用なら assert にして，資産とすべき，という至極当然の答えでしたねｗ 下手に wiki に動作を書くよりも，テストがある方がそのままサンプルにもなって分かりやすい。
でも「テストよりもコンソール出力の方が見やすいんだよね。ツールの問題だけど」「自分が確認するだけならばマウスオーバしないと値が確認出来ない JUnit ビューよりもそのまま出てくれる Console 出力を選んじゃうなぁ」という話を懇親会でしていたら「ツクレカス」と言われた。
,r::::::::::::::::::::'-､
,,r'::::::::::::::::::::::::::::::::::ヽ
.l::::::::::::::::::::;:-‐''" `-､::ヽ、
. l::::::::! '" i::::::ヽ
ヽ::::i _,.. !_,.._- :..l::::::::::!
l:::l ,ｨt:t::: ':::rtｪ::;:.. ヽ::::;!
!ヾ'´':::´;' ::.`ヾ ヾ Y ::!
. i :! ;` ｰ'`ヽ l ﾉi
ヽ! :, ---.､ : /! '
ヽ :' − ::. ;'.!
ヽ ,:' l,r 'ヽ
rヽ ￣ , -'r' r'ヽ
i' lヽ r'7,r'´ ' ' ` ｰ
l l! i. /,,r' ´
ツクレカス（2009〜？）
手を動かした
ペアプロのお題は「プライオリティキューの実装」。前回の TDD の回 で学んだことは渡せたかなぁ。
- TDD とは，小さなゴールを積み上げることによって問題を解決する開発技法である。
- 問題の解決法が見えているときに，更に TDD で頭の中と同じ物をテストに落とす必要はあまり無い。
- が，仕様変更が必要だと分かった瞬間に，足下の安心感をどれだけ築いておくことが出来るかは重要。TDD の恩恵の一つ。
まぁあくまで「僕の理解」なんだけどねー。
さっぱりどう解決したら良いか分からない状態になったときに TDD に任せてテストコードをひたすら書いていくと，ふと気づいたら問題が解決していた，という経験をすると TDD の本質を掴めるんじゃないかしら。
ペアプロの課題については，だいたい ペアプログラミング に書いてある(し，解決法まで書いてある) ので割愛。あー，その通りだよなぁ，と再確認した。
社内のブランチを svn から git に変更することの利点
コミット対象を自分の場所とすることでコミットの敷居が下がる。自然と情報の流通量そのものが増え，また共有がなされるようになる。という，掲示板からブログになったときのような心理的障壁の解除が大きな利点。
- 自分の場所にならコミットするので「僕のローカルではそのバグ直してるんですが」というよくある会話は減り，中央のソースも頑丈になる。OSS の利点と同じ。
- 自分の場所になら小さな単位でコミットされるので，技法の共有がはかられやすい。60 ファイル変更したときの diff は読まないけど，メール 60 通なら読める。
後はマージ時の履歴の取り込みとかの技術的なメリットかなぁ。
中央集権的なバージョン管理 (ブランチを切るのに管理者による承認が必要とか) はありがちなんだけど，コードを共有する，変更したら pull request する，という感覚を持ちづらいのは間違いない。それは悪だよね。
1 人日 6 時間として見積もる
懇親会は何故か見積もりの話で盛り上がった。PG/PM のどちらがスケジュールを決めるのかとか，タスクを積み上げて見積もることの是非とか。アジャイルな見積りと計画づくり は未読なんだよなぁ。とりあえず Amazon で買った。
理想的な環境ですら、１日８時間定時として、６時間はギリギリな見積もり。メールもこないし、電話もこないし、チームメンバーも話しかけてこない。そんな孤独な環境で、６時間見積もりじゃないだろうか。
ツクレカス
懇親会での会話が愚痴になりかけると「この話のゴールはどこなの？」「結局何が問題なの？」と問いかけてくる id:Yoshiori や id:Yamashiro0217 は凄いなぁ，と思った。圧倒的に正しいわ。ドワンゴパネェ。このチームは会議短いんだろうなぁ。
新人にまず読ませる書籍は？
僕なら全力で UNIXという考え方 を推す。
達人プログラマー は学ぶ時の心構えを書いてある本なので分かるけど，Effective Java は無いわー。コードに触れるのは，はじめは業務だけで十分じゃないかなぁ。作っている物，作りたい物がはっきりして，何回か詰まってそれから読んだ方が分かりやすいと思うんだよね。少なくともアレを読んで頭に入ってくるなら新人の域を超えてるんじゃないかと。
n 次会は t-wada 邸
ドミニオンやったり，○○業界は何故ブログを書かないんだろう，まとめ直して高速道路作る癖付けないと世界に置いてかれるよね的な話をしたりしながら結局朝 10 時まで居たｗ 講演といい，飲みといい，お世話になりました。