牛尾でございます。
お役に立てるかはしりませんが、一応自分なりのご回答ということで。
>自然な責務(役割)に分割できたかどうかは、主観が入るために出来るようになっ
>たかどうかの判断のしようがない。だから回答をもらえない、ということかも。
自分はそんなたいしたオブジェクターでもないので、しっかりできてるかもよう
わかりません。が、before TDDとafter TDDの私を比べて見たいと思います。
#最近EclipseでTDD好き度がさらに向上しています。 :-p
>> ペアプロ、テスト駆動開発を実践されている方に質問です。> 皆様
>> ソースコードで自然な責務に分割することは、訓練によって出来るようになるの
>> でしょうか？
なんというか、大きなレベルで考えるのは図のほうが楽ですが、ある程度細かくなると
TDDのほうがずっと楽というイメージを受けました。図だけで考えていると、コードを
つくったことを想像するのですが、実際つくるとそんな上手くいかなかったことが
多かったように思います。
逆にTDDでつくっていると、「先にテストを作る」「少しだけ進捗する(fake it, make itなど）」
「少しだけリファクタリング」で、なんというか、複雑な問題を小さな問題に分割できる
ので、ブレが少ないですし（大きな問題は小さな問題に分割して考えるのは問題解決の
基本ですよね）、先にテストを作るので使用するイメージを体感しながら
責務を割り当てていけるので楽だなぁと思いました。自分のつくるコードのレベルも
他の達人の皆さんからみればしょぼいかもしれませんが、自分としては前より上手くなった
と思います。
これを書いているときにふと頭に思い浮かんだのですが、コードのみで考えると
概観をイメージしますし、図だけで考えているとコードをイメージします。
どっちのケースでもイメージを早く具現化できる方向にもって行くほうがいいのかな
ということをぼーっと思っています。要はできるんならその人にとって楽だったらいいのかなぁ。
と私は思います。
>ただやはり、「シンプル＝分かり易い」ものを作る為には、局所的な視点
>（コード）だけでは無理があるように感じます。
>実践されている方達も、必要性を感じたら、当然、紙やホワイトボードやCRC
>カードなどを使ってシステムを概観できる抽象度のモデルを考えるのだろうと
>思います。
>その辺については何か誤解がありますか？ > XPを実践されている皆様
アジャイルモデリングのアンブラーさんもいってましたが、アジャイルモデルでも
実装はTDDお勧めだぜ！といっていました。
私の場合は適当なので、モデルの概観を考えたいときは裏紙とかでさっとモデリング
することもありましたし（大抵は概念レベル）、オブジェクト図でお客様のデータを分析する
こともやったこともありますし、コンポーネントのことを考えているときはタイプ図を
書いたこともあります。ややこしいアーキテクチャ考えている時は（１、２回ぐらい
しかありませんでしたが）インド料理屋にストーリカードもっていって、そこで飯食い
ながらシーケンスを考えたこともありました。
＃普段はシーケンスはほとんど書きませんでしたし、上記の図を１日中かいてるなんて
ことはありませんでした。さっとかいて、さっとやるみたいな。
赤坂さんのおっしゃるとおり、コード（＋頭の中）で考えているときに「あーあかん、
まとまらん。」と思ったときにさっと書いている感じでした。また、一番最初は
やはり概観をさっと裏紙に書くことがおおかったです。ケースバイケースでした。
普通の開発のフェーズの線の方向とＸＰのフェーズの線の方向は９０度違いますが、
それを表すように、分析⇔設計⇔実装⇔テストみたいなのをダイナミックに行き来
する感じですね。
めっちゃ適当な意見でもうしわけありませんが、以上です。