先日、以下の勉強会に参加してきました。
まとめもあります。
社外の勉強会というと、以前に主催(というほど何もしてないけど)側で参加して以来でした。
学生時代は、大規模なイベントに足を運んで、そこで開催されているセミナーとかに参加したことがありましたが、アプリケーション開発のエンジニアとして働き出してから参加するのは初めてだったので「はてさてどんなものかしら?」という感じでした。
結果、めちゃくちゃ面白かったです! また機会があれば参加したいと思いました。
ただ同時に、よく Twitter などで登壇者側の人が言う「登壇しない立場で勉強会に何度も参加しても意味ない」みたいな言葉の意味も理解できました。
「参加して楽しかった!」で終わることがほとんどのパターンですよね。それを実際の仕事に結びつけて価値を出すのって、かなり大変。
なので、今回の勉強会で得たものをしっかりと仕事なりプライベートプロダクトに結びつけることが出来るまでは、他の勉強会は良いかなぁという感じです。もしくは、LT 枠で登壇するか。
当日のメモ
当日、勢いでメモったものがあるので、改めてまとめておきます。未来の自分のために。
テスト駆動開発は自習(写経)に向いている

- 作者: Kent Beck,和田卓人
- 出版社/メーカー: オーム社
- 発売日: 2017/10/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
t_wada 先生が翻訳された本です。
本の中にはコードが大量に出てくるので、写経するのに向いていると説明されていました。
今読んでる本が読み終わり次第、購入して写経したいと考えています。
設計をせずにテストから書き始める方法「ではない」
よくある勘違いのようです。
TDD というと「とにかくテストを書き始めることからスタート!」のイメージがありましたが、そんなことはもちろんありません。ちゃんと設計はしますよ、という話。
たくさんテストを書くことになるが、まずは小さいところからクリアにしよう
結果的には多くのテストコードが必要になりますが、その最終形ばかりを見てウッとならずに、小さいところから進めていきましょう。
ひょっとすると実は一番難しいかもしれないのは、大きい問題を分解して、順番を決めて、着手すること
うーん。これは TDD の文脈だけではなく、仕事など全般に言えることですね。
大きい問題は、どこから手をつけて良いか分からなくなり、モチベーションが低下しがちですね。
大きい問題を大きいまま解決できる人なんてそうそういないので、しっかりと自分が理解できる大きさにまで分解して、進める必要がありますね。
最初に文章として書いて、それをリスト化していく
これは面白いやり方だなぁと思いました。
自分がその機能に求めること、そのテストに求めることをまずは普通の(箇条書きではない)文章で書いていく。
その後、その文章を分解してリスト化していく。そして、そのリストにそってテストを書いていく。
ぜひ実践したいです。
コアロジックから優先的にテストを書いていく
MVC モデルの V などは、テストを書く手間がかかる割りに、賞味期限が短い(ことが多い)のです。
「全部のテスト書かなきゃ!」と思うことは多いでしょう。そして、全部書かないとなんか見栄えが悪い、ということもあるでしょう。
テストに理解のない人が周りに多いと、「なんでちゃんと全部書かないの?」と詰められることもあるかもしれません。
しかし、時間などのリソースは有限です。コストパフォーマンスの悪いテストコードをたくさん書くより、コストパフォーマンスの良いテストコードに集中していきましょう!
テストの内容を具体的にする(考える負荷を減らす)
「数値を文字列に変換する」ではなく「数値 1 を文字列 '1' に変換する」といったイメージです。
曖昧なゴールを設定すると、コードを書いているときに思考がブレてきて、考える負荷が上がってきます。
なので、より具体的なゴールに変更できないか、考え直すのが大事です。
意味のないテストが意味ありげに見えるのは問題
これは反省ポイントですね・・・。
なんとなく追加したテストとか、不必要に重複したテストとか、書いた本人は経緯を知っていても、他人は知らないことがほとんどです。
また、書いた本人でさえ、しばらくしたら忘れるものです。そうすると、そういったテストコードが、今度は全体の生産性を下げだします。
「このテスト、なんで追加したんだろう・・・? でも、あるから保守しないとなぁ・・・」となるのです。
自分の記憶が鮮明なうちに、不要なテストコードは大胆に削除しましょう!