こんにちは、安井＠Aspacです。
Hidehiko AKASAKA wrote:
>>ペアプロ、テスト駆動開発を実践されている方に質問です。> 皆様
>>ソースコードで自然な責務に分割することは、訓練によって出来
るようになるの
>>でしょうか？
訓練はわかりませんが、わたしの周囲ではコミュニケーションに
よって実現している、と思います。参考になるか分かりませんが、
わたしの周囲でのやりかたを紹介します。
変更をラクにするためにどうするか？という観点から、
・まず、常に設計を複数人が把握している。
・「ほげほげクラス」と言えばイメージがだいたい一致できる程度
に、クラスの責務を明確にしておく。
・クラスの責務はコーディング中に、メンバー間でイメージを共有
しながら、洗練していく。
設計はホワイトボードで相談しながらおおざっぱに決めて、コー
ディングに入ってしまいます。コーディング中に出てくる疑問・問
題は、その場で相談して考えます。「この処理ってどのクラスに持
たせようか？」と考え相談することで、徐々に「自然な分割」に
なっていくように思います。
メンバーが「これが自然だ」と感じるのがよい設計だという、ニ
ワトリと卵みたいな話ではありますね。実際には誰かがリーダー
シップを取ってアーキテクチャ部分を設計してしまうことも多いで
すが、コーディングをしながら、より良い形になりつつ、メンバー
の認識も統一されていきます。
要は、人によって微妙に違う「自然さ」を、コミュニケーション
によってより一般的な形に洗練させていくというやり方、だと考え
ています。チーム全体で身につける、と言ってもいいかも。
# 書いてて、とてもすばらしいチームだ！という気がしてきま
# したが、実際にはそんなにスムーズには進みません (^^;
# 認識のズレや勘違いはしょっちゅうだし。作業を分担してひ
# とりずつで設計・コーディングをしていると、全体に品質が
# 落ちてくるし。
問いの「ソースコードのみで」という部分は、「否」です。ペア
プロ中なら空中や紙に、何人かいればホワイトボードにクラス図や
コラボレーション図やよくわからない図(笑)を書いて議論します。
モデルをつねに頭に描きながら考える人もいれば、ソースコードを
中心に考える人もいる、というのが現実のようです。
なお、今のプロジェクトは制御的な(ミドルウェア的な)ものなの
で、業務システムだとまたやり方が変わってくるだろうとは思います。
--
アジアパシフィックシステム総研 ソリューション３部 安井 力
http://www.asia.co.jp/ yasui@....jp
03-3985-3886 / FAX:03-3985-3778