テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる

「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。

「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。

テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用

セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。

f:id:yach:20220212100829p:plain

絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと(Validation)は、いずれも動作する様子を現しますが、大きく異なった観点です。仕様書とコードに乖離があったり、クラッシュするようなバグがあったら、Verificationの観点から「動き」ません。ユーザーにとって使えなかったり、資産を毀損するような重大な仕様の穴があったら、Validationの観点から「働き」ません。

そう考えると、動作するきれいなコードは書いた通りに動き、期待通りに働き、同時にきれいでなくてはならない。

TDDは主に開発者やプログラマーの活動です。しかし動作するきれいなコードに関心を持ち、実現したくなる他の種類の人々もいます。顧客、クライアントは働くコードを求めます。テスターやQA担当にとって、動くことが確認済みのコードはありがたいものです。コードを書いた本人以外のプログラマーは、安全に作業できるきれいなコードを好みます。

レッド・グリーン・リファクタリングのサイクルを回しながら、コードが動作する(Verified)かつきれい(Clean)であるようにするのは、プログラマーです。プログラマーがさらに、期待通りに動くか判断できる(Validated)、すなわち今書いているコードの受け取り手の立場にたって判断できる場合もあります。しかしこの判断には、プログラマー以外の人にも関わってもらうべきです。そのことを念頭に置き、図に3種類の人々のラベルを追加しました。開発者、顧客、QA(テスター)です。

f:id:yach:20220212100910p:plain

こちらの図では、人による価値の置き方の違いが見て取れます。プログラマーはコードが動き、きれいであるよう望みます。QA(テスター)はコードが動くことと働くことの両方を検証、確認します。顧客は働くコードを求めます。きれいなコードは顧客にも間接的に価値をもたらします。顧客としては、コードのきれいさには興味がないかもしれませんが、低コスト・短期間で追加変更できるのは嬉しいはずです。変更が安全かつ容易なのは、きれいなコードの特性です。

下側の2つの円が、プログラマーがTDDサイクルで重視する部分です。同時に上側の円、コードが本当に働くかどうかも重視すべきですが、働くか確認(Validate)できる人の助けを得なくては、動作するきれいなコードにはなりません。それぞれの立場の人々がお互いに助け合い、協力して動作するきれいなコードを追求する。その必要があると思い出すのに、この図が役立つよう願っています。

それぞれの立場の人が、TDDのサイクルを越えて一緒に働くわけです。あるいは、TDDサイクルの中で、一緒にモブプログラミングするのはもっと素晴らしいと思います。

この図はワークショップでも、「動作するきれいなコード」にまつわる活動や作業を見つけるために使えます。3つの円を大きく描いて、それぞれ「期待通り働く」「書いた通り動く」「きれい」とラベルをつけます。思いつく作業やタスク、活動、アイデアなどを付箋に書いて、3つの円の当てはまる場所に貼ります。円には重なっている部分があり、ここに付箋を貼れば2つ、3つの円に関係すると示せます。そうして、足らない部分を見つけたり、違う立場の人どうしが協力する仕方を話し合ったり、自分たちの「動作するきれいなコード」を定義したり、改善のアイデアを出したりと、なんでもやりたいことをしてください。

f:id:yach:20220206111449p:plain

さて、この図を示したところで、少しばかり懸念があります。3つの円、働く、動く、きれいという3つがすべて重要だと示しているつもりではあるのですが、人の役割を書き込んだことで勘違いが生じてしまうかもしれません。たとえば、「自分は開発者なので「期待通り働く」かどうかは気にしなくてよい」と思われては、本末転倒です。そうした間違いを避けるため、矢印を2本足した次の図を作りました。

f:id:yach:20220212102158p:plain

正直なところ、この矢印がなにを意味するべきか、まだ自分の中でもまとまっていません。たとえば、こんなふうに言えるとは考えています。

  • 開発者は動く・きれいに責任を持つが、働くかどうかも気にしたい。そのためには顧客と会話したり一緒に作業して、顧客を理解し顧客視点を得たい
  • QA(テスター)は開発者と積極的に関わるとよい。そうすると、開発者がコードをきれいにする考え方を知り、そこからテスト容易性に結びつけたり、テスト観点を見直したりできる

これ以外にも解釈や洞察があるのではないかと思います。この図の矢印について、思いついたことをコメントなどで教えていただけると嬉しいです。もっと言うとここで紹介した図についての感想やコメントもぜひお願いします。