[社内勉強会レポート] 訳者の和田卓人(t_wada)さんと『テスト駆動開発』を読む会〜前編〜

「テスト駆動開発」読書勉強会

#勉強会

田中賢治

2017.12.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おばんです、主催する勉強会であるAKIBA.swiftの忘年会を、企画しておきながら当日風邪で休んだ田中です！でも田中という苗字の人は複数いるので会はつつがなく行われたようです！よかった！(でも行きたかった)

さて、本題です。最近社内で『テスト駆動開発』読書勉強会というのをやっています。(詳しくはこちら → [社内勉強会レポート] 『テスト駆動開発』読書勉強会 #1 ｜ Developers.IO)

この活動をブログにまとめていたら、なんとTwitterで訳者である和田卓人(t_wada)さんから、ゲスト参加したいと声をかけていただきました。

今回のエントリでは和田さんをゲストに迎えて行った、『テスト駆動開発』読書勉強会のレポートを紹介します。前編である今回は第一部と付録Cの内容について取り扱います。後編である次回は、訳者の和田さんが付録Cに込めた思いを紹介していきます！

会の趣旨

『テスト駆動開発』の「第一部多国通貨」と「付録C 訳者解説：テスト駆動開発の現在」の内容について、読み終わった中から残った疑問や、意図が合っていたかどうかなどを質問したり話し合う会です。

↑のような形で、リモートメンバーを含めての会でした！

話し合われた内容

目次です。

読者に考えさせ、背景を各自で想像させる中身だった
えっ、16章で終わっちゃうの？
コードメトリクスの意味
付録Cを書くに至った経緯
付録Cの構成
Testing vs. Checking
図 C.3の「ビジネス面」の軸が意味するところ
良い設計とはなにか？
TDDを人に伝える上で、どうすればうまく伝わるか？
「使いすぎてみて」少し戻ってくるくらいを繰り返す学び方

※以下和田さんのコメントについては、わかりやすいようにワイルド・サバンナにちなんで?をつけていきます。?のついていないコメントは筆者の田中や、会に参加したクラスメソッド社員の意見など

読者に考えさせ、背景を各自で想像させる中身だった

第12章「設計とメタファー」で自分だったらどんなメタファーを考えるだろうかとか
- もっと前段で、Money自体にplusなどの処理は最初からMoneyの責務でないので、別の役割を早々に用意していたとか
とにかく考えうるシナリオや、著者の意図を読み解くシーンが多くて楽しい本だと思った
多国通貨という題材がシンプルで良い例だったので、Java以外の言語で書いたときにどう書くべきだろうかとか
実際にいろいろな言語で写経をしている人がたくさんいて嬉しい?

えっ、16章で終わっちゃうの？

第16章「将来の読み手を考えたテスト」終了時の実装が、一区切りつく前に終わってしまっていることに対して。

あと1, 2章あれば第一部の多国通貨の実装がひとまず終わるところまでいけそうだったのに、なんでここで終わってしまったのだろうか！？
多分読者への宿題的なもので、自分も読んでいるとき「え、ここで終わりなの？」と思った?
これも憶測だが、本の分量の問題であったりもあるんじゃないかなぁ?
これまでも内容的に省略していた部分はあったし、宿題だとしても、ここまで読んだ読者なら解ける問題だろうと思ったので納得

コードメトリクスの意味

第17章「多国通貨の振り返り」 p.136「コードメトリクス」より。

振り返りでこの数字を出した意味はどういったところにあったのか？
この数値を元に、テストが足りていないのかもしれない、過剰なのかもしれないといったような指標を示したかった?
- たとえばクラス数を見れば、テストコードに対してプロダクトコードは5倍になっている
- たとえば循環的複雑度の行を見れば、プロダクトコードでif文が出てくるのはBankに使っている一箇所のみ。この数値がとても低いということは、オブジェクト指向をうまく利用しているコードだということを意味する?

付録Cを書くに至った経緯

「脚注を書くより、言葉と歴史をまとめた方が良い」という、編集の森田さんからの提案があって?

付録Cの構成

過去、現在、未来を書いている?
- p.296の「TDDからBDDへ」までが過去?
- p.300の「教条主義と意味の希薄化」が現在?
- p.304の「これから」が未来?
本当は「教条主義と意味の希薄化」までしかなかったが、「ここまでだとあまり救いがない気がする」として、編集の森田さんと相談して「これから」を書いた?
「これから」は若い人に向けた気持ちが強い。TDDに限らず、これからのエンジニア人生に広く捉えられる内容になっていて、エモさが強くなった?

Testing vs. Checking

付録C 「TDDのTは「テスト」の一部に過ぎない」(p.293)について

テストエンジニアが行う「テスト」とプログラマが行う「テスト」には違いがある?
- > 「テストとは、エラーをみつけるつもりでプログラムを実行する過程である。」(p.293)
- ここから読み取れることとして、本来のテストとは「プログラムがうまく動かないことを期待する」、プログラムを壊しにかかる行為である?
- 対してプログラマが行うTDDのアプローチはCheckingの意味合いが強い。これは「自分が書いたプログラムが書いた通りに動くことを期待する」、確かめる行為である?
- Testing = 「プログラムがうまく動かないことを期待すること」?
- Checking = 「書いたプログラムが書いた通りに動くことを期待すること」?
かつてTDDが流行ることによって仕事がなくなることを危惧したテストエンジニアがいたが、テストエンジニアが行う「テスト」とプログラマがCheckingのために行う「テスト」では意味が違う。なので仕事が無くなるということは杞憂である?

図 C.3の「ビジネス面」の軸が意味するところ

付録C 「TDDのTは「テスト」の一部に過ぎない」の図 C.3(p.295)について

ビジネス面は「ユースケース」、「インターフェース」、「機能要件」、「仕様」などと読み替えるとしっくりくる?
より下の軸にいくほど、非機能要件の意味合いが強くなる?

良い設計とはなにか？

TDDが良い設計を導いてくれる？
- TDD自体が良い設計に導いてくれるものではない?
- > 「TDDは、設計のひらめきが正しい瞬間に訪れることを保証するものではない。しかし、自信を与えてくれるテストときちんと手入れされたコードは、ひらめきへの備えであり、いざひらめいたときに、それを具現化するための備えでもある。」(p.83)?
- この話からTDDのRed, Green, Refactoringを繰り返し、常にCheckingし続け、ひらめくその瞬間までの最大の良い設計を保つことで、いざひらめいた時にすべてを崩してから構築するのではないことに気づいた。ひらめきがこれまでの実装とCheckingの地続きとなる状態で変更が行える強みがTDDにはある
- top down(設計 -> 実装)ではなく、bottom upな作り方(実装 -> リファクタ)をするTDDらしさがこの二文(上で示したp.83のフレーズ)に含められている?
良い設計とはなにか？
- 疎結合
- 再利用性が高い
- こういうプログラムはテストがしやすく、テストがしやすい設計になっていると疎結合で再利用性が高い良いプログラムになる?
- TDDでプログラムを書くにはテストしやすさ(テスタビリティ)が必要なので、自ずとある程度良い設計になる。TDDが強制ギプスになる例だ?
しかしRailsの例でみるように必ずしも良い設計が「疎結合」で「再利用性が高い」という枠に当てはまるわけではない
- Railsは開発の「速さ」をメリットとしているのに疎結合化することで開発速度を落として、そのメリットを殺すなら本末転倒となる(p.301)?
- 例えばサービスインを最優先にしたスタートアップ開発のようなものが挙げられる?
- 良い設計とはその時々によって変わるもので、目的から考えるべきこと?

TDDを人に伝える上で、どうすればうまく伝わるか？

チームで取り組んだり、仲間を増やしたいが、どうしたらうまく布教できるかがわからない
一番ハイリスクハイリターンなのはライブコーディング。百聞は一見にしかず?
あとは情報伝達効率もよいのでペアプログラミングがおすすめ?
過去に行った講演動画があるので参考になるかも?

「使いすぎてみて」少し戻ってくるくらいを繰り返す学び方

> 優れたプログラミングテクニックやパラダイムは「使いすぎてみて」少し戻ってくるくらいが良い塩梅です。(p.308)
ちょうど自分も設計やTDDに対してこの姿勢で臨んでみていて、過剰に信頼する、教条主義になるくらいやってみている(前のページで教条主義は否定されているが) <- 「使いすぎてみて」
その行き着く先として、「なにかうまくいかない」とか「もっとこうしたほうがよいのではないか」とか、「このシーンではこっちのやり方の方が良い」という学びで成長しているように思うようになってきている <- 少し戻って良い塩梅に落ち着く
とても共感できる部分だった