TDDに必要なスキルについて考えた

っていうことで、TDDの前方依存と後方依存を技術的、ストーリー的に考えたものがあったので自分なりに考えてみた。
つまりはこのブログにたいするカウンターというか感想
「TDDの前方依存と後方依存 - pocketberserkerの爆走」

なかやん(id:pocketberserker)のブログにおける前提

まず先のブログに対する僕の解釈
大前提として、TDDの原則を守ることにおいて先のブログの前方依存や後方依存は多すぎる。
これはアジャイルの原則と似ているのもあるんですけど。

つまり、@pocketberserkerが言いたいのは「よいTDDをするための依存関係」だと思う。
でも、それだけでもおおい。
もっと広いことについて言っている。
たぶん「よいソフトウェア開発をするときのTDDが関わる依存関係」を考えたのだと思う。

であるとして、あの中身には技術的とストーリー的となっているけど、あれはどういった視点での分け方であるか微妙ではあると思う(言いたいことはわかるんだけど
なんというか、「みんなこう開発しているに違いない開発モデル」が透けてみえますです。
その上でストーリーに分けられているのは「きっとこう呼んでいるに違いない開発工程」てきなものというか。
でも、工程として呼んでいるかどうかじゃなくって、単純にシナリオかどうかっていう話だともうすこし分け方が違うと思いましたん。
逆に工程だったら工程だよって言ってもらえるとうれしかった。

※あとここでふれているTDDってユニットテストに限られているような気がする。

ブログの中身を言い換えると

ここからは僕自身の考え。
つまり、なかやんが考えてくれたのは彼なりの「最高のTDDを回し続けるための必要条件」なのだと思う。
とてもいいなって思いました。
僕自身は「これが原則だよ」っていうよりは「これが原則、ここまでが影響範囲、これがリファレンスモデル」って言ってもらえると勉強するときにすごくすごく役にたちます。
僕もこういう視点で自分が話す内容をまとめられるようになりたいですね。(←自分で探すときはよくやっているのになー

依存関係自体の妥当性

TDDは実際にはプログラミングをするフェーズを言っているので、つまりはそれに関わることは全てここに集中するでしょう。
ってなると、ほとんどのソフトウェア開発活動がTDDにかかわりますよね？
あえて言えば、「なぜプログラミングに必要ない活動をソフトウェア開発でやっているんでしょうか？」
むしろ、やっているならそれはいらない作業じゃないかなって思います。(アジャイルマニフェストすぎるかな？まぁ僕も常にやれているっていうわけじゃないけど。

僕はドキュメントとかで設計することも立派な設計行為だと思っているし、それはやっぱりプログラミングに関わってくると思います。(本当に意味のない無駄なドキュメントとかを除く。

それだと話は続かないので、その中でも特に重要と考えられるのが「実際にコードを触る場面」での必要条件。
僕的に分けると

プロダクト/テストコードを設計実装するスキル
調査するスキル
ブレークダウンスキル
インテグレーションスキル

※ブレークダウンはタスク分割する部分としない部分(ルーチンにする部分)の判断とか。インテグレーションはマージ実施とかフェイルファストの促進とか。

これらにどんなものが含まれるのか？それは「どんなTDDをしているのか」によってしまいます。
目的から言うと「○○を達成したい。ゆえに○○なTDDをするとよさそう。それには○○なスキルが必要になる」って感じ。
網羅的なテストのためにVOTDDをしたいのならソフトウェアテストスキルがより重要になりますし、
顧客の要望を反映したテストやタスク分割したインターフェース境界のテストのためにATDD系をしたいのなら顧客の要望が書き易いBDDのスキルだったり、DSLを作るスキルがより重要になるでしょう。

より具体的で網羅的に書くことはとても難しいかもしれないけれど、とりあえずはxUTPとかgoosとかレガシーコード改善ガイドとかリファクタリングに書いてあります。
こういったことを話しあってちゃんとまとめてみる勉強会があっても楽しそうですね。