もう2週間前になってしまいましたが、 2015/11/14(土) に TDDBC 仙台 5 を開催しました。もちろん一人でやったわけではなく、主催は @135yshr で、課題作成とマサカリ担当は @i_takehiro 、僕はその他雑用の主に3人で開催しました。
EXTENDED BODY:
今回の感想は2つのツイートに集約されます。
**TDD のエキスパート @t_wada と DDD のエキスパート @masuda220 が居るので、大変贅沢な勉強会になっている。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDDBC は座学とワークショップが一緒になってて、毎回新たな知見がある。俺得イベントである。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
詳細は当日の様子を自分のツイートを見ながら振り返ってみたいと思います。リアルタイムな流れは togetter を見ていただくと良いと思います。
会場は MEMBERS ウェブガーデン仙台
MEMBERS ウェブガーデン仙台さんの会場をお借りしました。ありがとうございました。とても綺麗な会場でした。
TDDBC 仙台 5 です！メンバーズ仙台さんに会場を提供いただいています。まだ申込み間に合います！ #tddbc https://t.co/rHXwIoyG8H pic.twitter.com/KwKLejmtP2— YAMAMOTO Masaki (@nnasaki) 2015, 11月 13
タイムテーブル
レビュー時間は思ったより、かかりました。次回はやはり見直さないとなぁと思った感じです。 (@i_takehiro のマサカリが冴え渡っていたのでとい噂も…)
今日のメニュー #tddbc pic.twitter.com/NDA8msvATi— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
和田さんについて
講師の自己紹介 #tddbc pic.twitter.com/gkOM27YpDF— いまいまさのぶ (@masanobuimai) November 14, 2015
和田さんの基調講演はやはり素晴らしかった
今回は頑張ってツイートしてたので、ツイートを元にふりかえります。
まず、TDDをしていない、自動化されたテストが無いときのリリースは「爆弾処理」のようなリリース。
爆弾処理のようなリリース #tddbc pic.twitter.com/bWItCkX3gP— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
一休さんのとんちみたいですが、
ストレスが増えるとテストが減る。自動テストが増えるとストレスが減る。テストを書く時間がないのではなく、テストを書かないから時間が無くなる。 #tddbc pic.twitter.com/G1LaRDguvE— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
我々が陥りやすい状況は設計を完璧にしてから綺麗なコードを書こうとすること。けれども、実装を始めないとわからないことが多い。TDDは動作する汚いコードから綺麗な設計を目指す。
動作するきれいなコードへの道は２つ。ひとつはソフトウェア工学としては左側の赤い道で、設計を完璧にして動かないコード。難しい。 ふたつめは、動作する汚いコードをテスト駆動開発でリファクタリングを重ねていく。 pic.twitter.com/NuZwCPcGio— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDDのサイクル #tddbc pic.twitter.com/18CXmNcajG— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDDと黄金の回転。黄金の回転については杜王町なので、常識らしい。 #tddbc pic.twitter.com/W2d907cruE— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
#tddbc 黄金の回転来ました。 pic.twitter.com/HWtX2HiHWK— いまいまさのぶ (@masanobuimai) November 14, 2015
実業務ではリファクタリングがおざなりになることが多い。リファクタリングというタスクが作られても、ビジネスの価値として提供するタスクでは無いため。リファクタリングを貯めると、大掃除が必要になる。大掃除は1日費やす。毎日やれば大掃除は必要無い。習慣化が必要。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
リファクタリングの教科書 #tddbc pic.twitter.com/l1bYs9Dnzg— YAMAMOTO Masaki (@nnasaki) November 14, 2015
Dustin Boswell の リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) を Amazon でチェック！ https://t.co/hVc7hPoYZB @さんから #tddbc— 135yshr (@135yshr) 2015, 11月 14
テスト駆動開発のスコープは赤色の部分。社会やビジネスに影響をあたえるわけではない。小さいスコープで頻繁に行うこと。 #tddbc pic.twitter.com/Fxx6eqOfHV— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
良いテストの原則。FIRST #tddbc pic.twitter.com/R6HTplsFs4— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
RepeatableとIndependentなテストをまず目指す。 #rddbc pic.twitter.com/hwqAikCGdk— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
テストのメンテナンスコストの現実。後々楽になると思ってたのに、気づいたら落ちるテストを直してばっかりいる。こうならないために、テストコードにもリファクタリングが必要。 #tddbc pic.twitter.com/Bt2tIfVYt3— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDD導入効果。 TDD導入後の Visual Studio は不具合は10%以下に減少、実装時間は20%増えた。導入前は大丈夫だったのかという疑問が… #tddbc pic.twitter.com/ihdCcOT2sa— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDD導入効果。だいぶポジティブ。 #tddbc pic.twitter.com/xhSuIQU3hm— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDD導入すると、デバッグ時間が減ってコーディング時間が増えるが、トータル時間は減る。TDD導入したことで良い結果があるが、SIerからするとポジティブな意見が出るかはビミョウ。
@masanobuimai マネージャー say 実装時間が増えている！テスト項目書をExcelで書いていない？自動化だ？ 1つずつ目で確認して、結果のエビデンスが無いとやったかどうかわからんだろ！俺の若い頃は…— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
誰が、何のためのテストか？テストの定義が対象者によって異なる。 #tddbc pic.twitter.com/sCrfEjOSKF— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
BDD は Spec 系と シナリオ系で二つの世界に分かれてしまい、 BDD という言葉は誤解されやすい。 #tddbc pic.twitter.com/qeLeJXl69j— YAMAMOTO Masaki (@nnasaki) November 14, 2015
TDD をするからテストエンジニアが不要となるわけではない。 TDD は Checking でしかない。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
アジャイルテストの四象現。 #tddbc pic.twitter.com/BFWbujwuo6— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
テストは品質を上げない。体重計に乗るだけでは痩せないのと同じ。品質を上げるためには改善（プログラミング、リファクタリング）が必要 #tddbc pic.twitter.com/zBPyzADfLB— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
なぜテスト駆動開発を行うか？工学的ではなく、最大の理由は心理的なもの。 #tddbc pic.twitter.com/qCGimXYBf1— YAMAMOTO Masaki (@nnasaki) November 14, 2015
人間がソフトを開発するんだし、人と人との協調作業が多いので、心理的な部分が大きいと思う。いまやスポーツでメンタルトレーニングするのは当たり前だし、その部分がソフトウェア工学で不足しているのかなぁ。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
今回の課題は格子点
Mr.TDD @i_takehiro の今日の課題解説。 #tddbc pic.twitter.com/OFH5yxNQlx— YAMAMOTO Masaki (@nnasaki) November 14, 2015
格子点っていってもピンと来ないかも知れませんが、方眼紙上に点を書いていく感じです。課題の詳細については、 TDD Boot Camp(TDDBC) - TDDBC仙台05/課題 をご覧ください。
今回も Mr.TDD & DDD こと @i_takehiro オリジナルの問題です。尚、当日は課題１までしか最初みせておらず、全体像がわからない状態で進んでいたので、もし写経する場合は課題1だけをみてやるとライブ感を味わえると思います。
お昼終わってペアプロへ
お昼は弁当を用意して、ペアプロに入ります。仙台の場合、ペアは主催者側でアンケートをもとに組んでおき、お昼ご飯を一緒に食べるようにしています。これは午後からペアプロをスムーズに行うために、コミュニケーションをとりやすくする試作です。
ちなみにお弁当は４種類用意していました。そのうちの1つはこんな感じです。
ロコモコ丼いただきます！ #tddbc pic.twitter.com/7coVFmUVK2— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
ちなみにペアプロ中はみんなTweetする暇がないので、Tweetがほとんどありません。
レビュー中にあったQ&Aに対する回答
ペアプロ中にちょっとしたQ&Aがあり、いつも情報が揮発してしまっていたので、メモしておきました。これはメモしておいてよかった。
Q: テストがすぐに壊れてしまう。どうすれば良いか？ A: 序盤はそうなりがち。終盤につれて徐々に安定してくるようになってくる。 #tddbc— YAMAMOTO Masaki (@nnasaki) November 14, 2015
TDDをやり始めたばかりだとクラスやメソッドがしょっちゅう変わるので、テストを直すのが苦になってくる。結局面倒になって辞めてしまうって事があると思いますが、やっぱり最初はちょっと辛い感じです。これを乗り越えてメリットが見いだせると、次のプロジェクトからも初期の苦労は耐えられる感じですかね。
Q: テストケースをREDにするつもりが、予想外にGREENになった。どうするべきか？ A: テストの不具合に早期に気づけてよかったと思う。そうなるとテストコードが信用できなくなり、テストコードのテストを書くのではなく、実装コードとテストコードで相互に担保させる #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
テストをREDになるつもりで書いたらGREENになった。というのは実装かテストに問題がある可能性が高いので注意すべき。
Q: x,y の2つの変数のテストを同時にするべきか？ A: 正解は1つでは無い。チームの熟練度とメンタルによる。自信があるなら2つ同時に行ってもよい。自信が無くなった時点でブレーキをかけて1つずつに別けても良い。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
テストケースは作った人の性格で、大胆な人と緻密な人で作る大きさが違う。上手く行かなかったり、迷った時は緻密(細かく)にした方が良い。 #tddbc— leecom (@leecom) 2015, 11月 14
三角測量は"どうやってリファクタリングすればいいかわからないとき”にやる #tddbc— 糖質警察 (@a_suenami) November 14, 2015
これは良い質問だった。テストを書く粒度は自分の自信により異なる。アクセルとブレーキで緩急付ける。これに関連する質問で次のQ&Aもあった。
Q: Getter の三角測量を行っているが、そこまで必要か？
A:
1.（テストの）重複をなくす目的。三角測量自体は2個行えば証明が成り立つので3つも4つも必要は無いかもしれない。
2. ケントベック自身も三角測量については奇妙だと言っている。(Tobe)どうなったらいいかわかるが、(How)どうやっていいかはわからない。必ずしも正しい方法ではない。ローギアな方法。
Q: 動的型付け言語は何でも渡せるから数値かどうかをテストでチェックすべきでは？ A: 人により異なるけど、そんなの一々チェックするぐらいなら、動的型付け言語使わなきゃ良いじゃん。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
String.format とプラス演算子どちらが実効効率が良いか？コンパイラが最適化するので、気にするな。可読性を高めた方がよい。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDDは個人でも出来る。では組織では？
懇親会でも話合ったQ&A。こちらも興味深かった。
Q: 自信という話が出たが、個人では無く組織の場合はどうするべきか？標準化とか？
A:
・TDDは一人でも出来る。でもそれは組織では…
・属人性の低い指標みたいな
・空手の型みたいなルールを決める
（example for アジャイルサムライ, jenkins通さないとリリース出来ない)
・Yahoo!なら黒帯みたいな段位とか
・実際にやってみて苦労したところ
・自信じゃなくて組織の場合、
・データとして見れる？
・Excelじゃないと通用しない
・元々そうだったけど、それを壊すために稟議を通して変えるようにした。
・アジャイルサムライ11というチームを作った
・ムリだと諦めてドロップアウト
・TDDの効果はすごいけど、今までとの指標と変わりすぎると組織にフィットしない
・防波堤になるマネージャー
・腹くくる
・LOCあたりの発生バグ数の指標とか
・プログラマー以外にもわかる定量的な指標を作る
・ねつ造…
・お客さんとの契約を準委任でアジャイルな開発
僕は組織に時間を使うなら、自分でやろうと辞めてしまった人間ですが、ちゃんと会社に稟議を通して出来るようにしたというメンバーズさんはすごいなぁと思った。
みんなクラス名に複数形使う？
「クラス名に複数形はあまり使わないですね。」「いや、私は使いますね。」「O/Rマッパーは複数形になりますね」「いや、O/Rマッパーにクラス名引きずられるのおかしいでしょう」「クラス名は集合じゃなくて、オブジェクトは集合を表せるけど…」 面白いなぁ #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
Q&Aじゃないけど興味深かったクラス名の付け方。ちなみに私はクラス名に複数形使います。
ちなみに複数形使わない派は和田さん。使う派は井上さん。マッパーにクラス名が引きずられるのがおかしいという指摘は増田さん。だったと思います。テストだけじゃなく、オブジェクト指向やDDDの知識が見えて面白かった。皆さんそれぞれ同じ本を読んでいるんですけど、それぞれが昇華してて考え方は異なる点もあるんだなぁと感じた。
ふりかえりはKPTで
ふりかえり中 #tddbc pic.twitter.com/CAnOnQL23d— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
懇親会もメンバーズさんの和室で
なんと会場のすぐ隣には和室があり、すっかり居酒屋気分で行いました。
membersさんの和室でガヤガヤ懇親会 #tddbc pic.twitter.com/BXbU8KXqHZ— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
あぐらでLTという斬新さ！トップバッターは @a_suenami さん！ #tddbc pic.twitter.com/AvNtEdc48I— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
@a_suenami さんの糖質制限の話で盛り上がる。TDD is 糖質駆動ダイエット**
.@t_wada さんはなぜか正座で LT 中。 #tddbc pic.twitter.com/qDbTEWL1Ut— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
なお、買い出しでセブンイレブンのお総菜を「これ全部」と大人買いしましたｗ
仙台名物その１ 主催者のコスプレ
主催者の @135yshr は毎回コスプレしており、今回は 5 と Go をかけて、go のマスコットである gopher 君をコスプレしてた。
.@135yshr による恒例のコスプレ。5回目なので、go言語のgopherらしい。ねずみ男ではない。 #tddbc pic.twitter.com/2zDbFAXXik— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
ちなみに本物の gopher 君。ちょっと厳しい…
[
和田さんとGopherコスプレ。 #tddbc pic.twitter.com/wAEesJA9Sd— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
仙台名物その２ @i_takehiro のマサカリ
仙台では Mr.TDD & DDD こと @i_takehiro によるコードレビューに対する素晴らしい指摘がいただけます。我々はこれをマサカリと呼んでいます。
言葉で書くより10秒のイメージ動画をご覧ください。すぐにわかります。
#tddbc 今日の記念にコース作った。 pic.twitter.com/0P4XdLUQb2— いまいまさのぶ (@masanobuimai) 2015, 11月 14
それでは、@i_takehiro のマサカリに対する反応をご覧ください。
#tddbc 仙台のコードレビューの様子です。 pic.twitter.com/f91MVplqEe— いまいまさのぶ (@masanobuimai) 2015, 11月 14
すっかり大人しくなった #tddbc タグをみて、きっと今ごろ @i_takehiro の素敵なコードレビュータイムを楽しんでいるに違いないと想像した。 pic.twitter.com/rb7XYSDzy2— いまいまさのぶ (@masanobuimai) 2015, 11月 14
@i_takehiro さん「はいっ」 会場「ザワッザワッ…」 #tddbc— 糖質警察 (@a_suenami) 2015, 11月 14
.@i_takehiro の マサカリキターッ！ #tddbc— leecom (@leecom) 2015, 11月 14
#tddbc 仙台のコードレビューのイメージ pic.twitter.com/8w3oH4Jqzb— いまいまさのぶ (@masanobuimai) 2015, 11月 14
止まらないマサカリ #tddbc— 糖質警察 (@a_suenami) 2015, 11月 14
@i_takehiro さんが口を開くと場がざわつくｗ #tddbc— minoru.oonuma (@numamino) 2015, 11月 14
エンドレスマサカリ #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
#tddbc 仙台のコードレビューは、こんな感じでほのぼのしてます。 #その場に居ない pic.twitter.com/ejzljMnOH0— いまいまさのぶ (@masanobuimai) 2015, 11月 14
t-wadaさん「いのうえさん、何かありますか？」 会場「（爆笑）」 #tddbc— 糖質警察 (@a_suenami) 2015, 11月 14
「他何か。質問とか…マサカリとか…」ｗ #tddbc— 糖質警察 (@a_suenami) 2015, 11月 14
突然ですが、ここで #tddbc 仙台の様子を念写してみましょう。 pic.twitter.com/IblFbvGGJh— いまいまさのぶ (@masanobuimai) 2015, 11月 14
#tddbc pic.twitter.com/hmcc2vHmFk— いまいまさのぶ (@masanobuimai) 2015, 11月 14
マサカリ対策で、一生懸命リファクタリングしました。 #tddbc— leecom (@leecom) 2015, 11月 14
「他の人のコードレビューで指摘があった部分を直して、マサカリを回避した。」 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
#tddbc みんなすぐ「 @i_takehiro がマサカリ投げた」って言うけど、あれは爪切りみたいなもんですよ。 pic.twitter.com/vLwBtfuRbe— いまいまさのぶ (@masanobuimai) 2015, 11月 14
「じゃあ、井上さんおねがいします」 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
今日の@i_takehiro いつもと発しているオーラが違った。こっちが本当の姿かと思いきや、まだ本領発揮していないらしい。いったい第何形態まであるのか。 #tddbc— setoguchi (@mixjuice001) 2015, 11月 14
まとめ
冒頭の2ツイートの通り。もう一度貼っておきます。
TDD のエキスパート @t_wada と DDD のエキスパート @masuda220 が居るので、大変贅沢な勉強会になっている。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
TDDBC は座学とワークショップが一緒になってて、毎回新たな知見がある。俺得イベントである。 #tddbc— YAMAMOTO Masaki (@nnasaki) 2015, 11月 14
次のステップ
我々は毎週木曜日に19時ごろから21時ごろまで、ソシラボ | 仙台市青葉区のコワーキング・イベントスペース さんにて勉強会をやっています。TDD 以外にも DDD や Go言語 の勉強会をやっていますのでお気軽にご参加ください。
たまにやっていない場合があるので、 TDD勉強会in仙台 - connpass のメンバーに登録していただくか、主催3名をフォローしてチェックください。
対象レベルは初心者からです。そのとき集まった人のレベルに合わせて行いますので、是非気軽にご参加ください。