tdd-in-net-5-638



















若干釣り?なタイトルで恐縮ですが、テスト駆動開発(TDD)の勉強会に参加して来ました。
(トップ画像はこちらからお借りしました)
「組織的にシステム品質を高めるためにどうすればよいか?」を考えていた矢先、ふとこの勉強会のお知らせが目に止まり、何かヒントが見つかるかもと参加した次第です。
メインスピーカーは、あのライオンで有名な、TDDのエバンジェリストである @t_wadaさん。
twada_savannah_lion













そのライブコーディングを見れるとあって、会場は超満員でした。

当日の内容はこちらからご覧ください。

実は講義に参加する前は「テストコードを書くことは有用だけど、工数が増えて費用対効果が合わないのではないか?」「結局最後まで保守仕切れないのではないか?」と思っていました。

ただ初めて実演を見てみて、TDDは実戦(つまり商用案件)で非常に効果的なアプローチであると感じました。TDDの全てはまだ理解しきれていないのですが、少なくとも現時点で感じていることは以下です。
  1. 目的と手段が明確に分離しており、アプローチの無駄が生じにくい。
    (実は実現しなくてもいい要件の実装を考えることほど無駄はない)
  2. 結果的に要件がテストコードに構造的に記載される形となり、コードの他者への継承が行いやすく、結果長く使えてメンテナンスがしやすくなる。
    (仕様書やコメントは結局書かなくてもコードはデプロイされるが、TDDではテストコードがプロセスに組み込まれており、書かないわけにはいかない)
  3. 作業が実現機能単位に分解されるため、進捗を計りやすい。
    (開発者がソースをコントロールしている(何が問題かを把握できている)状態を維持しやすい)
システム開発は要件伝達の生産性がボトルネックであるわけで、ビジネスサイドの人間がテストコード(の元ネタ)に近い形で仕様を検討して提示できたら、エンジニアリングはプロセス全体としてもっと無駄が省けるのではないかと思います。

TDD、是非弊社で活かしたい。勉強して考えたいと思います。

なにはともあれ、@t_wadaさんの軽妙でわかりやすい説明と流れるようなタイピングに見とれました。すごいエンジニアのライブコーディングって、エンターテーメントだと思いますね。