[2008 年 2 月号]
[突撃インタビュー]
1 月号の前編 に引き続き、 Rebecca Wirfs-Brock さんのインタビューをお届けします。 後編では、テスト駆動開発や、レベッカさんが最近興味を持たれている技術についてお伺いしました。また、若手エンジニアへのアドバイスもいただきました。
-- レベッカさんは、テスト駆動開発 (Test Driven Development、以下 TDD )を試されたことはありますか？
私は、設計工程でテストを実施するプロジェクトには関わったことがあります。ただし、テストケースを書くことだけを設計とみなして、それを最初におこなうプロジェクトに携わったことはありません。少しだけ設計をおこなってからテストを書く人たちとは仕事をしたことがありますね。
私の同僚に TDD の熱心な賛同者がいて、設計に関してよく議論になります。テストが設計を表現するものなのか、そうでないのかの間にバランスがあるんでしょうね。 私自身はテストが設計を表現しているとは思いません。テストは、コードの動作に対する期待を表現するものであり、設計そのものではないと思います。
2007 年の Agile Conference で、アジャイル設計者に対して、CRC カードやロールステレオタイプに関するチュートリアルを実施しました。 そこで、60 人ほどの聴衆の前で「プログラミングをする前に、CRC カードのような手法で設計やモデリングをおこなっている方はどれぐらいいらっしゃいますか？」と聞いてみたところ、三分の一程度の方が手を挙げられました。皆さん躊躇気味でしたし、半分ぐらいの方が後ろめたく感じているようでしたので、「OK 、大丈夫ですよ！ほとんどの人がやっていることです。けして悪いことではありません。CRC カードは、あなたの考えを助け、補完してくれるものです。また、設計をおこなったからといって、オーバーワークにはなりません。」と伝えました。
XP では時間をかけて設計することはアジャイルではないし、未熟な設計者のやることだと考えられています。 しかし、多くの人はたとえ簡単なものを作る場合であっても、実装する前に少し考える必要があります。しかも、そうした方がシンプルなコードを書くことができるのです。
-- 私は、最初にテストケースを書くと使いやすい API が設計できると思っています。レベッカさんは、これについてはどう思われますか ?
私は、API の契約を明確化することは非常に難しいと感じています。たとえば、メソッド呼び出しの引数を知っているだけでは、実際にメソッドを使うことはできません。設計者が設計上の制約を表現するテストコードを提供することは、実際の使用法を説明するためには良いやり方です。引数やタイプについての記述よりも、API を理解するためのテストコードのほうが表現力が豊かだと思います。 しかし、テストは最初に行うべきものなのか、あるいは設計後に行うべきものなのかについては、私には明確な考えはありません。順序は重要ではないと感じています。
純粋な TDD 論者の方であれば、「当然全てのテストを最初に書くべきだ！」と言うのでしょうね。彼らはテストをパスした際の緑のライト (*1) が好きだし（笑）。 Tektronix 社のエンジニア時代の最初の仕事が技術評価だったので、彼らの気持ちはよくわかります。 しかし、テストは仕様や要求を表現するものではありません。 使用方法を本当に理解していても、理解したことをテストで表現することはとても難しいと思います。
それから、私は、TDD の一部の熱狂的信者には賛同できません。Portland の あるユーザーグループ で、「全てのメソッドを public にすべきだ。そうすれば全てのメソッドをテストできる」「1 つでも private なメソッドが存在する設計は怪しい」という 議論 がおこなわれています。 確かに、メソッドを private で宣言すると、外部からはテストすることはできなくなります。 しかし、内部の詳細な処理をメソッド化しているときや、ロギングなどで継承やテンプレートメソッドを用いているときはオーバーライドされたくありませんし、アクセス可能であってはなりません。 しかし、TDD の純粋主義者は、「あぁ、仕事がすすまない。全てのメソッドのテストができない。だめじゃないか。」と言います。これは少し極端な考え方だと思います。
私がすべてを public にするとき、そのクラスを利用するプログラマや拡張のためサブクラスを設計する人のためであって、テストのためではありません。私はエクストリームな立場は好きではありません。(*2)
-- レベッカさんが最近興味をもたれている技術について教えていただけますか？
あら、私が興味をもっているものはとてもたくさんありますが、どれがよいかしら。 そうですね、 私はこれまで、ルールベース言語(*3) について学んできました。この経験から学んだことは、ルールベースのアルゴリズムに向いたデータの構造化技法です。 ルールベースシステムは、ある種の問題を解決するための興味深い技術だと思います。 ただ、多くの人はルールベースの使い方を間違っているように思います。何千ものルールを記述してしまっているからです。 ワーキングメモリの状態がシンプルになるようにデータ設計をして、ルールベースのアルゴリズムの利点を生かすようにすべきです。
また、もう古い技術かもしれませんが、オブジェクト指向データベースも好きです。人々が忘れてしまっている良い技術だと思います。あとは、時間のあるときに、Ruby や Rails を詳しく調べたいと思いますね。
-- アスペクト指向はどうでしょう？
アスペクト指向は、情熱を注ぐというほどではありませんが、数年に渡って興味をもっている技術の 1 つです。これまで私は、アスペクトの単純な利用方法ではなく、アスペクトを使った良い設計方法を見つけようと努めてきました。しかし、まだ答えを見つけることはできていません。
アスペクトは、限定された使い方をすれば便利ですね。 たとえば、アサーションや、永続化のためのシンプルな宣言のために利用するのは好きです。Java EE アプリケーションでは、Spring フレームワークの提供するアスペクト機能を使用しています。
しかし、最近はアスペクトで多くのことをやり過ぎる傾向があります。たとえば、アスペクト・フレームワークを使用してプログラミングを行っている人たちは、実行時に実際のところ何が起こっているのか把握できていないように感じます。これはあまりよくないですね。
-- 問題フレームはどうですか？レベッカさんの 「問題フレームパターン」の論文 を読んで、とても興味深いと思いました。
はい、私は以前から問題フレームに興味を持ってきました。 Michael Jackson さんの書籍 はすこし難しいですし、イベントやイベント内の現象を表現する状態モデリングに焦点を当てています。しかし、私は、問題フレームを使うと分析する時に正確な問いを立てることができることに興味を持ち、論文を書きました。本当におこなうべきことは何かを検討する必要がある設計者には、問題フレームはとても役に立つと思います。
ただ、問題フレームを人に教えるのは非常に難しいですね。だから、James Nobel さんや Paul Taylor さんと一緒に論文を発表しました。 去年、私はより多くの人が問題フレームに慣れ親しむことができるように、問題フレームのトレーニングを行ないました。また、Agile Conference でも発表を行いました。この時は、イベントやイベント内のモデリングをおこなうのではなく、問いかけをおこなったおかげで、皆さん、少なからず興味を持ってくれましたよ。
問題フレームをもっと理解しやすく、役立つものにすることが今の私の目標です。そのために書籍を出版するかもしれません。
-- 日本のエンジニアに良い設計者になるためのアドバイスをいただけますか？
良い設計者になるには、多くの設計を知ること、設計すること、誰かの設計をレビューすること、そして、設計について議論することが重要だと思います。 多くの場合、私たちは解決策を見つけることに集中してしまうため、設計について学ぶためにレビューしたり、議論したりすることを忘れがちです。 よい設計者になるためには、自分と同じ仕事をしている人だけでなく、異なる分野の設計や解決策を知っている人と議論するとよいでしょう。 多くの設計を知ると、設計の選択肢が広がり、設計判断が向上します。 私がよい設計者になれたのは、コンサルタントとして、良いものも悪いものも合わせてたくさんの設計と実装を見て、経験を積み、たくさん議論をしてきたからだと思っています。
-- では、最後の質問です。責務駆動設計を試してみたい初心者へアドバイスを頂けますか？
やはり、問題を解決するための複数の方法を見つけ、試すことですね。 そのために、まずは責務駆動設計の用語やロールとは何かといったことに十分に慣れることが必要です。それから、実際の業務では難しいと思いますので、練習を通じて、設計に対する複数の解決策を試してみると良いでしょう。
練習する場合は、どのように責務を調整するかを考えてください。たとえば、このオブジェクトは何をしているのか、このオブジェクトはサービス提供者に分解すべきだろうか、といった、さまざまな選択肢について考えてみてください。 また、自分の設計が良いのか悪いのかを、どうすれば判断できるのかについても考えてみましょう。それから、責務駆動設計の語彙を使って、自分の設計を他の人に説明するのもよいでしょう。
-- ありがとうございました。
オブジェクトデザイン ロール、責務、コラボレーションによる設計技法
| ©2008 OGIS-RI Co., Ltd. |
|
