2003/07/27
どうもー、「プロトタイプ開発真っ只中」
でおなじみのやまろうです(疲)。
みなさん、お久しぶりです。とても忙しくてメルマガ書いてる時間がありません
でした。
前にもお話しましたが、僕は今ある銀行のWebアプリケーションの
プロトタイプ開発に参加しています。前の現場では、開発の分担の仕方が主に
「あなたはEJB専門、君はServlet専門」というふうにクラスの種類で担当を
分けていましたが、今回は「君はこの業務とその業務とあの業務」という風に
業務によってわけました。なので、JSPから始まって、Action、EJB、DAOと全て
自分で作ることが出来ました。やっぱしこの方がおもしろいと感じました。
前の時も「業務で担当分けよう」って言ったんですけど、それだと出来ない人
がいるってことで、一人の人が同じようなクラスをずっと作りつづけるという
ことになりました。これはこれでうまくいったんですけどね。
そして、開発の状況はというと、概ね良好でございます！環境設定がうまくいって
なかったりで最初苦戦したんですけど、途中からはサクサク進むようになりました。
一番参ったのは、PKI製品の関係上、サーブレットコンテナをJRun3.1を使ってて
Struts1.1のTagLibが使えなかったことです。せっかくDynaActionForm使おうと
思ったのにー！ということでなくなくStruts1.0を使いました。なんちゅうか、
つまらなくなったというか、気持ちが折れそうになりました。
しかし、そんな時支えになったのがXP(エクストリームプログラミング)です。
というかXPの論文です。XPの論文はインターネットでたくさん公開されている
のですが、とにかく内容がおもしろくて、文章自体がユーモアにとんでて
思わず吹き出しちゃうようなのもあるんですけど、はっとさせられるような
斬新な考えがあるのです。
XPについて簡単に説明しますと、
コミュニケーション、フィードバック、単純さ、そして、勇気を
という「4つの価値」重んじた開発手法です。
コミュニケーションは、
「ドキュメントなんて読むより、いっしょに作業したり
話した方がよくわかるよ」。
フィードバックは
「長い時間かけて仕様を決めたって、実際使ってみて初めて
わかることって多いでしょ。それだったら、小さいアプリケーションを
さっさと作って小規模なリリースを繰り返す方がいいんじゃないの？
使ってみないとわからないことって多いですぜ」
単純さは、
「今は要らないんだけど後のことを考えて、こうしておいた方がいいよなー
とか言うけど、どうせ、要らないって！必要になったその時作ればいいって！」
勇気は
「あっ、このコーディング、ああしておけば良かったぁ。今から直すと
またテストしなきゃなんないし、失敗したらやだなぁ。直すのやめとこ。」
「おいおいー、勇気を持って直そうぜー！テストなんて、JUnit流せば
一瞬で終わるじゃねーか！」
ということです。この「JUnit流せば一瞬で終わるじゃねーか」がXPの核となる
プラクティス「テスティング」です。
JUnitの使い方くらい知ってるわいって人も多いでしょうが、簡単なサンプルを
ご紹介します。ってなわけでソース行ってみよう！
package mag;
import junit.framework.*; //(1)
public class CalcTest extends TestCase {
public static void main(String args[]) {
junit.textui.TestRunner.run(new TestSuite(CalcTest.class));
}
public CalcTest(String name) {
super(name);
} //(2)
public void testAdd() throws Exception { //(3)
Calc calc = new Calc();
int result = calc.add(1, 2);
super.assertEquals(3, result); //(4)
}
}
class Calc {
public int add(int num1, int num2) {
return num1 + num2;
}
}
(1)から、(2)まではお決まりのコーディングです。
(3)でCalcというクラスのaddメソッドをテストしています。
(4)でassertEqualsメソッドでresultが3であるかをチェックしています。
3じゃない場合はテスト失敗ということになります。
実行しましょう！
www.junit.orgからJUnitをダウンロードして、解凍してそん中にある
junit.jarをクラスパスに設定します。
で、
コマンドラインから
java mag.CalcTest
コンソールに
.
Time: 0.016
OK (1 test)
と出たはずです。
どうでしょうか？一瞬で終わったでしょ、テスト。
これで「あっ、このコーディング、ああしておけば良かったぁ。」と
思ったら、直してJUnitを流せばテスト完了ってわけです。
そして、テスティングはプログラマーに勇気を与えます。テストが通れば、その
コードに自信を持てます。そして、いつでも、すぐに実行できるテストがあれば、
手軽にコードを変更することができます（コードを変更しても、テストを通して
正しいことがすぐに確認できるから）
「XPは勇気を重んじるんだから、勇気を持ってどんどんコードを変更しよう」と
言っても、テストを用意せずにコードを変更するのは、｢勇気」ではなく
「ただの自殺行為」となってしまいます。
そして、すぐ実行できるテストがあるから、顧客の仕様変更にも素早く対応できます。
コードを変更してすぐテストが出来るんですから。
マーチン・フォウラーさんの論文に以下のようなことが書いてありました。
「問題のあるプロジェクトの開発者は"このプロジェクトは仕様変更が
多すぎるんだよ"と言い訳するがビジネスにかかわるソフトウェアを開発するなら
仕様が変わるなんて当たり前であってそれにどうやって対応するのかが問題なんだ。
開発に入る前に、要求の全体像を文書化して顧客のハンコをもらって、ハンコ
押したんだから、ちょっとやそっとで仕様を変えんなよっていう考え自体が
ヘボなんだ。」
かっこいぃーーー！！！そういや前の現場で「仕様変更が多すぎるんだよー、
契約した時の見積もりと全然違う工数になってるよー」っておれさまは
営業のこともわかってるぜーって感じで何度も得意げに
言ってた人がいたけれど、あの人ヘボだったのね、へへっ！！
さらに、テストを書くことによって、そのクラスを使う側の視点に立つことが
出来、より良い設計を考えることが出来るようになります。テストを書いてて
「テスト書くのめんどくせーなー」と思ったらそのクラスは使いにくいクラスだと
言えます。
さらに、テストを先に書けば(XPではテストファーストと言う)、今から作ろうとしてる
メソッドの実行結果を先に考えることになり、より仕様をしっかりと把握してから
コーディングに入るので、より良いコーディングが出来ます。
僕は、数ヶ月前まで、趣味等でプログラムを書くとき、いきなりコードを
打ち込んでいました。その結果、くだらないミスをつぶすデバック作業をしていました。
「くだらねー」とかつぶやきながら・・・。
そして、いつだか読んだ本を思い出しました。
「大体の人が、いきなりコードを打ち込むのではなく、簡単なスケッチを書くであろうが」
みたいな内容でした。
「そっか、じゃぁおれちゃんもスケッチを書こう！」ということで
ある程度、複雑なプログラムは、紙に処理の手順やイメージ等を書いて、
頭の中を整理させてから、コーディングをしてみました。
すると・・・、
なんと一発でバグなしのプログラムを書くことが出来ました。
頭の中を整理することの大切さを知りました。テスティングもスケッチと同じような
効果をもたらすのではないかと思います。クラスを使う側の視点に立つことが出来、
実行結果をはっきりと想像してから、コーディングを行う。さすれば、よりスムーズに、
正解へと導いてくれるのではないでしょうか！
ってなわけで、テスティング論でした。XPについては書きたいことがいっぱいあるんですが
また今度ということで、んじゃ！
やまろう