リンク

感想

会社で、「t-wadaさんのこの発表すごいよかったですよ」と聞いたので興味が湧いて再放送を見ることにしました。Findyさん、t-wadaさん再放送ありがとう…

特に個人的に面白かったポイントを書きます。

ソフトウェア開発の三本柱には優先度がある

ソフトウェア開発の三本柱は、Version Control, Testing, Automationの3つです。今回t-wadaさんが取り組んだコードはどれも備えていませんでした。優先度順に手をつけたいけどどこから手をつけるべきか。

ここでVersion Controlが一番優先度が高いのはなんとなく分かったのですが、TestingよりもAutomationが優先度高いというのは一瞬驚きました。ただ、「自動化は特にチーム開発においてレバレッジが効くので優先」という理由を聞いて納得しました。この後の流れを見ると、仕様変更やテスト駆動開発で何度も定型作業を繰り返すことになっていったと思われるので、確かに手作業を減らすことが開発サイクルを早く回すためにテストよりも必要そうです。

個人的に自動化が好きなので無意識のうちに自動化をしてしまうのですが、改めて自動化の意味、効果が大きい理由を認識できました。

初手で入れるテストはテストが入ることが重要なので、雑な正常系テスト1つで良い

最初に入れたテストが、「handlerのresponseがundefinedでないことをチェックする」だけだったのは驚きました。もっとちゃんとしたテストを入れるんじゃないのか！

これについては、「最初は軽くて良くて、自動テストが動くところまで持っていけることが重要」ということのようで、それを理解すると確かに最初は動くことが自明なテストを入れるのが正解だなと感じました。

学生時代に大学でTDDワイワイ会(TDDyyx)のイベントに参加したことがあって、その時も最初は「えっ、そんなテスト入れるのか」と思うような自明に見えるテストから最初のステップを踏み出していたことを思い出しました。

初手で入れるテストのハードルは一番低くして、テストが入ったという状態に最速で持っていくというのが大事なんだろうなと感じました。

テストを加えるために、コードに手を加える必要がある時の判断

ランダム性がロジックに入ってしまっているからテストを加えにくいというところで、接合部と呼ばれる、直接編集せずにプログラムの振る舞いを変えることのできる場所を探すという話がありました。
実際ガーッとコードを書くとロジックもりもりになるのでテストを加えるときにだるいなあとなってしまって結局個人開発ではテストを書かなくなってしまいがちなのですが、いい感じに切り出すポイントを探すことでテストしやすくする、それによって再現性のあるテストハーネスを整備できるというのはなるほどな〜〜耳が痛いけどそれはそうだよな〜〜と思いました。

この後のExtract or Sproutの話(全体を覆うようにテストを書くか、自分の変更を加える箇所だけを保護するテストを書くか)も含めて、どのようなテストをどこに書いていくべきか、それは何をガードするのか、という全体像が感覚でつかめたのがよかったです。

つらさの分析の言語化がすごい

リファクタしてなくて、SDKのdeprecatedも来て、仕様変更も来てウワー！という場面で、t-wadaさんがつらさの分析をしているのですがここの言語化が知識に裏打ちされたものを感じて個人的に面白かったです。

普通に僕だったら「単一のプロダクトコードに2つの変更要因が降りかかってくるのがつらい」という結論が降りて来なさそうです… ここに限らず引用された本のいくつかは積読していたので、そういった現状のつらさを言語化して次の一手を打てるように設計関連の本も読みたいモチベが出てきました。

終わりに

ストーリーに沿っていくつも大切な概念が登場すると頭に入りやすくてかつ楽しくてめちゃよかったです。t-wadaさん、Findyさんありがとうございました！

とりあえずClean Architectureの本を読むか… あと趣味プロジェクトにめっちゃ軽い正常系のテストを一個追加して、実装と間合いを取ったテストを書いたり接合部を探してテストしやすくするところからやってみようかな…