ルールを破ってもいいのはいつか？

作者 Mark Levison, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年10月2日 午前6時49分

コミュニティ

Agile

トピック

ユニットテスト,

アジャイル技術,

Delivering Quality

タグ

TDD,

XP,

品質

「Just Ship Baby(リンク)」の中で、JUnit Frameworkの作者、Kent Beck氏は、すべてのアジャイルプロセスとプラクティスのポイントは、出荷するソフトウェアを作り出すことだと指摘する。それらがソフトウェアを出荷する障害になるならば、おそらくあなたはルールを破る必要がある。

「Just win, baby」とかつて言ったOakland Raidersのゼネラルマネージャ Al Davis氏を引用して、Kent氏はあるトラブルを説明する。それは、彼が持っていたアイデアを試すため、Eclipse Plug-in Test Firstを書こうとしたときのことであった。

数週間にわたって六時間から八時間で、最初のテストを書いて、実行しようと苦労しました。Eclipseプラグインのためにテストを書くことは簡単なことではなく、問題が起きるのは驚くべきことではありませんでした。私はただ問題に激しくぶつかり続け、最初のテストをきちんと実行させようとしていました。

八時間作業した後、彼は役に立つテストもできておらず、最初のアイデアをテストすることも成功していなかった。数日後、彼は、今度はEclipseでテストを書かずに試してみようとした。三時間の作業でデモをすることができたが、それは彼を不安にさせるものであった。その試みは大して素晴らしいアイデアではなかったのだ。

Piergiuliano Bossi氏(リンク)は、Kent氏は間違ったメッセージを出したのだと考えた。Kent氏はただEclipseプラグインの機構を探りながら調査のスパイクを行い、そのような環境でのテストの書き方を理解しようとしただけだと彼は信じている。Piergiuliano氏は、TDDなしでAPIを調査するのは普通のことだと考える。APIを十分理解してから戻ってきてコードを書き直すまで待つのだ。ルールを緩める場合というのはどのようなときか、そして結果はどのようになるのかと彼は疑問に思っている。

プラクティスのいくつかを使わなければ、短期間の納品が達成できる状況を考えてみましょう。このような場合、チームは大体いくつか深刻な技術的な借り(リンク)ができることになるか、もっと悪いことにぶつかり、それによってシステムの外部品質はひどく影響を受けることになります。

…

システムがすでに妥協している他の状況もあります。それ以上設計の借りを大目に見ることはできず、ソフトウェアの正確さの欠如が、経済的な損失(または、それより悪いこと)を引き起こす可能性があります。私の経験によると、これは起こる傾向が強くなっていて、そうなったとき結果は壊滅的になりえるのです。「Just ship, baby」と言うことが、悲惨な結果をもたらすことがあります。結局のところ無責任なのです。

彼は、Kent氏の投稿がただ「マッチョなプログラミングの軽蔑すべき文化を送り込む」ものだと恐れている。

五年前、Uncle Bob氏(リンク)は同じ話題について書いている:

やみくもにルールに従うのは子供の使いです。ルールが役に立つときと立たないときを見分けるのには、頭を使います。私たちはルールが役に立つかどうか、引き続き評価する責任があります。

しかし、彼はその意見を和らげた。

プロフェッショナルなプライドの中にあるものが決め手になります。冷たく硬い何かが、まだ熱く赤々と燃えています。それは恐怖心からルールを無視することはありません。ルールによってひどいものを出荷しなければならないとき、それがルールを無視します。

つまり、Piergiuliano氏とBob氏の考えにあるのは、本当に重要なのは品質だということを心の中に持ち続けることである。

原文はこちらです：   http://www.infoq.com/news/2008/09/break_rules

• 次へ >