Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
こんにちわ。ばたっちです。
原油の価格が上昇してる中、時速370kmも出るスーパー電気自動車 というのができてるそうです。
なんでも、ホイル(車輪)の中にモータが入っていて、直接タイヤ を回すという仕掛けだそうです。 写真を見るとタイヤが８つあります(^^;
何が優れているかというと、エネルギー消費をエンジンの１／４に しちゃったことです。
従来のエンジン式では、
エンジン→トランスミッション→プロペラシャフト→ドライブシャフト。。
その他云々を経由してタイヤに力が伝えられるので、無駄が多かっ たのですが、それに比べて、
モータ→タイヤ
にダイレクトに力を伝えることで、エネルギー損失(無駄)を格段に 減らすことで実現しているんですね♪
ソフトウェア開発も間に余計なもの(設計書、テスト仕様書。。(^^;) を省略して、損失を減らしたいですね。
そんなあなたには、XPの「テスト駆動開発」はいかがでしょう？
従来のドキュメント中心の情報伝達では、
設計−(設計書)→コーディング−(テスト仕様書)→テスト
のように、伝言ゲーム状態になり、情報の損失が大きくなります。
テスト駆動開発では、
自動テスト←→コーディング＋再設計
のように、やりたいこと(要求)を表現した自動テストが、ちゃんと 動くようにコーディングすることを、動くプログラムで確認しなが ら、進めることができます。損失はかなり軽減されます。
なんたって、動かしながら確認できるので、フィードバックが明確 です。(百聞は一見にしかず状態ですね(^^;)
※偶然ですが、コラムメンバーの最新記事がすべて「テスト」ネタ のようです。いかに、XPでは「テスト」が重視されているかという ことですね♪
今回は、ビジネス編、開発編の２本立てです♪(^^;
「ビジネス編」「開発編」
お客さん：「以前の機能A が動かないぞ！」
と、お客さんが怒鳴り込んでくる。
解析してみると、今回追加リリースした機能B の変更で、機能A の ルートが動かなくなっている。。。
「デグレだ。。お客さんになんて言おう。。」
なんてことありませんか？
お客さん：「この問題は大変だ！他に類似箇所がないか、全コード一斉チェックだ！」
と号令がかかる。。
全コードチェックだって！？この何万キロラインもある、重複バリ バリの(^^; コードを？
「こんなの人手で確認しても確認しきれないぞ。。」 「今後も発生し得るな。。」
なんてことも、ありませんか？ (^^;
何か問題があれば、人手で全コードトレース。バージョンアップの たびにレグレッション・テストと称して、過去のテスト項目片手に しこしことテスト実施。
従来の開発ではテストは一度きり(ワンタイム・テスト)という性格 のため、テスト実施のタイミングをすり抜けて混入したバグは、後 で表面化し、災いをもたらしてくれます。
こうなったら、テストも対処療法です。基本的に手遅れな状態とい うことですね。(^^;
また、
「動いたコードは触るな(変更するな)！」
という教訓により、継ぎ接ぎ、スパゲティ、重複バリバリでぶくぶ くと立派に育った(？)コードは、バグのコードも分散化。
治しても切りがない、もれがあるという状況になりがちです。。A(^^;
しかも、こんな状態ではあれほど大事に作った「ドキュメント」 (設計書など)はまったく役に立ちません。 実際のコードの内容ともどんどん離れていきます。
コードと設計書の内容がマッチしていてこそ、初めてドキュメント が意味を成しますが、いまだかって、そのようなドキュメントに出 会ったことはありません。コードを直接見る方が早いくらい。A^^;
頑張って、先にドキュメントを作っても、システムの品質を維持し てくれませんよぉ。エンジンとタイヤを中継する「プロペラシャフ ト」のように、時間や効率の損失を生むものでしかありません。
そんな時間があるのなら、自動テストを書く時間に使いましょう！
XPの「テスト駆動開発(TDD: Test Driven Development)」では、 従来、コーディングに先立って作っていたドキュメントにかかる時 間、そしてテストという名に隠れたデバッグにかかる時間を使って、 自動テストを書きます。
まぁ、どーしても設計書が必要なら、テスト駆動開発で高い品質で システムを完成させた後に、ゆっくり書けばいいでしょう。 完成したシステムをドキュメントに反映させるわけなので、内容は マッチしますし、バグなんか出ないから(^^;、内容が離れていくこ ともほとんどありません。
テスト駆動開発はあらかじめトラックにラインを引き(テストを作 り)、それからラインに沿って選手(プログラム)を走らせて、ゴール を目指すようなもの。
従来の開発は、選手(プログラム)が走り始めてから、「こっちだ」 「あっちだ」と指示して、ゴールへ向かわせるようなもの。 あっ、「すいか割り」っぽいかも A^^;
どちらが効率がいいか、はっきりしてますね♪
具体的な手順については、書籍など情報源はたくさんあるので、こ こでは説明しませんが、ケント・ベック様が作られた「xUnit」と は、あらゆる言語に移植され、誰でもすぐに始められるようになっ ています。
一人でも可能です。スモールスタートが切れるのも「テスト駆動開 発」のメリットです。
そして、今まで作った自動テストはプログラムなので、いつでも実 施できます。常時テスト(エニタイム・テスト)ですね。もはや、ワ ンタイム・テスト時のように、テストの隙間をぬぐって、バグが混 入する隙も与えません！(^^;
自動テストはコードとダイレクトに相互作用し、コードの品質を向 上させます。もはや、継ぎ接ぎ、重複、スパゲティとはおさらばで す！ドキュメントと違って、高効率な相互作用が品質を生み出しま す。
テスト駆動開発は、あなたを「デスマーチ」の恐怖から解放します。 自分の身を守ることから始めましょう♪
いずれ、すべての開発は「テスト駆動開発」になります(。。と言い 切ってみる)。とっととスタートを切っちゃいましょう。(^_^)/~
There is no comment.