第1回　XPな開発者の1日：快適なXPドライビングのすすめ（1）（2/2 ページ）

[縣俊貴, 橋本正徳, Project Mobster（メディアファイブ株式会社），＠IT]

■7:00

　起床。今日は会社でどんな楽しいことをやろうかな。XPではその日の仕事を次の日に繰り越さないから、朝はだいたい気分良く出勤できる。あこがれのM子ちゃんとペアになれたらいいな。

■9:00　【Ant】

　出社。ブラウザを起動して、【Ant】の自動ビルドによるユニットテストの結果を見てみる。すべて緑のバー、278個のテストすべて成功しているみたいだ。プロジェクトは今日も万事快調。

■9:05 【Wiki】

　今回のプロジェクトでは情報共有に【Wiki】を利用している。共有文書はすべてWiki上で一元的にまとめられている。Wikiの文書は自動的にリンクされ、常に更新可能だ。コピーの山で文書のバージョンの違いで悩むことはない。

　Wiki上にはデータベースのパフォーマンスに関する調査結果が上がっていた。今回、データベースはMySQLではなくPostgreSQLを利用することになりそうだ。どちらにしろデータベースに対応するのはかなり先になる。しばらくはファイルベースでプロジェクトをドライブしていく。

■9:15

　毎朝定例のスタンドアップミーティング。立ったままのミーティングはみんな早く切り上げたいので、無駄が少なく結論が出やすい。例えは悪いが、高校のときの数学教師Sと同じやり方だ。しかし、たった15分間でも、毎日メンバーと顔を会わせ言葉を交わすことが、ここまでプロジェクトを円滑にするとは、いままで気付かなかったな。

■9:30　【B6サイズの紙】【プリンタ内蔵のホワイトボード】

　今日最初の仕事は、

• 「プロジェクト：商品管理システム」における
• 「ストーリー：商品番号・商品種別・商品名・価格で検索が実行できる」の
• 「タスク：検索処理オブジェクトの作成」

だ。ストーリーとタスクは【B6サイズの紙】に記述されている。この紙は隣の部屋の「ヘビーウェートプロセスチーム」が大量に生み出した古いドキュメントを裁断して作った。こりゃあと100年分は困らないな。

　検索の実装方法をペアの橋本君と【プリンタ内蔵のホワイトボード】を使って簡単にミーティングを行う。簡単なクラス図と説明を書いて1部だけ印刷。2部印刷なんて無駄なことはしない。クラス図をタスクカードにホッチキスで添付する。

■10:00　【Eclipse】【CVS】【CVS for NT】

　1台のマシン、1つのキーボードによるペアプログラミング。最初にドライバーになったのは橋本君、僕はパートナーだ。そして交代の合図は「交代しようか？」。

　XPにおける最大の特徴の1つはペアプログラミング。コーディングを2人で行うのだ。こいつのおかげで、仕事中にメールチェックしたりサイトを見て回ったりできなくなった（やっちゃいけないんだけどやっちゃうよな）。だけど、1人でプログラミングしていたときは、ケアレスミスで何日も何日もバグに苦しんだり、自己満足でしかないようなプログラムをずっと書いていたりして効率的じゃなかったな。いまはコードレビューと同時進行でプログラミングしているようなものだし、相棒がいるということは心強い。

　まずはJavaの開発環境【Eclipse】を起動。前日のモジュールの未取得分を【CVS for NT】サーバより取り出す。Eclipseの【CVS】機能は簡単だ。同期の機能で全モジュールを最新の状態に更新した。1番上のパッケージにある「AllTests」クラスを実行して、モジュールの状態を見る。緑のバーがのびる。278個のテストすべて成功を確認。万事快調だ。

■10:10　【JUnit】

　コーディングはテストファーストに従ってテストケースから作成する。まずは検索オブジェクトのテストケースを作成。これもEclipseに内蔵されたテスティングフレームワーク【JUnit】を使う。

　僕はXP開発以前からテストケースを使っている。ウォーターフォール開発の中にいても実践できる項目だ。

　テストはコーディングの際のゴールになるが、さらに将来にわたって大変重宝する。「機能拡張」「仕様変更」「プロジェクトの肥大」などのときにクラス1つ1つにコードレベルで現在の仕様が付いているわけだ。これはプログラマにとって大きな自信と安心感をくれる。僕らはテスト熱中性だ。

　テストをまず書く。コンパイルエラー。検索オブジェクトクラスをまだ書いていないので当然だな。Eclipseの場合、エラー項目をクリックするだけで、空っぽのスケルトンメソッドが自動的に作られる。あとはペアでコードを書いていく。取りあえずのゴールは「テストに通ること」だ。

■12:00

　昼食。みんなで出掛ける。プロジェクトメンバーは大変仲がよい。これもペアプログラミングのおかげかな。

■13:00

　検索オブジェクトが完成したので、テストを走らせる。赤いバーがのびる。テスト失敗、検索条件のマッチング判定メソッドだ。ステップ実行すると条件が逆だったことが判明。4つの目で見逃したミスも、テストは見逃さない。修正して再びテストを実行。緑のバーがのびる。テストに通ったのでCVSにコミットする。

■13:30

　10分くらいの休憩を取るか。お互い同意のうえでの休憩だ、心置きなく休憩できる。

■15:00　【cactus】

　同じく「タスク：検索条件を取得し検索を行う」が完成。クラス名はSearchServletだ。これもサーブレットテスティングフレームワーク【cactus】を使ってテスト。テストに通ったのでコミット。

■15:30　【結合用マシン】

　一連の検索処理の流れが完成したので、結合用マシンへ移動して結合テスト。１日に何度も結合テストを行うのもXPの特徴だ。何度も結合するので結合専用のマシンを1台確保している。緑のバーがのびる。312個のテストすべて成功。ほっと胸をなで下ろす。ここで失敗したらコミットした僕らのモジュールが原因だからだ。検索処理がきちんと動作しているのも確認した。

　そういえば前はだいたい納期ごろ（！）に結合テストしてたっけ、ほろ苦い思い出だ。タスクが完了したご褒美に、橋本君の持ってきたビタースイートチョコレートをこっそり奪ってほおばる。うまいなぁ、この瞬間のために頑張っているなぁ。

■16:00

　テストは成功したが、クラスの精度を上げるためにリファクタリングをすることにした。

　リファクタリングで可読性を高くしたり、仕様変更時や機能拡張時などでも安全なように、ソースを保っていく。後々手の付けられない爆弾を抱え込まないようにするためでもある。以前、僕はうかつにも爆弾を爆発させた経験があるので、リファクタリングは絶対に欠かさない。あのときは人にソースを見られるの、恥ずかしかったな。

　Eclipseを使ってのリファクタリングは実に簡単だ。「メソッドの抽出」「変数名の変更」などをサクサクと進め、その間に何度かテストを走らせた。おや？ M子ちゃんたちが作っていたクラスにコーディング規約と違うメソッド名が……。それも、修正してコミット。本当に【CVS】って便利だ。コードは共有である。みるみるうちにきれいなコードに洗練された。ペアで納得のいくコードの出来上がりだ。

■18:00

　最後にテストをもう一度走らせる。みるみる緑のバーがのびる。334個のテストにすべて成功。万事快調。週40時間。ペアでプログラミングをするのは意外と疲れる。人の集中力はそれほどタフではない。今日も、ここで仕事をきっぱりと終えることにする。橋本君は昨夜の奥さんとのけんかが気になってるようだ。「帰って家族と楽しく食事でもしよう」。コレで彼の家庭も円満だ。残業が原因で家庭崩壊になっては本末転倒だ。さて、僕も近くのバーにだれかさんを誘って飲みに行こう。

■終わりに

　今回はモノローグタッチでXP開発者の1日を紹介しました。連載の第2回以降は実践的な内容になります。

　第2回は 「CVS：コードの共同所有」と題して、CVSを利用したコードの共同所有の方法とその効果をご紹介します。CVSを利用するための環境なども併せて解説します。お楽しみに！