第1回　XPな開発者の1日


縣俊貴
橋本正徳
Project Mobster／メディアファイブ株式会社

2002/12/20

---

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個のテストすべて成功を確認。万事快調だ。

同期の機能で全モジュールを最新の状態に更新した

コラム：ペアプログラミングとは

ペアプログラミングとは、すべてのコードを2人一組作成していく手法です。XPのプラクティスの中でも最も、なじみにくいプラクティスかもしれません。ペアプログラミングには次のメリットがあります。 【コードの品質が上がる】　すべてのコードに対し、絶えずレビューを行っているのでコードの品質は上がります。 【開発速度が上がる】　コード品質が高まるので、開発速度は上がります。また、コミュニケーションが高まるので、問題解決にかかる時間が短縮されて、開発速度が上がります。これは不思議な現象です。1人1人で作業していたときより、確実に効率がよくなります。 【プロジェクトのリスクが減少する】　1つのコードを最低2人の人間がよく知っています。メンバーの1人が病気になって入院しても、もう1人がそのコードのことをよく知っているのです。また上記2つのメリット、「コードの品質が上がる」「開発速度が上がる」のでリスクが減少します。

10:10　【JUnit】

　

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

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

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

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

コラム：テストファーストとは

テストファーストとは実行コード（メソッド）を書く前に、そのテストコード を先に書くという手法です。テストファーストには次のメリットがあります。 テストを先に書くことで、振る舞いを明確にすることができる テストを先に書けないということは、そのコードが何をすべきかまだ理解していないということです。 テストを先に書くことで、シンプルになる テストを先に書けば、テストに通るための必要最低限の実行コードを書くようになります。このことにより、コードをシンプルかつきれいに保つことができます。 テストを先に書くことで、自信が持てる テストファーストにより、テストを書かないという行為を防止できます。全てのコードにテストが用意してあれば、大きな自信になります。自信・勇気がXPを成功に導く要素です。 テストを先に書くことで、ドキュメントを作成する必要がない 優れたテストは最高のドキュメントです。紙でかかれた、ソースに対するドキュメントなどすぐに古くなってしまいます。テストはコードと共に成長していくので、これを最初から書かない手はありません。

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を利用するための環境なども併せて解説します。お楽しみに！

【関連記事】
Eclipseを使おう！（1） オープンソースのEclipseは仕事に使える開発環境

INDEX
快適なXPドライビングのすすめ 第1回 XPな開発者の1日
	Page 1 ■はじめに ■本連載の目的 ■本連載の予定 ■本連載の対象読者
	Page 2 ■7:00〜18:00 ■終わりに

　

　

---

【用語集】

【Ant】
Javaのビルドツール。テスティングの結果をHTML出力する機能があります。　
Apache Jakarta Project-http://jakarta.apache.org/ant/index.html

【JUnit】
テスティングを行うためのフレームワークです。
JUnit.org-http://www.junit.org/

【cactus】
Servletのテストを行うためのフレームワークです。
Apache Jakarta Project-http://jakarta.apache.org/cactus/

【CVS】
バージョン管理システムです。
CVS Home-http://www.cvshome.org/
CVS for NT-http://www.cvsnt.org/

【Eclipse】
オープンソースのJava開発環境です。
Eclipse.org-http://www.eclipse.org/

【Wiki】
Webベースの情報共有ツールです。
WikiWikiWeb-http://c2.com/cgi/wiki
JavaベースのWikiです。
MobWiki-http://www.mobster.jp/wiki/index.jsp

【リファクタリング】
現存コードを効率よく変更する方法のことです。コードをより良い状態に安全に変更することができます。『リファクタリング〜プログラミングの体質改善テクニック〜』（ピアソン・エデュケーション）Ｍ・ファウラー 著。http://www.pearsoned.co.jp/washo/object/wa_obj25-j.html

---

プロフィール

縣俊貴（あがた　としたか） 　メディアファイブ株式会社所属。XML,フレームワークを中心に開発業務に携わる。Javaのコミュニティー団体であるMobsterを主催。現在MonsterにてJavaベースのWikiシステム「MobWiki」を開発している。 橋本正徳（はしもと　まさのり） 　メディアファイブ株式会社所属。XML、フレームワーク等の開発業務に携わる。Javaのコミュニティー団体である「Mobster」を縣と共に発起、運営。現在mobsterにてバグトラッキングシステム「mobbug」等を開発している。「日本XPユーザーグループ関西支部 九州分科会」にも参加。ちなみにこの記事自身もCVSでバージョン管理し、縣と橋本とで共同所有されて書かれている。 Project Mobster（ぷろじぇくと もぶすたー） 福岡県福岡市を中心にJava言語を研究追求し、その成果物をWeb上に公開していく団体です。年齢・スキル・会社などを超えてボーダーレスに活動しております。

IT Architect 連載記事一覧