f:id:kasei_san:20180224115428j:plain

ドーモ、社内ニンジャスレイヤー推進おじさんの id:kasei_san です。

先日、社内にてテスト駆動開発をお題に読書感想会を実施したところ、翻訳者の id:t-wada さんの目に留まり、なんと、id:t-wada さんをお招きして、第二回読書感想会を実施することになりました!!

素晴らしい取り組みだと思います。たぶんもう終わってしまったとは思いますが、御社内でまた『テスト駆動開発』を取り上げるときには、ぜひお気軽にお声がけください。
— Takuto Wada (@t_wada) 2017年11月29日

読書感想会とは?

技術書などチームが読んだ本について、知見や疑問を共有する会です。

詳しい解説と前回の様子は、こちらの記事をご覧ください。

どんなことを話したの?

テスト駆動開発の疑問や感想について id:t-wada さんに解説頂いたり、訳者解説で紹介しきれなかったことを紹介していただきました。

こちらは、その際のホワイトボードです。とても1Hとは思えないような、濃く知見溢れるお話を伺うことができました...!

f:id:kasei_san:20180224125233j:plain

その中でも、特に印象深かったトピックスを4つほど紹介いたします。

デザインパターンを知識として理解しているつもりだが、実践できていない。どうしたらよいか? という質問を解説いただきました。

デザインパターンはリファクタリングの途中で出てくるものなので、リファクタリングの勉強をした方が身につく というお話は目から鱗でした...!

パターンはリファクタリングの途中で出てくるもの
- 「コードの匂い」があった時の解決策がデザインパターン
- 例: 同じif文がコードの中に複数ある...! → stateパターン
デザインパターンを沢山覚えるのは辛いので、まずはTDD本にあるパターンから覚えると良い
パターン指向リファクタリング入門という本がオススメ
既存のコードが実装のテストをしてしまっており、リファクタリングがつらい。どうしたらよいか?
- 今あるものを分析してリファクタリングする必要がある
  - コストは高い。覚悟がいる
- 不要なテストは消す
- POODR本にあった 振る舞い、インターフェイスのテスト を意識する
  - 実装に近づけすぎない
  - 実装をたすけるテストを

ゴールのイメージが見えなくてもできる。むしろそのゴールに向けて細かく方向転換をしながら進むものがTDD とのことでした。

id:t-wada さんが「TDD本で倒せなかった話題」とおっしゃっていたのが印象深かったです。

ゴールのイメージが見えなくても、TDDはできる
むしろ、段々見えてきて具体的になるまで手を止めない
- メソッド名を書くだけでもよい
- そのメソッド名も途中で名前が変わる
実装して後からテストを書いてしまうと、方向転換ができない
TDDでは、最初にやると思っていたゴールと違う所につく
- TDDは、ゴールのイメージがはっきりしていないところから、細かく方向を変えて、ゴールに最短で辿り着く手段
テストを書くのは具体例を知るための手段
- 達人プログラマーの「曳光弾」