ここ数週間、Joel Spolsky(リンク)とRobert C Martin(リンク)(Bobおじさんと呼ばれている)の間で議論が交わされている。そもそもの発端は、Jeff Atwood (リンク)とJoel Spolskyの「38:th Stack Overflow」 (リンク) というポッドキャストで、Joelの「よくユニットテスティングをJoelテストの13番目の項目に加えるべきだと言われるんだけど、それには反対なんだ」という発言だった(Joelテストとは、「Joelテスト: よりよいコードのための12のステップ」のことだ) (リンク)。Joelはこのように説明している(リンク)。
テスト駆動開発について議論されていることですが、すべてはユニットテストすべきだという意見があります……たくさんの人が私に、Joelテストを読んだ後で、「13番目の項目としてユニットテスティングを加えるべきですよ。コードは100％ユニットテストするべきなんですから」と言ってきました。
それを聞いてちょっとショックだったのです。やや原理主義に偏りすぎ、必要ないことまでやるべきだと言われたようだったので。つまり、そもそものアジャイルプログラミングのツボは、必要になるまではやらない、必要になったときページフォルトを起こす、ということではないでしょうか。私は感じるんですが、すべてなにもかも自動テストするというのは、たいていの場合、あまり役に立たないのではないかと。
Joelは2つの点を挙げて異論を唱えている。1つめは、なにに時間を使うのかという点だ。
ですから、私の感覚では、チームが本当に100%コードカバレッジするユニットテストを書くと、いくつか問題が起きます。 1つめは、ユニットテストを書くのにはあまりにも多大な時間がかかるのに、それだけの時間を費やして品質向上する必要があるとは限らないことです。つまり、品質は多少は向上しますし、何かを変更するときにどこかを壊してしまう心配はなくなりますが、それだけです。
Joelの異論の2つめの点は、テストスイートの脆さだ。
ユニットテストの本当の問題は、私の体験から発見したことですが、コードを進化させながら変更すると、一定の割合でユニットテストを壊すことになることです。コードを変更すると、その結果として、ユニットテストの10%が壊れます。これは意図してやっていることです。設計を変更するとか… メニューとメニューに関わる部分を変えたとか… メニューをどこかに移動したとか。その部分のテストは壊れてしまいますね。そうなると、いったん手を止めて、テストを作り直して新しいコードに対応させなければいけません。
議論の中で、Bobおじさんが集めたオブジェクト指向設計のSOLID原理(リンク) にも言及した。ちょうど、Bobおじさんと Scott Hanselman (リンク)が、Hanselminutesの最近の回で解説したところだった(リンク)。ふたたびJoelを引用する。
(SOLID原理は)オブジェクト指向設計であり、アジャイルな設計だとも言っていますが、本当は、実は違うものです。この原理はクラスをどう設計するか、クラスがどう働くべきかを説くものです。2人の話を聞いていると、きわめて官僚主義的なプログラミングに聞こえます。あまりコードを書いていない人が思いついたことのように聞こえますね、正直なところ。
JeffとJoelの2人は、コーディングやアジャイルにBobおじさんがどう関わってきたか、ちゃんと下調べをしていなかったようだ。Bobおじさんが招集して始めたミーティングが、アジャイルマニフェスト (リンク)に結実することになったのである。またJeffやJoelが生まれた頃からずっとコードを書いてきたのだ。実際、相当量のコードを公開で書いてもいる(リンク)。Bobはポッドキャストで言われたことについて、自分の考えを述べた。
ぼくはTDDを信仰しているわけじゃない。従う価値のある規律だと思っているのだ。ぼくがすべてのテストを先に書いているというわけではないぞ。テストの中には、ごく一部だけど、コードの後で書く方が具合がいいものもある。テストをまったく書かないコードだってある。書く価値がないからだ。だが、これは例外で、ルールはある。ぼくが書いたコードはほとんどが、テストを先に書いたものだ。(それにJoel、ぼくは時間を無駄にはしていないよ。
Bobはアジャイルに関してもJoelを訂正している。
JoelはSOLID原則がアジャイルじゃないと言ってるな。(ため息)誰でも、その誰かの親戚だって、「アジャイル」という言葉をちゃんと知っていると思いこんでいる。だがぼくこそが、「アジャイル」という言葉が決まった会議を招集したんだぞ。ぼくがアジャイル開発について書いてきた歴史は、アジャイル開発が創造されたときにまでさかのぼるんだ。なにがアジャイルか、なにがアジャイルじゃないかは知っているつもりだ。だから、ぼくならJoelを訂正してもいいと思うんだ。いいか、Joel。SOLID原理はアジャイルだ。
Joelが経験上10％のテストがコード変更時に壊れるという話についても、Bobおじさんは言及している。
Joelの次の不満は、脆いテストの問題だ。コードを変更すると、当然だがいくつかのテストは失敗する。Joelはこの割合が10%だと言っているが、お笑いぐさだ。それに、JoelがまだTDDを表層的にしか理解しておらず、まじめに取り組んだことがないこともわかる。もしテスト設計をした結果、一カ所変えるだけで10%のテストが失敗するようになったなら、他の職を探したほうがいい。テスト設計は、ほかのあらゆるソフトウェア設計と同じく、分離することにかかっている。
議論はさらに進み、Atwoodが自分のブログに「フェレンギ人プログラマ」(リンク)と呼ぶ書き込みをした(訳注: フェレンギ人とは、スタートレックに登場する種族)。そこでAtwoodは、SOLID原則が表面的にはとても納得いくものだが、ルールにあまりに頼りすぎるのは危険だと指摘した。
ルール、ガイドライン、原則といったものは経験から抽出した結晶で、研究し大事にすべきです。しかし自分の頭を使って目の前の問題を慎重に検討することに勝るものではありません。
Jeffの言い分には議論の余地がない。自分の頭を使って慎重に検討することなく、良いソフトウェアを生み出すことはできない。書籍やガイドライン、手法について書く人が意識するリスクには、書いてある通りにコンテキストを無視して従ってしまう人がいることも含まれる。だが、実は容易に避けられるようなリスクではないのだ。つまるところDreufysのスキル獲得モデル(参考記事)の問題であり、アドバイスの受け手がその時点でどれだけのスキルレベルに達しているかによるのである。Jeffのアドバイスに従うことは、決断することを意味する。上達した初心者(Advanced Beginner)あるいは一人前(Proficient)から、有能(Competent)へ移行すると決めたことになるのである(Dreyfusのモデルによる)。この移行は意図的に遂行するものであり、時間の経過で自然に起きるものではない。
さらに議論が公開でおこなわれた後、BobおじさんがStack Overflowポッドキャストに出演することになり、最近公開された(リンク)。さらに議論が公開でおこなわれた後、BobおじさんがStack Overflowポッドキャストに出演することになり、最近公開された。BobおじさんはSOLID原則の背景を語り、Joelはそれがいつ役に立つのか質問した。そこではあるパターンが生まれた。Joelはなぜある原理が重要なのかたずね、Bobが例を示して、コンポーネントを独立してデプロイできると説明する。Joelはその原理が非常に大きなプロジェクトで、独立したデプロイが必要なときにのみ役に立つのかと確認すると、BobはJoelに賛同した。
品質とTDDの件については、両者の違いがより鮮明だった(ドキュメントとしてのテストの価値は、全員が認めたが)。Bobはテストスイートを作るとき、それがJoelが言うように変更のたびに10%も壊れるほどガチガチにしてはいけないと言い、そのためにはロジックとプレゼンテーションを分離して、画面に表示するすぐ裏側をテストすればよいと説明した。Jeffは、同じことをUnixコミュニティでは以前からやっているとコメントした。まずコマンドラインアプリケーションを作り、そのうえにUIを実装してコマンドラインアプリケーションを叩くのである。
ポッドキャストのおわりで、Jeff、Joel、Bobの3人はアドバイスを盲信することのリスクとプログラミングコミュニティのスキルレベルについて話し、あまりにも多くの開発者が自分の仕事について無自覚すぎると同意した。まとめると、注意深さが欠かせないことには3人とも賛成した上で、ソフトウェア開発については異なる信念を持っていると感じている。変化へ対応することの重要性は認識しているものの、デザインやテストをどれだけすれば変化へ対応できるかが、3人の差異の中核であり、また業界を見てもその差異は非常に広い。変化があることは普遍的でも、変化への対応方法は多岐にわたっているのである。このディスカッションはあちこちのブログでの議論を招いた。フォーラムでは、ノイズ比が高まった。学習に関してよく考えられているコメントもある。Dhananjay NenetoがJeffのフェレンギ人プログラマについて次のように書いている(リンク)。
私の最大の懸念は、このポストに書いてあるアドバイスは、初級プログラマにはかえって害となるのではないかということです。トレードオフを判断するためのコストや知識を身につける前に、トレードオフをしてしまうかもしれません。慎重な検討を重ねて適切に適用すること(始めたばかりのときには多大な努力が必要です)と、原理を自分のものとして身につけるという望ましい道から、外れてしまう原因となるかもしれません。
この議論は永遠に決着のつかない種類のものだし、通常はノイズが多すぎて面白い議論とはならないものだ。それでも、いくつかの興味深い、嗜好の問題では片付けられない要素を含んでいる。いくつかの質問が提示される。
-
新しい開発者はどうすれば、経験ある開発者が身につけているものを、あまり手ひどい失敗をせずに学ばせられるのだろうか？
-
変化にはどう対応すべきだろうか？変化へ対応するための計画を、それ以上やっても無駄になってしまうような分岐点はどこにあるのだろうか？
-
SOLID原則は複雑なプロジェクトにしか役立たないのだろうか？使うかどうかの判断はどうすべきか？有効利用とやりすぎの境界はどこにあるのだろうか？
原文はこちらです: http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob