|
プログラミングとか日常とかの覚書っぽいなにか
昨日は「TDDBC横浜 Second Season」があったので参加してきました。
今回TDDBCは初参加（勉強会自体2回目だけど）。もともと今回の参加枠が30人で、申し込みはどうやら倍くらいあったようなので、抽選に当たって運が良かった。 9時半受付で、ほぼその時間に現地に到着。場所は横浜駅西口から数分の位置にある株式会社アットウェア。 受付で参加費（懇親会と合わせて3500円）を払って、ネームプレートを書いて、とりあえず右後ろのテーブルの、扇風機の目の前の席へ。なんせ暑かったですから…。 基調講演 10時から開始。まずは、川西さん（@tosikawa さん）による基調講演。 『テスト駆動開発入門の入門』というタイトルでしたが、このタイトルは「テスト駆動開発の「入門の入門」」という意味ではなく「「テスト駆動開発入門」の入門」なんだそうです。つまりTDDのバイブルともいえる書籍『テスト駆動開発入門』（ケント・ベック著）の入門。 川西さん曰く、TDDやってる人とは、『テスト駆動開発入門』の写経をした人のことだそうです。たとえTDDのやり方で開発していようが、『テスト駆動開発入門』を読んでいようが、『テスト駆動開発入門』の写経を写経をしたことがないなら、その人はTDDやってるとは言えない！とかなんとか。私も読んではいるけど写経したことないんで、一からやり始めないと。 講演の内容としては
私が前にこの本を読んだときに「まえがき」とかちゃんと読んだかどうか怪しいものですが、読者をこの本に（すなわちTDDに）引き込むための部分だけあって、実は大事なことがまとまって書いてありました。 出だしの「動作する綺麗なコード」がTDDの目標であり、この一文がすべてを物語っています。 その「動作する綺麗なコード」を書いていくための具体的な説明や方法が Part I やら Part II やらにまとまっていたわけです。今回の基調講演を聞いて、もう一度『テスト駆動開発入門』を読み直そうと思った次第でした。もちろん今度は写経も含めて。 これまでTDDBCは、和田さん（@t_wada さん）が基調講演を行うことが多かったようですが（私もWeb上にアップされてるTDDBC基調講演の動画や資料を見たことがあります）、今回のように他の方々が講演をできるようになってきてくれてうれしいと、和田さんもおっしゃっていました。 ペアプロ・TDDデモ 基調講演の後は、「ペアプロ・TDDデモ」。 実際にペアプログラミング＆TDDで今回の課題のステップ０の部分を進めていく様子のデモンストレーションを見ることができました。 TDDで重要なのは、道筋を考えずにいきなりテストコードを書き始めようとすると、1歩先は見えているけども、さらにその先が見えておらず、結果的に間違った変な方向へ進んで行ってしまうという可能性がある（1人でTDDやると場合は特に）。従って、あらかじめTODO的なことをテストリストとして書きだしておいた方がよいのだそうです。 テストリストを作成していく際には、まず最初に課題を上から順番に見ていくのではなく、課題のなかからもっとも単純な動作を探します。例えば、今回の自販機の課題（ステップ０）の場合は「投入金額の総計を取得できる」の部分。特に、「何もお金を入れていないときの総計が0円」というように。 また、小さなステップで進む場合、テストケースが通るようなべたな実装（「仮実装」、単に0を返すだけのような）を先に書くようにすることで、テストコードに間違いがないかを知ることができるのだそうです。仮実装でテスト結果がレッドになってしまった場合、テストコードの方が間違っているのです。もし実装を書いた後にテストコードが正しいことを示そうとすると、多大なコストがかかってしまうようです。 その他の着目点、注意点としては
昼食 ペアプロのデモの後はお昼ご飯。 お弁当が準備されていました。あまり好きじゃない梅干しが……この時期は暑さで傷みやすいので、それをある程度防止するために梅干しを入れるってのは常識ですかね。食べれないほど嫌いというわけでもないので、いただいておきました。すっぱい！ TDD＆ペアプロ実践 午後は実際に他の参加者とペアを組んでTDD＆ペアプロ実践でした。 1時間半くらいのTDD＆ペアプロ実習の後、どれかのペアのコードレビューを30分（15分×2ペア）というセットを、休憩をはさみつつ3セット。3回目の直前で、ペアの交代なども行いつつ。 今回C++で参加してたのが私と大鷲さん（@aetos382 さん）だけだったのでペアの交代はありませんでした。 課題の内容は以前のTDDBCから同じものが使われているらしく、英語に困らないように仙台02の時点で用語集まで作られてるらしいです。 C++選択しておきながら、C++用の環境構築のページに乗っていたPCUnitはダウンロードしておいたもののビルドとか試していない状態でした…。あと、いつの間に追加されたのか、GoogleTestの環境構築の説明が知らないうちに追加されていました…（前日に追加されたらしい？） なので、ペアプロは大鷲さんのPCを使ってやることに。彼のPCはWindows 8 (RTM) とVisual Studio 2012を入れてるらしい。これはこれでいい！と思いました。Visual Studioもスムーズに動いてるし。 リビジョン管理はMercurialを使うことに。その場でTortoiseHgをインストール。 ひとまずローカルでリポジトリを作って開発を進め、あとで共有できるようにしてもらうことにしました。 私達のペアは、紙にテストリストを書きだしていって、それをもとにテストケースを作っていくという形を取っていました。ただ、なにぶんTDD初心者同士ということもあって、デモで見たものと比べてもちゃんとしたものが書けていなかったように感じてしまいますが…。デモでは型をどうするかとか言うことも含めて書いて言ってたと思うんですが、私達は口頭で確認した程度になってしまった…。 途中他のチームのコードレビューも見てると、言語ごとにテストコードの書き方に特徴があっておもしろいと思いました。そして、うちのチームの進み方はちょっと遅いのでは……などということも。 自分たちの発表時にTAの方の話によると、同じことをしようとすると、C++は他の言語と比べて開発のスピードは遅くなりがちなんだそうです。「でも実行速度は他のどれにも負けません」などという話も。まあ、この辺はコードの作り方にも左右されるので一概には言えないんでしょうけどね。 コードレビューは言語ごとに1ペアが発表だったので、C++の唯一のペアである私たちは必然的にコードレビューをされるペアとなりました。5ペア目（3回目のコードレビューの最初のペア）の発表だったので、最初の2回のレビューのなかで私達に足りていない部分など気づくことができました。 そんななか、「無効なお金（1円玉とか5円玉とか）をお釣りとして出す際に、投入後すぐ出すのか、購入後のお釣りと一緒に出すのか」という議論があり「ならば『お釣り受け』を作って、投入時に無効なお金がそこに入るようにしよう」という方針にまとまりました。他の発表済みペアのなかではそのような考え方を取っているところはなかったようなので「これはいい考えだ！」という感じで。 ただ、その方針が決まったのはすでに3回目のペアプロ実践の時間になってからで時間がなかったので、とにかく最初にその方針をテストリストにまとめてしまおう！ということで、テストリストをつらつらと記述。 そして、それを1つ1つテストコード作成＆実装、と進めていきました。 実習中に書いてきたテストリストやメモ書きはこんなの。 コードレビュー時の発表については大鷲さんにおまかせしちゃいました。 最後に決めた方針がよかったおかげで、進み具合は他のペアと比べて遅かったにもかかわらず、受けはとてもよかったようです。 今回の私達のペアの成果を大鷲さんがbitbucketにリポジトリをアップしておいてくれました。 https://bitbucket.org/aetos/tddbc_yokohama2/src/9af7a916e3e9/TDDBC_Yokohama2_GoogleTest ……ええ、 Commit 146743418a69 見ると分かるように、肝心のファイル（VendingMachineクラスを定義してるファイル）を最初にaddするのをすっかり忘れてて、変更履歴が残ってなかった……これは痛い、ホントに残念。最初に環境丸ごと（すでに存在した .obj や .exe も含めて）リポジトリにつっこんでしまっていたので、VendingMachineクラス以外のソースを変更していなかった場合でも変更ありとして認識されてしまい、気づくことができなかったようです。コミット時にもっとちゃんと確認していれば…。
教訓： git や hg では status の確認も大事
質問コーナー TDD＆ペアプロが終わった後は質問コーナー。 分からない内容も多く、聞き逃してしまったものも多いです……。多分誰かがブログとかでまとめてくれるに違いない。 Q．コードが変わったらテストを直さないといけなかった。しょうがない？
Q．JUnitでRSpecのように機能で分類する方法はある？
Q．シナリオ的なものはどこまで考えるべき？
Q．TDDでテストを書く順序について。課題のステップ０でお金を入れる／入れない、合計／釣り銭の組み合わせで何通りもできるが。
Q．TDDをEclipseでやるときのおすすめテンプレートなど
Q．Git Commitのタイミングはいつ？
Q．納期に間に合わない！テスト書かないとダメ！？
Q．テストを書かない人を戒める方法を知りたい
Q．実装するときに気付いた新たなTODOの管理方法はありますか
振り返り (KPT) とまとめ 質問コーナーのあとは振り返りの時間。各自、KPTを付箋に書いて貼り出し。私が書いたのはこんな感じ。
他の人もいろいろ思うところを書いていたようです。
かつてのTDDBCではt_wada賞というものがあって、最近はなくなっていたらしいのですが、それを今回復活させたらしいです。 そしてなんと、私達C++のペアが t_wada賞をいただくことになりました…！ 賞品として『Gitポケットリファレンス』をいただき、大鷲さんとのじゃんけん決戦の末、私がいただきました！ 和田さん、ありがとうございました。 TDDBCなのにTDD関連の書籍じゃなくてGitリファレンスなんだとか、使ってたのgitじゃなくてhgじゃんとかツッコミがありそうな気がしますが、そこはキニシナイ。 最後に全員で写真撮影。 たまたま、懇親会用のビール配達してくれた人にカメラのシャッターお願いして、全員集合写真となりました。 懇親会 その後は懇親会。 ピザ、おいしかったです。ピザでおなか一杯にして帰りました。 LTもいくつか。お酒入ってる状態だったのであまり詳しく思い出せそうにないかも。この辺りはだれかがまとめてくれると期待。 懇親会でのLTやその他で印象に残っているのは
感想 今回のTDDBCでは非常に学ぶことが多かったです。 特に、ペアプロのやり方がさっぱりで、ペアプロってそもそもどういうものよ？って状態だったので、それを実際に体験できたのが大きかったです。また、TDDの進め方、テストを書いて仮実装して、またテスト書いて本実装して……というタイミングを学べたのも大きいです。 今後はどうにかして業務に取り入れていくことができれば…という状態。 ペアプロはちょっと難ありですが、TDD自体はこっそり自分だけ進めていくことも可能なので、それで効果を実証して他の人にも勧めていく、という方針を取っていきたいところです。 最後に、TDDBCを開催し指導してくださった和田さんや川西さんをはじめとするスタッフの皆様、私の不甲斐なさで迷惑を書けてしまっていたかもしれないペアの大鷲さん（@aetos382 さん）、そして他の参加者の皆さんに、お礼申し上げます。ありがとうございました。 リンク（現時点での参加者のブログ投稿とか） Togetter - 2012/09/01 TDD Boot Camp 横浜 Second Season #tddbc http://togetter.com/li/360406 TDD Boot Camp 横浜 Second Seasonにスタッフとして参加してきた #tddbc - Shinya’s Daily Report http://d.hatena.ne.jp/absj31/20120901/1346573746 TDDBC横浜 Second Seasonに参加してきた - 全力で気まぐれ http://d.hatena.ne.jp/STAR_ZERO/20120901/1346514990 TDDBC 横浜 Second Season でした - @yujioramaの日記 http://d.hatena.ne.jp/yujiorama/20120902/1346517108 参加者集合写真（@setoazusa さんのツイート） https://twitter.com/setoazusa/status/242091049806356480 TDDBC横浜2nd/記録 http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd%2F%E8%A8%98%E9%8C%B2 TDDBC横浜2nd/KPT http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd%2FKPT
PR 
|
プロフィール
ＨＮ：
はむぱい
職業：
ソフト作ったりしてる人
Twitter
カテゴリー
最新CM
[06/09 replica rolex oyster perpetual datejust]
[06/09 bracelets imitation cartier love]
[06/09 replica the oyster perpetual datejust]
[06/09 datejust rolex oyster perpetual]
[06/09 replica gold love bangle]
カレンダー
ブログ内検索
あ～いい漢字
|
