TDDとクオリティについてあれこれ

私の頭の中で、デミングのクオリティの強いこだわり, TDD, アレグザンダー系等のことが頭でぐるぐるしていることの整理のため描画を試みる。

TDDと品質ついてあれこれ。TDDが品質向上に有効であると、断言する自信は私にはない。 実証実験の方法がわからない、実験をやったことはないから。 が、メンテナンス性の読みやすさ、修正しやすさ、テストしやすさを上げようという意志をTDDの回転に感じてる。

TDDは 開発者とCodeの 関係性を深く考えさせる機会をくれる。1. Codeからどのようなこと何を感じたいのか？ 2. Codeから どのようなことを感じる形のCodeをつくりたいのか？の問いが頭の中で駆け巡る。
TDDの身体的ふるまいの中で、Codeを目でみたときの感覚、指でうごかしたときの感覚、声にだしてみたときの感覚、耳にしてみたときの感覚、メタファとしての不吉な臭いを感じる感覚、心に思い描く理想の Code 像を感じる感覚を研ぎすまし、Good な Codeの形に、一歩づつ近づいていく。
TDDにおいては、感じることは、とてもアクティブなふるまいだ。
TDDにおいては、良いこと・もの感じることと、良いこと・ものを感じるようにふるまうことは混ざり合っている。

TDDと死角

TDDの死角の１つは、使用性。TDDは、開発者とAPIの関係性を深く考えさせるのに寄与するが、エンドユーザとUIの関係性までは深く考えさせてくれない。テスト自動化の原則はむしろじゃま。プログラマがCodeを愛でるように、 ユーザがUIを愛でる感覚を研ぎすまし、意図が明確なUIになっているか、学習コストを考慮しているか、そのUIを愛用してもらえるか等に気を配ることが求められる。TDDの帽子を外し、別のUI系の座視を積極活用したほうがよいのだろう。

TDDの死角の１は、機能性。ユーザがほしい機能を満たしているかの判断は、TDD単独ではきつい。TDDの描画の中心的座視は、Developersで、Customersではない。何度かくらっている。

ATDD+TDDあるいはBDDから察するに、ユーザーストーリー、受入れテスト、ATDD等がもつCustomersの座視をうまく保持しながら、TDDのDeveloperの座視で記述していくのが基本スタンスであろう。

他にも色々書きたい（例えば、上の記述は、個人レベルのTDDの座視から離れていない。チームのTDDの座視は欠落している）が、ここで、思索をやめておこう。