TDDへの違和感をつかめた気がする

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

TDDダメかもしれんな。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

違うな。TDDとは違う手法が必要という事だなぁ。

wtnabe, yet another yak shaver @wtnabe

@kyon_mm 結局のところ、1) サイクルがあること、2) サイクルが重くなりにくいこと、が満たせるかどうかなんじゃないですかね。TDDは最も小さくて速いサイクルを実現するのに向いてる。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@wtnabe そのとおりです！ で、なんというか、TDDだとあそんでつくっていくかんじがしないんですよね。。。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@wtnabe 重要なのはすばやいフィードバックで、テスト駆動という考えかただと、あそんでわちゃわちゃつくっているときのようなフィードバックループはまわっていない。。。

YASUI Tsutomu @yattom

@kyon_mm @wtnabe あそんでわちゃわちゃ作るときは、TDDしないですね。単に動かしながら作る。動かすのにテスティングフレームワークを使うことはあるけど、できれば動いてる様子を直接見られる方法を使うほうが好き。

YASUI Tsutomu @yattom

TDDが効くのは、ソリッドなコードを資産として積み上げていきたいという意識があり、かつ、テストと並行した方がそういうコードが書ける人の場合。天才みたいな人ならTDDしなくていいと思いますが、多くの人は天才ではなくてたぶんTDDは有効。BDD的なアプローチも含む。

wtnabe, yet another yak shaver @wtnabe

@kyon_mm 1) 全体のループと小さいパーツのループを分ける、2) 全体のループを回すのを支援するツールを作る、を組み合わせるとよいと思います。人数がいるならこれらを並行にできるのでより強いです。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@yattom っていうのがTDDの限界なかんじ。いきいきとしていない。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@wtnabe ってなるじゃないですかーっていうのが、エンジニアとしてがんばりどころだなとおもったしだい。もっとよい手法があるはずだ。

YASUI Tsutomu @yattom

@kyon_mm 「設計通りに書け」「書き終えるまで動かすな」という世界にくらべるとだいぶいきいきすると感じます。いきいきって比較していいのかな？とは思うけど。コードに触れる人々がパターン試しながら解空間の探索するなんてのは、よい場です。でも、きょんさんの言うのはレイヤーが違うのかなって気もする

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@yattom レイヤーというより範囲がせまい。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

TDDとかAgileのこと好きでこじらせているので。。。

かわべ　たくや @kawakawa

興味深いコメントが続いてる。TDDを実装パターンとみるのではなく、設計パターンとみることで、設計と実装のフィードバックループが回せればとは思う。BDDに近いけどもっとフンワリしてるイメージ。 twitter.com/kyon_mm/status…

かわべ　たくや @kawakawa

ただ、DHHが言う通り「TDDは設計を悪化させる」という側面も否定できないので、悩んではいる。 基本は「作って捨てる」なんだけど、TDDをうまく使えればパターン化できそうなんだけど、なかなか捉えられない。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa そう。そういうことです。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa この1週間でSmalltalkをさわりながら、アレグザンダーのことをかんがえているわけだけど、いま自分がやっていることは2000年初頭から進歩していないし、最初の理想にたどりつけていないことがよくわかった。。。

かわべ　たくや @kawakawa

@kyon_mm ふっ・・・深い。。。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa ようやくベックやカニンガムやケイがかんがえていた状況をちょっとでも後追いできてきたなという気持ちです。。。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa 「TDDは(小さな)インターフェースや構造の設計」なので、「TDDはメッセージ、センター、間の設計はできない」という。前者にかたよることで後者がなされず、それを「設計を悪化させる」と呼ぶこともできるかも。 DHHとCoplienが上述のように思っているかはわからないですが。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa CRCカードとTDDはわけることができないプラクティス(センター)だったのではないのか。TDDだけをやってもベックがXPをうんだころの美しさは現場にはあらわれない。やらないよりマシだよねってなるけど、TDDによるフォースを調和できなくなってしまう。それがTDD is DEADの正体だったのでは。

かわべ　たくや @kawakawa

@kyon_mm そう！そうなんですよ！！ TDDでは直接、設計できないものがあるので、設計を悪化させるというのはわかるのですが、ただ、書かないと見えてこないことがあるのも事実だし、書かれたことは変更できるので、間接的にメッセージ、センター、間へ影響を及ぼすことが出来るのとは思うのです。

かわべ　たくや @kawakawa

@kyon_mm おぉぉ、判りやすいですね。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kawakawa ありがとうございます！すごくおそい気付きだったけど。。。

かわべ　たくや @kawakawa

@kyon_mm こちらこそ有難うございます！ 長年、捉えられなかった違和感の正体を、やっと見つけられそうな気がします。