ひろきち劇場NEO

ソフトウェア開発から写真、旅行、ダイビングまで寄せ鍋風にお届けするブログ。ええダシが出てる・・・かな

アジャイル開発についての論争

2009年02月18日 | ◆仕事
Info QにSpolsky vs Uncle Bobという記事がUPされました。アジャイル開発に関する熱い論争です。

面白かったので訳してみます(適当ですが)。

**********

ここ何週間か、Joel SpolskyとUncle Bobの愛称で知られるRobert C Martinの間である論争が続いている。事の発端はJeff AtwoodとJoel Spolskyが提供する"Stack Overflow podcast"の第38回目の配信で、Joelが自身の提唱する"The Joel Test:より良いコードのための12のステップ"の13個目のステップにユニットテストを追加するようたびたび提案を受けているが、それには同意できないと発言したことだった。Joelが言うには、

「テスト駆動開発に関する議論があるよね、・・・なんでもかんでもユニットテストをするべきかってやつ、・・・たくさんの人が僕の書いた"The Joel Test"を読んで、こう言うんだよ『13個目のステップとしてユニットテストを加えるべきだ、自分の書いたコードに対する100%のユニットテストを実施するべき』ってね。これを聞くと、必ずしも必要でないことにちょっと固執しすぎているように感じるんだよね。ほら、アジャイルの思想って今必要でないことはするな、ってことじゃない。必要に応じてやれって。時間をかけてなんでもかんでも自動的にテストしたって、役に立たないんじゃないかって感じるんだよ」

「もし本当に100%のユニットテストやったとしたら、そこにはいくつかの問題が生じると思う。ひとつは、テスト仕様書を書くのに膨大な時間を費やすということ。品質を改善するためにそんなコストをかけなくてもいいにもかかわらず。いや、もちろん品質は改善するかもしれないよ。自信を持って副作用の無い修正ができるかもしれないし。でも、それだけだよね。」

「でも僕が発見したユニットテストの本当の問題は、プログラムが進化していくにしたがってコードに施される修正がある一定の割合でテスト仕様をだめにしていくってことなんだ。コードを修正するとするだろ、そうするとユニットテストの10%はもう役に立たないんだよ。だって、デザインを変更したら、例えば、メニューを別の場所に移動したら、そのメニューに関連していたすべてのもの、そしてメニュー自身はもう別のところにある。そうすると関連テストはすべてもう台無し。で、新しいコードに即してもう一回テストを書き直さなきゃならない。」

議論はUncle Bobの"SOLID principles of object-oriented design"へと移っていく。

「あれはオブジェクト指向設計のことだろ、なのに彼らはアジャイルだって言う。ぜんっぜん違うし。あれはクラスをどう設計するか、どう動くべきかについての哲学じゃないか。それにあれを聞いてると、ぶっちゃけろくにコードも書いたことのない輩の思い付きによる、極めて官僚的なプログラミング手法に聞こえるんだよね」

しかしJeffとJoelはUncle Bobの経験とアジャイルとの関係について予習不足だった。Uncle Bobはアジャイルマニフェストへと発展した会議の発起人であり、JeffとJoelが生まれた頃からずっとコードを書き続けているのだ。また、彼は公にも膨大な量のコードを書いている。そしてBobはpodcastでの発言に関して言及した。

「僕はTDDの信奉者じゃない。採用する価値のある一つのやり方だと考えている。すべてのテストを最初に書くわけじゃないし、コードを書いた後に書いたほうが都合がいい場合もある。価値が無ければテストをまったく書かない場合さえある。でもそれは例外だ。ほとんどのケースでは最初にテストを書く。(そしてJoel、これは時間の無駄なんかじゃないんだよ)」


また、Bobは"機敏さ"についてもJoelの意見を覆した。

「Joelは"SOLID principle"はアジャイルじゃないと言った。(ため息)。みんな自分はアジャイルという言葉が何を意味するか知っていると思っているが、"アジャイル"という名のついた会議を招集したのはこの僕だ。僕はアジャイル開発という言葉が生まれてからずっとアジャイルについて書いてるんだよ。僕は何がアジャイルで、何がアジャイルじゃないか知ってるつもりだ。だからこの点で僕にはJoelの意見を却下する権限があると思っている。」

コードを変更した場合、だいたいテストの10%がダメになるというJoelの経験について、Uncle Bobは書く。

「Joelはさらにテストのもろさ、つまりコードを変更したらテストのいくつかは自然に崩壊するということについて不満を言っている。Joelは10%という数値を出している。お笑いだ。これはJoelがTDDについて表面的に理解する以上のことをしてこなかったことを示している(ビジネスガリ勉の失敗の典型だ)。もし君が一つの修正をしたがためにテストの10%がダメになるのであれば、職を変えたほうがいい。テストの設計というのはソフトウェアの他の設計と同じで、いかに結合性を弱めるかということなんだよ。」

議論が続く中、Jeffは"The Ferengi Programmer"という記事を自身のブログにアップした。そこで彼は、"SOLID principles"が表面的には問題がないことは認めるが、規則に強く依存することには危険が伴うのだと言った。

「ルール、ガイドライン、思想は経験によって醸成された宝石であり、それらは研究され尊重されるべきものだ。しかし、それらをもって自分たちの仕事について批判的に考えることの代用にすることは出来ない。」

Jeffの書いたことに議論の余地はない。自身の行動について批判的に考えることなしに良いソフトウェアは生まれないし、本やガイドライン、または手法などについて書いている人はたいてい、自分の考えの本当の意味を理解せずただ盲目的にそのアドバイスに従ってくる人がいるというリスクがあることを知っているし、そしてそれを回避することが簡単なことではないということも理解している。これらはすべてドレイファスの技能獲得モデルに尽きる。彼らがアドバイスを読んだとき、その技能のどのレベルにまで到達したのか、ということなのだ。Jeffのアドバイスに従えば、あるスキルに関してドレイファスの尺度で言うところのAdvanced BeginnerあるいはProficientからCompetentレベルへ移動したいかどうかはあなた自身が決めることだ、ということだ。その典型的な移動はあなた自身が意図的に起こさなければならないもので、年が過ぎるに従って自然に起こりうるものではないと考えられている。

**********

長いのでここまで。

この後さらに論争があり、最終的に3人はいくつかの点で合意します。そのあたりは上のリンクで確認してください。

いやあしかし、アツいなこの人たち。基本的にソフトウェアを愛してるというのは伝わってきますが、アメリカ人ってやっぱり議論好きなんでしょうか?

おかげで参考になりましたけどね。