私たちの t_wada になるメリット

となるわけですが、「私たちの t_wada さんになること」には非常に重要な意図があります。

t_wada さんとは

https://twitter.com/t_wada

主にテストを書くことの重要性を説いているプログラマーでありエヴァンジェリストのような存在です。

直接の面識はありませんが、 t_wada さんのたくさんのスライド資料はどれもとても参考になる優れたものです。

https://speakerdeck.com/twada

どのスライドも読みやすく、内容も分かりやすいので、プログラマーの皆さんは是非読んでみて欲しいです。

私たちの t_wada さんになる、とは

ここからはフィクションの話をします。

あるレガシープロジェクトの品質を改善するために１人がアサインされました。そのプロジェクトには、テストコードがありません。全ての修正は手動の目視でのテストで大丈夫か確認し、大丈夫だったらデプロイします。

そのプロジェクトの問題は、「リリース後に発覚する不具合が多い」ということです。

これはなぜか。そう。 テストがないから です。

人間の目や耳には限界があります。全てのケースを網羅できる人はいません（逆にエッジケースを上手に引く人はいます）。

人間がポチポチクリックしたり何かを入力してテストするにはとても時間がかかりますが、もしこれをコードが代わりにやってくれれば非常に高速にテストすることが出来ます。また、作り方次第では並列にテストしてさらに高速化することも可能です。

よく「テストを書くのは難しい。テストを書く時間があれば実装に回したい。」という話があります。これは半分正解で、半分間違いです。

テストを書くのは難しい場合があります。さらに言うと、難しいからテストが書かれていない可能性があります。

• 静的メソッドを使っている
• メソッド内で new でインスタンス化している
• 外部APIやデータベースに依存している

など、テストを阻害する要因はソフトウェア開発において非常にたくさんあります。これは、「テストを書けるように設計し実装されたものではないコード」によく見受けられます。

逆に言えば、 「テストを書けるように設計し実装出来るようにならないとテストは書けません」 。これはある意味真実です。もちろんモックやフィクスチャなどを使って複雑に結合したコードのテストを書くことは不可能ではありませんが、そのテスト自体が難しく、複雑なものになり、やがてそれは負債となってしまいます。ミイラ取りがミイラになってしまう事例は、結構あります。

さて、たくさんのスライドや本を読んだ A さんは、テストコードの様々な書き方を知っています。どんな風に設計すればテストがしやすいかもわかっています。

A さんのコードは、テストしやすく、見やすく、もちろんテストコードが書いてあり、チームの評判も良いです。バグも起こしたことがありません。

しかし、 A さんは新規プロジェクト開発のリーダーを務めるため異動してしまいました。残されたメンバーとコード、そして A さんが書いたテストコードは CI を回り続けていますが、カバレッジは段々と下がっていきます。

A さんがテストコードを書いていた部分に関しては修正を加えたらテストが落ちるので、 CI が落ちないようにテストコードをなんとか修正して Pass したものがマージされるので、バグが発生しませんでした。

しかし、それ以外の人が書いたコードにはテストコードが付属されていなく、結合が密で、副作用があり、コードレビューも大変なものになっていました。そちらの方ではどんどん不具合が報告されてしまいます。

テストとは、文化

「テスト」とは「文化」です。

これが非常に重要です。テストは黙っていても生えてこないし、テストに熱心なメンバーが１人いても、その人が書いた分のテストしか生まれません。つまり、 「テストはコードを書く全員が自然と書く仕組み」 になっていなければ文化として根付かないのです。

その文化に必要なのは 「人」 です。特に 「伝道師」 です。それが t_wada さんであります。

しかし、 t_wada さんも忙しい方ですから、わざわざお呼びして講師をしていただくわけにもいきません。

ではどうやって文化を作るか。つまり 自分が t_wada さんと同じになれば良い わけです。

t_wada さんは何か特殊な能力を持っているわけではなく、一介の人間です。であれば、模倣して同じように振る舞えば、同じような効果がチームに反映されるのではないかと考えました。

実録レガシーコード改善というスライドがあります。これは実際にレガシーコードと呼べる題材を、順序立てて改善していく手法を紹介しています。

私はこれの自分のプロジェクト版を作ることにしました。同じように順序立てて、実際のプロダクトコードに対してこのプレゼンを仕掛けようと思っています。

また、他のスライドも、みんなで読む会を開いてみたり、要約して紹介してみたりする予定です。

そうやって「私が伝道師になる」ことで、「みんながテストを書ける」文化を作っていく、この行動が非常に重要なのではないかと考えています。

今年のビックチャレンジはこの Become our t_wada です。