【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

XP小説 - XPを小説風に紹介してみる、テスト。

目次

XPを小説風に紹介してみる、テスト。

初心表明

XPの紹介を小説風におこなってみようかと思う。まぁ、だらだらとね。

設定

登場人物

天野主人公。プログラマー。昔は、XP懐疑派だったが、最近はXP推進派に変わった。心変わりの速さは、技術者ならではのものか。オブジェクト指向に関してはプロジェクトの中で一番知識がある。
猪狩プロジェクトマネージャ。XP急進派。XPに魅せられて、自分がマネジメントするプロジェクトには全てXPを適用するという、筋金入りのXPer。
牛尾プログラマー。今年入社の新人。まだ、それほどスキルは高くない。
江川プログラマー。プログラマー歴20年のベテラン。COBOL、PL/1、C、Javaを操る。プログラミングしてられれば幸せで、自分の書いたコードにとやかく言われるのを極端に嫌がる傾向あり。
大熊プログラマー。XP急進派。XPがやりたくて猪狩に無理を言って、このプロジェクトに参加させてもらっている。XP以外は悪、特にWater Fallは極悪だと思う傾向あり。
川井プログラマー。紅一点。主人公の天野が密かに憧れているが、実は川井と北野が出来ている。
北野コンサルタント。XPのコーチ役として週に2回プロジェクトに顔を出す。猪狩の古くからの友人である。
倉貫顧客。猪狩に説得されて猪狩の会社で執務している。いわゆる、オンサイト顧客。正直、しょっちゅう質問されて、うざったいと思っている
賢人(ケント)役割不明。いつか登場予定。
小熊顧客。倉貫の同僚。他のプロジェクトに依頼しているシステムの担当。
佐伯小熊が依頼しているシステムのプロジェクトマネージャ。大変な勉強家であり、XPなどにも詳しいが、なぜかXPには懐疑心を抱いている。年のせいか自分の身を守ることが最優先。

本文

「おはよう。」

今回のプロジェクトは挨拶から始まる。やはり、あいさつは気持ちいい。 今まで携わってきたプロジェクトは、音もなくみんなが現れて、そして去っていくというのが普通だった。 とうぜん、ちょっと飲んで帰るなんて事はしないのだ。 ただいまの時刻は9時30分を少し過ぎたところ。10時からのスタンドアップミーティングには、まだ充分時間がある。 昨晩の結合テストの結果を確認したり、スタンドアップミーティングの準備をするには、やはりこのぐらいの出社時刻がベストなのだ。 最近はWeb日記を見るのがマイブームだ。 様々な人が自分たちがやっているXPプロジェクトを報告している。 誰に向かって報告しているのか分からないが、同じ悩みを共有したり、ヒントを得たりとかなり助けてもらっている。 自分も世の人のために何か貢献しなければという気に自然となる。 9時半より早く来てしまっても、タスクに集中して取り組むにはちょっと時間が短い。 スタンドアップミーティングで作業が中断されるのは、なんとも効率が悪いのだ。 そうこうしているうちにスタンドアップミーティングの時間になった。ホワイトボードの前に集合して、昨日したこと、今日すること、そして問題点を順に発表していく。 問題点のみ、ホワイトボードに書き出されていく。今日の書記は、憧れの川井さんだ。ついつい見とれてしまう。 「次、天野さん」とプロジェクトマネージャの猪狩さんから声がかかった。「えっと、・・・」つい川井さんに見とれていて、なにを言うか忘れてしまった。 さっき書いたばかりの手持ちのメモに目を通す。早く来て、スタンドアップミーティングの準備をしておいてよかった。「・・・問題なんですが・・・」

「えっ、変態なんですが!?」と、猪狩さん。

自分、そんな事言ってないですって。 「問題なんですが、ペアプロマシンについているキーボードが101と106が混在していて、タイプミスが多くなっている気がするんですが」と、気を取り直して大きな声で話す。

ふぅ、やれやれ。自分の番が終わった。 少し大きな声を出したせいだろうか、ちょっとリラックスしている自分に気づく。 そういえば、このあいだのテレビで身体性の話をしていたっけ。 人間は深く呼吸をするとリラックスができるんだって。 大きい声で話すってことは、深く呼吸をすることだからリラックスできるのか。 朝からリラックスできると能率上がるよね。 スタンドアップミーティングを、朝行うのはこのへんの狙いもあるんだろうな。 ってことは、大きな声を出すとリラックスできるわけだ。 いつもぺけピーのときは緊張しまくりだから、今度大きな声を出して演じてみるかな。

「では、その件についてはスタンドアップミーティングが終わってから興味のある人だけで話すことにしましょう。」と、プロジェクトマネージャが場を仕切ってくれた。 以前は、ここで議論に華が咲いてしまい、あまり関係のない人の時間を無駄に使ってしまって、非効率的なスタンドアップミーティングになっていた。 正直なところ、自分も昔は、こういうところが嫌で「XP=猪狩さん」を嫌っていたのかもしれないと思う。 XPが悪いんじゃなくて、進め方が悪かっただけなんだけなんだよね。 コンサルタントの北野さんが、スタンドアップミーティングの運営のまずさを指摘しなければ、嫌いなままだったかもしれないと思う。 今は、XPやっていて良かったと思うようになったよ。


スタンドアップミーティングの後に残ったのは、自分のほかに、猪狩さんと江川さん、そしてコンサルタントの北野さんの4人だった。 やはり、ベテランの江川さんはキーボードにはかなり執着があるのだろう、彼がはじめに口火を切った。

 「やっぱりできるプログラマは101しかないですよ。全部のキーボードを101にしましょう」
おっと、いきなり断定口調だ。 以前のプロジェクトでも似たような事を経験したことがある。 ベテラン技術屋というのは、なぜこうも自分が正しいと主張したがるのだろう。 「相談したい」と言うくせに、いつもすることは「説得」なのだ。 しかし、技術面では誰もベテランに勝てないのは明らかで、ついつい従ってしまいう自分に少々嫌気がしているの事実だが。
 「できるプログラマ、というのは具体的にどういうことですか?」と北野さん。
北野さんのコーチングマジックの始まりだ。
 「そうですね、言語仕様をばっち覚えていて、ライブラリにも精通しているってことかな」と考えながら、江川さんが答える。
 「なるほど。では、そのような方はこのプロジェクトにいますか?」
 「えっと、天野君と、川井ちゃんはOKかな。大熊さんは、もう少しでこのレベルになりそうだなぁ」
 「そうですね。私もそう思います。彼らが好きなキーボードはどちらですか?」
 「うーん。106だよね。101キーボードの推進派は俺だけか。思いっきり少数派だな。」 
 「では、天野さんに質問します。101キーボードに慣れるのにどのくらいかかりますか?」
おっと、いきなりふられた。
 「えぇ、1週間ぐらいで慣れると思いますが」
 「えっ、そんなにかかるのか。おれが106に慣れるのは2日もあれば充分だよ」
と江川さんが割って入った。これも、ベテラン特有の行動だよね。 すぐに人の話の腰を折ってしまう。本人に自覚がないからたちが悪い。 でも、今回はいい方向に話が進みそうだ。
 「と、いうことは俺が106キーボードになれたほうがお得というわけか」
ありゃりゃ、自分で結論出しちゃったよ。さすが北野マジック。
 「ですね。では、江川さんお願いできますか」と北野さん。
 「まぁ、しょうがないな。チームのためだよ」
 「猪狩さんは、なにかご意見ありますか?」
ここも北野さんのいいところだと思う。発言をしていない人にも、きちんと発言のチャンスを与える。
 「そうですね。106キーボードだったら、どっかのプロジェクトでサーバー用に買ったPCについてきたのがあると思いますので、もらってきましょうか」。
 「それは、いい考えですね。いつごろまでに手に入りますか?」
 「午前中にはなんとかなると思います」。
 「天野さん、これで問題は解決されましたか?」
 「はい!」
すごすぎる。たった5分程度のミーティングで、自分の問題が解決されてしまった。 問題を検討できる場があるというのも素晴らしいけど、会議の進め方が特に素晴らしいと思う。 江川さんは、チームに対して自分が折れてやったんだ、という感じになっているの納得感があるようだし、猪狩さんは自分のすべき作業がデットラインまで明確に具体的になっているし、自分は思っていた問題が解決されるしで、なかなかいい後味の会議になったなったと思う。 昨日は大熊さんが提議した「スタンドアップミーティングは、XPのプラクティスじゃないからやる必要はない」という問題は、大熊さんと猪狩さんの間で議論が炸裂してしまったけど、北野さんがいたら10分もすれば解決したんだろうなと、心底思ってしまうね。


今日の開発が始まった。XPなので当然ペアプログラミング。 1つのディスプレイ、1つのキーボード、1つのマウスを、2つの頭脳、2つの口、4つの目、4つの耳、4つの手を使って開発を進める。 さっきのミーティングに参加していないメンバーは早速開発に取り掛かっている。江川さんとペアになって開発を進める。 今日から江川さんにも106キーボードになれてもらいたいところだが、まだ猪狩さんが調達してきてくれないので、仕方なく101キーボード。正直使いにくい。 5分ほどドライバーをしていたが、江川さんからツッコミが入る。「エンド使えば楽勝ジャン」。 何を言っているかよく分からないので、キーボードを渡してドライバーを交代してもらう。 うげ。ずいぶんすっきりしちゃったよ。自分がStringクラスの使い方をマスターしていなかっただけらしい。

 天野コード
 if(message.substring(message.length() - 1, message.length()).equals("A")){
     //...
 }

 江川コード
 if(message.endsWith("A"){
     //...
 }

「なるほど。こんなのあったんですか。」と素直に喜んでしまった。 江川さんも自分の優位性をアピールできたせいか、誇らしげな表情だ。 ペアプロのよいところは、こんな風にちょっとしたテクニックを簡単に学習できるところだろうか。 セミナー風にかしこまってやるわけではないので、教える側の準備もさほど大変ではないし、教わる側も変に構えなくてすむ。 ペアプロにはリアルタイムレビューというメリットの側面もあるが、やはり教育効果というか、お互いの力を高めあう場としての意義が非常に高いと思っている。 こんなバカコードをコードレビューで、大勢からたくさん発見されたら、自分はいたたまれないだろう。モチベーションが下がりまくってしまう。ある意味、安全地帯でのコードレビューと考えられるだろう。


さてと、気を取り直して江川さんとのペアプロを楽しむことにしよう。 ペアプロの楽しさの源は、ちょっとした成功を2人で分かち合えるところにあるんだと思っている。 バーが緑になったときだけではなく、意図的に赤くしようとしたときに赤くなるというのもなかなかの快感である。 ひとりで、この成功をニヤニヤしていたら、怪しい人だと思われかねないなので、無表情を装うしかない。 テスト駆動開発では、「まずは赤」ということで、テストコードを先に書き、テストコードがコンパイルできるだけの最小限の製品コードを書くのが基本である。なぜ最初に赤にするかというと、そのテストコードの妥当性を確認するためだ。「バグ埋め込み法」というテクニックがあるが、これは埋め込まれたバグがテストでどれだけ発見されたかで、テストの進捗を測定するという側面のほかに、テストケースがどれだけ妥当かの判断にも使えるという側面があるのだ。 次は、「Fake It」と呼ばれる作業だ。テストを通すための最小限のコードを書く。当然バーは緑になる。 そして製品コードを「Refactor」し続け、バーを緑に保ったまま製品コードを導くか、「Triangulation」ということでさらにテストケースを増やして、バーを一度赤にしてから製品コードを解に近づけていく方法をとるのだ。 今は、文字列をカンマで区切って配列に入れて返すメソッドを作っているところだ。 まぁ、さくっとテストコードを書いてみた。

 import java.io.BufferedReader;
 import java.io.StringReader;
 
 import junit.framework.TestCase;
 
 public class CsvReaderTest extends TestCase {
     public void testSplit() {
         StringReader stringReader = new StringReader("a,b");
         BufferedReader bufferedReader = new BufferedReader(stringReader);
         CsvReader csvReader = new CsvReader(bufferedReader);
         String[][] result = csvReader.toArray();
         assertEquals(1, result.length);
         assertEquals(2, result[0].length);
         assertEquals("a", result[0][0]);
         assertEquals("b", result[0][1]);
     }
 }

 「こんな感じでどうですかね、江川さん」
とくに江川さんからのツッコミなどはない。 江川さんも、このコードにはご満悦のようである。 自分としても、一気に書いたわりには、意図が良く分かってなかなかのものだと思う。
 「おや、ずいぶん一気に書きましたね」と、背後から北野さんが現れた。
 「えぇ、大分TDDにも慣れましたので、このぐらいは一気に書けるようになりました」
 「そうですか。それはかなりスキルアップしましたね。ところで、TDDの勘所ってどこだと思いますか?」
 「そうですねぇ、やっぱりリズムだと思います。ちょっとテスト書いて、ちょっとテストして赤を確認、ちょっとコード書いて、ちょっとテストして緑を確認」
 「私もそう思います。このリズムは、テンポが速いのと、遅いのではどちらが好きですか。」
 「当然、速い方だよ。」
 「当然、速い方です。」
江川さんと同時に回答してしまった。ちょっと2人で苦笑い。
 「ですよね。このテストコードで、もっとテンポを速くしたら気持ちいいですか?」
 「そりゃ、気持ちいいですよ。あっ」
江川さんが何かに気がついたようだ。すかさずキーボードを奪ってさっきのテストコードの下3行をコメントアウトした。

 public void testSplit() {
     StringReader stringReader = new StringReader("a,b");
     BufferedReader bufferedReader = new BufferedReader(stringReader);
     CsvReader csvReader = new CsvReader(bufferedReader);
     String[][] result = csvReader.toArray();
     assertEquals(1, result.length);
 //  assertEquals(2, result[0].length);
 //  assertEquals("a", result[0][0]);
 //  assertEquals("b", result[0][1]);
 }

 「どうですか」
 「いいですね。どうしてこうしたのか、天野さん分かりますか?」
 「えっと。」
言葉に詰まる。
 「多分、さっきのコードでは、4つの表明を通るまでテストが通らないからだと・・・」
 「正解!。そうですね、今、江川さんが手を入れたテストならば、素早く緑にできますよね。」
 「なるほど。これなら、赤の状態を短くできるからストレスがたまらず、精神衛生的にもよいですね。」
思わず、大きな声を出してしまっている自分に気づいた。
 「ならば、ちょっとした成功、私は『プチ成功』と個人的に呼んでいるんだけど、この数が増えることになるから楽しくなるな」
江川さんもこのちょっとした成功を楽しんでいたようだ。 それにしても「プチ成功」とは、なかなかの響きではないか。 気に入ってしまった。今度、どこかで使ってみることにしよう。
 「ちなみに、Assert Firstという進め方があって、まずメソッドの仕様をこんな風に表明して、」

 assertEquals(1, result.length);

 「次に、この表明に必要なコードを順に前に書いていく、」

 ↑String[][] result = csvReader.toArray();
 ↑assertEquals(1, result.length);

 「というのも、覚えていくといいよ。どんなテストがしたいのかが明確になりやすいんだ」
北野さんは、いろいろ知っていて本当に頼りになる。 しかも、押し付けがましくないので、素直に話を聞いてしまう。 うーん、北野マジック。
さて、テストも書けたことだし、次は製品コードを書く事にしよう。 まずは、コンパイルを通すことに専念する。
 「江川さん、まずは自分が製品コード書きますね。」
 「OK、じゃんじゃん行ってくれ」と江川さんが、快諾してくれた。

 import java.io.BufferedReader;
 
 public class CsvReader {
     public CsvReader(BufferedReader bufferedReader) {
     }
 
     public String[][] toArray() {
        return null;
     }
 
 }

 「これで、コンパイル通りますね。ほら」
よし、コンパイルが通った。早速テストを実行する。NullPointerException?が発生する。そりゃそうだ、nullを返しているんだから。当然ながら想定の範囲内だ。 次に「Fake It」だ。テストをパスさせることに専念する。

     public String[][] toArray() {
         return new String[1][0];
     }

 「いいね」と江川さん。
実行する前から、テストが通るのが予期できる。これぞ、ベビーステップの利点であろう。当然、バーは緑になる。さて、次はどうしようか。先ほどコメントアウトした、表明があるから、1つコメントを戻して、テストケースを増やすことにしよう。ここは「Triangulation」で攻めるのだ。コメントを戻して、早速実行。バーは期待通りに赤になる。製品コードに手を加えよう。

     public String[][] toArray() {
         return new String[1][2];
     }

 「よし」
 「よし」
 江川さんと、また同調した。この、感覚がまた楽しい。もう一つコメントをはずして、戻り値の中身を確認することにしてみる。

     assertEquals("a", result[0][0]);

ここで、またテストを実行する。当然赤になる。

 「Fake Itしますか。」と江川さんから、声がかかる。

	public String[][] toArray() {
		return new String[][]{{"a", "b"}};
	}

そして、テストを実行する。緑だ。リファクタリングをしよう。