見出し画像

TDDBC札幌2019 参加レポート / #tddbc #agilesapporo

tacck

2019年6月15日に開催された、「TDDBC札幌2019」に参加しました。

午前は和田 卓人(@t_wada)さんによる基調講演+ライブコーディング、午後から言語別にペアを作っての徹底的なTDDペアプログラミング、というとても濃い一日でした。

基調講演

こちらのスライドの内容をベースとして、お話いただきました。

序盤の内容の中で特に印象に残ったものを、自分なりにまとめてみます。

「動作するきれいなコード」がテスト駆動開発のゴール。
ただし、それを一度に達成するのはとても難しい。可能なのは一部の天才だけだろう。
一般のエンジニアが彼らと戦うためには武器が必要。そのために課題を「分割統治」して各個撃破をしていく。
ゴール自体も「動作するコード」と「きれいなコード」にわけ、順番に戦っていく。
「動作するコード」が最初のRed→Greenの流れ、ここを最短時間で実現する。「きれいなコード」がリファクタリング。
この「リファクタリング」こそがTDDにおいて最も重要な箇所。
世の中の多くのシステムで起きている「動くコードに触るな」という問題。これはリファクタリングの出来ない状態(テストが無い状態)が当たり前であった証拠。しかし、技術者はこれに技術で戦っていかなければならない。その技術こそテスト駆動開発。
ただし、リファクタリングには脱出条件が必要。
* 時間で区切る (例えば5分、10分、など)
* 数字で区切る (例えば実装したコードの重複数を1にしたら終わり、など)

ライブコーディング

次は、和田さんの基調講演中に行なわれるライブコーディングです。

正直ここはかなり魔法のような時間が続いていて、気がつくと終了時間をオーバーしてしまっていた、という気持ちでした。
こちらも、印象に残っているところをまとめてみます。

テーマはFizzBuzz問題。ルールは一見するとシンプルだが、手を動かそうとしてみると意外と詰まる箇所がある。それを見つけて分割し、各個撃破していく。それが設計であり、TODOリストへ書いていくもの。
設計の基準として「テスト容易性」を考える。
「プリントアウト機能」をテストするのは、できなくはないが言語による難易度の差も大きい。また、そもそもViewのような箇所は、テストを書いても(本来の目的と異なる理由で)壊れやすい。投資対効果の低い領域となる。そのため、そのような箇所には「ロジックを入れない」ことで、テストしなくても良いようにする。

一般に「Viewにロジックを入れない」理由が明確に表されているな、と感じました。

TODOリストを作成していくときに、まず問題文をテキストエディタ上で切り分けていく。この中で上記の「テスト容易性」を中心に実装順を考えていく。
TDDでは「実装しやすいもの」から実装する。
特に最初のサイクルでは、環境含めて「無」から「有」を生み出すものになるため、実装難易度を下げてサイクルを回すことに集中する。
TODOリストを作成し、整えるのは「設計」の活動。しかし、最初にやりすぎてはいけない。実装の手が止まったらまた戻って考える、考えたらまた手を動かす、というサイクルを作れば良い。
TODOリストを作る中で、言葉の粒度を気にしていく。同じことを言っているはずなのに使っている言葉が違う場合は、同じ言葉に揃える。また、言葉の裏に隠れた機能、をあぶりだしていく。

ここは、自分では今まで十分には出来ていなかった箇所だと感じました。
TDDでは、TODOリストも「リファクタリング」の対象、という印象を強く受けました。

テストコードを書く場合の順番。メソッドの中では「検証」から書く。検証がゴールであり、まずそれを明確にすべき。
ここで手が止まるなら、TODOを考えきれていない。再度TODOリストへ戻り考えを深めていく。
この時に、「具体的な値」で考えることが、設計に鋭い視点をもたらす。

この表現も、TDDにおいての独特な捉え方に感じました。Redは失敗ではなく、単に今の立ち位置(設計フェーズ)を表している、と捉えることで、開発の心理的安全性を高めるイメージが湧きました。

作りやすいコードより「使いやすいコード」の方が価値が高い。
TDDでは「先に使う」ことで使いやすさを考える。

「先に使う」ことにより、プロダクトコードの設計がそこで始まる、ということに繋がるイメージを持てました。おそらくTDDの導入をためらっている人たちのハードルとなるポイントだとは思いますが、だからこそ、やることに高い価値があるとおも思います。

そして、一旦機能を実装したあとからの流れ。

「三年後」にそのテストコードをまったく別の人が引き継ぐとして、そのコードを見た担当者は果たして「仕様」を理解できるのか。
従来の書き方では、仕様レベルの情報はテストコードから抜け落ちている。そのため、三角測量で書いたテストの要不要を第三者が判断できない。
論理的に重複しているが、それを判断する基準が書かれていないため。
現代においては、テストコードのメンテナンスコストも無視できない。
「テストコードをドキュメント」として育てることで、コストを下げることを考えていくべき。
そのためには、テスティングフレームワークの機能を使い、「テストを構造化」していく。これにより、テストリストが構造化されたドキュメントとして表現されていく。

ここまで徹底してドキュメント化していく、という発想を持っていなかったので、この流れは本当に圧巻でした。

最後のまとめ。

TDDを学びたい人は、実際に和田さんのライブコーディングを見てみるべきだと思います。ここに、和田さんの持つ知識・情熱・エネルギーが凝縮されており、とても文字では書ききれないです。

休憩

美味しゅうございました。

ペアプログラミング

午後は二人一組となり、TDDのペアプログラミングを行ないました。
お題は「整数の閉空間」を表現する、というもの。

オリジナルは仙台の井上(@i_takehiro)さんによるもので、今回はTAとしても参加いただいていました。(そして、後ほどのレビューでマサカリをいただきました。)

私は"JavaScript+Jest"でペアを組んでの参加となりました。
普段はPHP+PHPUnitで書くことが多いので、あまり触ったことのないものを選んでみました。ペアの相手もちょうど同じような感じだったので、同じようなイメージで話をできて、すごくスムーズにペアプロできました。

ペアプロの時間は、前半・後半と二部になっていて、前半のペアプロ後に一組レビューを受け、その結果も踏まえ引き続き後半のペアプロを行ない、後半でも一組レビューを受ける、という流れでした。

そして、我々のペアが後半のレビュー対象として指名いただきました。こういう場で「レビュー」と言われると心理的ハードルがあるかもしれないのですが、私は純粋に指名をもらえて「嬉しい」と思いました。

スクリーン寄りが私です。(和田さんのスタンドが見守ってくれています。)

構造化の仕方や、テストコード・プロダクトコードのメッソド名の付け方、粒度の揃え方というところがレビューの中の議論の中心となりました。
それぞれの考え方をお聞きしつつ、自分たちの中の考えを話し、そして井上さんに名前の付け方によるコードの流れ(まさにドキュメントとしてのコード)の意味についてマサカリをいただく、というとても実りのあるレビューとなりました。

自分がレビューを行なう場合も、これだけ充実感のあるレビューを行ないたい、行なえるように精進したい、と思える、本当に素晴らしい時間でした。

また、構造化の基本的な方向性(機能→意味→具体例という流れ)について、和田さんも同じ方向性でやっている、とのコメントもいただけた時は、心の中で少しガッツポーズしてました。

終わりに

和田さんによるまとめ、参考文献の紹介などを聞き、長くて短い、そして濃い一日が終わりました。

講演いただいた和田さん、仙台より来ていただいた井上さん、そして今回TDDBCを札幌で実現し運営していただいたスタッフのみなさまに、心からお礼を言いたいです。
本当にありがとうございました。

和田さんのTDDの講演は、ここ数年で本当にお聞きしたいものの一つでした。「テスト駆動開発」を読んでその思いがさらに強くなり、今年は道外でもなんとか行けないか、と考えていたため、札幌で受けることができて本当に感謝しかありません。

また、一緒にペアプロをやってくれたパートナーにも感謝します。最近は複数人でコードを書く機会がめっきりなかったので、本当に楽しくコーディングすることができました。
今回は懇親会に一緒に行けなかったので、ぜひ別の機会で飲みましょう。

昨年「テスト駆動開発」を読み、自分も何かやらねば、という思いから"Laravel+TDDの基礎を学ぶ"という記事を書いてみました。今回の経験を受けて、こちらはさらにブラッシュアップしていきたいと思います。

最後にみんなで記念撮影。

Togetterのまとめもあるので、そちらも読んでいただけると当日の雰囲気を少しでも味わえると思います。

おまけ

懇親会も楽しかったです！

サポート頂けますと、日々の学習や勉強会の運営に使わせていただきます！ありがとうございます！