全国各地からスピーカー、TA陣が集まって非常に豪華な顔ぶれでした。
＃スピーカー、スタッフ、参加された皆さん、楽しい時間をありがとうございました〜
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
◆会場
楽天さんのカフェテリアが良かったです。
プロジェクター(2台も！)も無線LANも電源(さすがに座席分はないですが、タップで分ければ全然問題ありません)も完備で良かったです。
椅子が硬い材質で長時間座っているとツライかもしれませんが、事前に主催者さんが「クッション持ってきた方が良いよ〜」て言っていたので問題なかったです。
主催者の@bufferingsさんが「今後も勉強会で使って行きたい」と言っていましたが、本当に良い環境だと思いました。
以下、完全に自分用メモ。
◆和田卓人(@t_wada)さんの講演「TDD のこころ – テスト駆動開発に大事なもの」
・BC(ブートキャンプ)では、(TDDだけでなく)ペアプログラミングも経験できる
・同じお題を解く(ので)コードレビュー大会ができる
→コードレビュー大会は初体験でしたが「他の人ならどう書くだろう？」を知ることができて新鮮でした(実際にこんなことはなかなか業務ではないので)。
・ソフトウェア開発の三本柱
・バージョン管理
・テスティング
・自動化
→現代的、合理的に開発するのに必要ってのはまさにその通りで。イテレーション0ではまずこれをするってのは鉄則かなと思います。
逆にここを取りこぼすとそれなりにしんどい思いをすることにもなったり。
・バージョン管理
・RPGをセーブ無しでクリアしようするもの
→このメタファは良いなぁと思いました。それにブランチを切る時のメタファにもしっくり来ますし。
今度(バージョン管理に理解を示さない人に)使ってみようと思いました。
・テスティング
・開発者が自分の書いたコードに対してテスト(コードを書いて)する
・自動化(自働化)
・オートメーション
・人間がやっている作業を機械に肩代わりさせる
・コンパイル、FTP…などを自動化する
・人間が使える時間を増やそう(人間にしか使えないことに時間を使うようにする)
・「自働化」は機械がやった結果を人間に教えてくれるってこと
依存の矢印を逆にする。
・ポーリングすることで思考を非同期化して進めることができる
・三脚椅子
・三本柱だと切実感が足りないので、三脚椅子というメタファを言うようにしている
・「一本もないと安定してしまう」って言われたけど(笑)
・まずはバージョン管理から始めるのが大事
・「テスト」にまつわる混乱
・「○○テスト」が多い
日本語の中でも「ユニットテスト」「単体テスト」の違いがあったりする。
・なのでモデルを単純化している
・「誰が何のために」
・DeveloperTesting：開発者が開発促進のために
・CustomerTesting：顧客(のロール)が進捗管理のために
※機能が出来上がっているかどうか？価値が出来上がっているか？…を0か1で判断する。
・QATesting：品質保証担当者(のロール)が品質保証のために
・この話の中には「何を、いつする」てのは入っていない。
・というわけで今日は「DeveloperTesting」をする
・TDDとは？
・書籍「テスト駆動開発入門」
何か分からないことがあったらこの本に立ち返れば良い
・動作する、きれいなコードへ
・その方法論は2つあって、良い設計をしてその後コードにする…これで「動作するきれいなコード」になる。
きれいな設計というのは「沼地」であって「完璧な設計」を追い求めるといつまでも終わらない。
・動かそうとして初めて分かるということがソフトウェア開発には多すぎる。
なので、頭の中で考えているよりもはるかに多い。
・なのでまずは「(すぐには)動かない」汚いコードから、動作する汚いコードにする。
その後、キレイにしていくってのがTDD。
→この四象限のスライドは知っていましたが、初めて直にお話を聴いてやっぱり分かりやすいなぁと思いました。
一方、自分の所属組織の状況に照らし合わせた時にプログラミングをせずに設計する(実際は「設計書を書くだけ」かもしれませんが)人にとってはこの四象限の話はイメージできないのかな？とも思ったりしました。
・TDDと黄金の回転
・四象限に当てまめる
・汚い→キレイにするには意思がいる
・大事なのは小さいうちから初めてやる
・よくある質問で「リファクタリングのコストをどう説明するか？」
・小さいうちからリファクタリングをやっておけば良い
大きくなると投資効果や説明責任が必要になってくる
→リファクタリングを「個別タスク」て考えると確かにその通りで、「テストコードを書く(もちろん通る)」と「リファクタリング」もセットにして「プログラミング」タスクという扱いにしていくのが良いアプローチだと思っています。
・TDDをこころ
・少しづつ、少しづつ
・小さいDoneを少しずつ定義していく
・複数を相手にしない。ひとりずつ対処する。
・1つてストコードを書いて1つ流す
・すばやくまわす
・早ければ早いほど良い
→チームやプロセスにボトルネックがあると素早く回せないので、それも明白になって改善活動につながると思いました。
・素早く回っていないと「問題が大きい」「ピントがボヤけている」証拠。
・小さくすることで「どこが」ピントがぼけているかが明確になる。
・自分が最初のユーザ
・引数にString×6あるようなメソッドって自分が使う際に使いやすいと思うか？
・ドッグフードを食べるのが大事
・不安をテストに
・祈るようではダメ
・命綱を編むようなものがテストコード
・リリース＝バンジージャンプ
で、バンジージャンプする前になって命綱を編むのではなく、日々ちょっとづつやっておく
・TDDをはプログラミング技法
・最大のメリットは「心理的」なもの
・即座にフィードバックを得るため
・書いたコードに自信を持つ
・これから書くコードに自信を持つ
・TDDの真の目的
・変化に対応できるのは「健康」なコード
・無駄がない：引き締まっていて、贅肉がない
・重複がない、分かりやすい名前で、分かりやすい構造になっている
・チームの「健康」
・日々毎日動くかどうか分からないようなコードを残業して書くようでは「健康」ではない
・実装時間具合は1〜2割増、不具合は半分位に減る
・デバッグの工数が減らす
・要求が洗練された
・コードの品質を上げる
・開発工数を減らす
・TDDを導入したことによって減る工数＝デバッグ
・軽微なミスが減る(テストコードもカバーしてくれる)
・小さいバグはコードを書いているのでテストコードがあるのでデバッグをほとんど必要でなくなる
・テストコードがないとデバッグ(推論)をしないといけない
時間が読めないデバッグの工数が減る
◆デモペアプロ
プロジェクターとの接続トラブルで急遽デモマシンを交換していましたが、これがまたキーバインドが違っていて更に混乱を…って感じでした(笑)。
ペアプロの場合、お互いのツールやキーバインドが違っていると生産性(や気分)に影響が出るので、「合わせる」か例えばキリの良い所でコミットなりして、マシン毎交代するなどの工夫がいると思いました(以前、ペアプロやっていた時にはeclipse派とNetBeans派がチームに混在していたので、そうやっていました)。
またメモ。
・とにかく最小限で書くってことが大事
・ゴールの最小限から書いていく
・仮実装
・「今書いたコードが絶対通る」コードのこと
・これで失敗するってことはテストコードがバグっていることがすぐに分かる
・「テストコードをテストコードが必要になるのでは？」の前に、仮実装をすることで「テストコードのテストをする」ことができる。そのタイミングがTDDとして良いタイミングである。
もしこれをしなかったらミューテーションテストが必要になる。
◆吉岡弘隆(@hyoshiok)さんの講演「大規模ソフトウェア開発とテストの経験について」
・今日のメッセージ「開発者の皆さん、テストを書こう」
・安定性に差こそあれ常に動くものがある
・学んだイロハ
・マニュアルを読むこと
・テストを書くこと
・デバッグの仕方
・質問の仕方
・環境は変化する
・自分は変化しているか
お昼直後、かつ、吉岡さんの声が心地よくて、うつらうつらしてしまいました…(すいません)。
◆関将俊(@m_seki)さんの講演「どこまでがTDD?−-TDDの引き算と足し算」
・TDDの場合、最初の「目標を考える」のがポイント。
・まずはそれを書いてRedにする。
テストに沿って実装する。
・壊してみる活動をTDDのサイクルに入れても良いのでは無いか？
・より良く、より強く…動く、キレイに続く指針
・Destoroyがキーワード
◆ペアプロ
・久しぶりだったので余計に疲れた(心地良い疲れだけど)。
・ドライバーでもナビゲーターでもあれだけ集中すれば疲れる。
反省点として(TAの方からも言われたけど)もっと頻繁に交代、休憩を取りながらしたら良かったかも…と思いました。
・(直接TDDの話ではないですが)ペアプロやると設計やプログラムに対して不安が少なくなり、自信を持って進める(少なくとも2人の知識が入っている)ので、精神衛生上、自分にはとても合っているプラクティスだと再認識しました。
◆その他、懇親会
・グリーンバンドの話
・(プロフェッショナルでも)テストコードを書くのが面倒くさいことがある。でもそのグリーンバンドを見て、「プロフェッショナルであるならば、自分の書いたコードは説明できるのは、当たり前だし、テストコードを書くのが当たり前」と思い直す。
・吉岡(@hyoshiok)さんとお話できて良かったです。
(社内外の)勉強会を主催したり、お手伝いすることがちょくちょくあり、その中で「勉強会と組織との関係」みたいなことを考えていました。
なので、吉岡さんがブログに書かれているこのエントリなど(たくさんある)について話をしたかったわけです。
・(Skypeでは話したことがあったけど会ったことは無かった)きょん(@kyon_mm)さんとも会えてお話して、Groovyをえらく薦められたり(笑)。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
何よりも(特にペアプロやってる時の)熱気というか集中力がすごかったです(後で写真見て余計に感じました)。
