TDDの真の目的は健康
TDDの真の目的は健康だそうです。ここでいう健康とは、1つはコードの健康、もう一つはチーム（人）の健康とのことでした。
変化に対応できるのは健康体のコードであり、外的要因での変化に対応できるのは健康体のチームだと述べていました。
事例、応用
精神的な話ばかりではなく、現実の話として、TDDの導入事例と応用編へと話は進みました。
MS、IBMなどのTDD導入事例を引き合いに出し、TDDを実施すると、ざっくりとバグは半分になり、実装時間は2割増しといえると語りました。また、実装は2割増しになるのですが、デバックにかかる時間が圧倒的に減るため、まったく読めないデバッギングの時間をほとんどなくすことができ、結果、全体の工数が減るというのも見逃せない重要なメリットであるとのことでした。
応用編として、テストのないコードや、すでにデータの入ったデータベースがあるケース、テストが脆い、遅い場合にそれに対処していく方法として、三冊の書籍が紹介されました。
さらにもう一冊、モダンTDDの本として、ケントベックのテスト駆動開発入門に続く、二冊目のTDDのバイブルになりうる本も紹介されました。
以下に言及された書籍を紹介します。
- 『レガシーコード改善ガイド』
- 『データベース・リファクタリング』
- 『xUnit Test Patterns』
- 『Growing Object-Oriented Sowtware,Guided by Tests』
- 『テスト駆動開発入門』
この先生き残るために
自分の書いたコードに対してテストを書くということがプロとしてのたしなみです。少しずつ、後からでもいいので、テストを書いていってもらいたいと述べられていました。
また、たくさん本を読むことを勧められていました。その勉強方法としては、写経することが良いそうです。写経とは、本に書いてあるサンプルコードをひたすら書き写していくことです。和田さん自身、最初にマスターした本は写経して、読んで、初めて深く理解できたそうです。具体的な技術書の写経方法については、和田さんのツイートをご参照ください。
最後に
「今日、何か1つを覚えて帰るとしたらTDDと黄金の回転です。黄金の回転こそが駆動の力を与えます。テストやTDDはスキルです。才能ではなく習得可能なものです。量は質に転化します。写経しましょう!!」と、力強いメッセージで話を結びました。
