ボブおじさんの名著『アジャイルソフトウェアの奥義』を読み返しながら感想などをつらつらと書き連ねる、その3。

【読書記録】アジャイルソフトウェア開発の奥義 (1)
【読書記録】アジャイルソフトウェア開発の奥義 (2)

第5章 リファクタリング

エラトステネスの篩というアルゴリズムを使って素数を作るプログラムを題材に、少しずつリファクタリングしていく様子を実演する章。

リファクタリングは食後のキッチンを片付けるようなものだ。最初は後片付けをしなければ、それだけ食事時間は短くて済む。しかし、片付けておかないと、翌日の食事の用意をするときにもっと時間がかかってしまう。

『アジャイルソフトウェア開発の奥義』（第5章, p. 55）

第6章 プログラミングエピソード

50ページ近くある長い章。ボブおじさんことBob Martinと、同僚(?)のBob Koss、二人のボブによるペアプログラミングの実演だ。筆者によると、実際に行われた内容をできる限り忠実に再現したとのこと。

題材はボウリングゲームのスコア集計。最初に二人はゲーム、フレーム、投球というドメインオブジェクトからなる簡単なクラス図を書いて、投球クラスからテストファーストで書いていこうとするが、投球(Throw)クラスには振舞いを持たせるべきなのか、単なる整数でもいいのではないのか、という疑問からフレーム(Frame)クラスの実装に切り替える。さらに途中からゲーム(Game)クラスの実装に切り替える。

Gameクラスの実装は、もっとも簡単なテストケースから始めて、スペアのケース、ストライクのケース、最終フレームのケースなど徐々に複雑なケースを実装していく。レッド、グリーン、リファクターのリズムで、まずは動作するコードを書いて、きれいなコードに仕上げていく。

リファクタリングの過程で、ボブおじさんは、あるロジックを以下の擬似コードのようにするといいんじゃないかと提案する。

if strike
  score += 10 + nextTwoBalls();
else if spare
  score += 10 + nextBall();
else
  score += towBallsInFrame()

ボブおじさん「なんてこった！　これはほとんどボウリングゲームのルールそのものだね。」

最終的に完成したコードは、Game と Scorer 二つのクラスから構成される。Scorer はスコアの計算を担当するオブジェクトとして、途中で導入されたものだ。

始めにクラス図でスケッチした、ゲーム、フレーム、投球という概念の静的な構造は間違っていない。今回のアプリケーションの解決領域のモデルとしてはふさわしくなかった、あるいは過剰であったというだけである。その構造よりはむしろ、先ほどの擬似コードで表現されるビジネスルール（ボウリングゲームのルール）が、コードで正しく、わかりやすく表現されていることが重要である。

以下は本性の結論からの引用。

しかし、ダイアグラムを作ったからといって、それが最良の設計だと思い込んでしまってはいけない。最良の設計というものは、テストを最初に用意し、小さなステップを繰り返すことで展開されていくものなのだ。

（第5章, p. 101）

この第6章は本当に素晴らしく、写経して手を動かしてみるのがおすすめ。
あまりに素晴らしいので社内の勉強会でも紹介をした。以下はその資料。