4章から5章までの内容を発表した．

1. アジャイルソフトウェア開発の奥義 勉強会
4-5章
筑波大学 情報メディア創成学類4年
川口 航平
1

2. 今回の読む範囲
• 4章 テスティング
• P33-P42
• 5章 リファクタリング
• P43-56
2

3. 4章 テスティング
• テスト主導型の開発がプロダクト開発に与える影響について述
べている章である．
• 特にプロダクトのコードを書く前にテストコードを書くメリッ
トについて述べている
3

4. テストコードを最初に書くメリット
• テストが成功する限り，プログラムの変更を気軽に⾏える
• 呼び出し側の⽴場からコーディングをするので，呼び出しやすい形
式の設計になりやすい
• テストそのものがドキュメントとして機能する
• テスト可能な設計を強いられることにより，ソフトウェアの分離が
促進される
4

5. テスト主導型ソフトウェア開発の例
• 未実装なテスト対象が存在することを前提としてテストコードを書く⼿
法（Intention programing）がある．
• ⾃分の意図することをコードを書く前にテストコードの中に記述してお
く
• このとき，⾃分の意図を単純かつ明瞭にしておくことによって，良い構
造のプログラムが書ける
5
テストを最初に書くことによって，設計上の判断にふるいをかけられる

6. 具体例
• あるゲームの実装におけるテストコードを考えてみる
• このゲームは下記のような仕様を持つ
• プレイヤーはダンジョンの中を探検する
• ダンジョンには複数の部屋が有る
• 部屋には東⻄南北それぞに1つ以上の通路があり，その通路は他の部屋と繋
がれいてる
6

7. Intention programmingを用いて書いた
テストコード
7
※ 本書にて記述されているコードに若⼲の修正を加えています

8. テストコードが重要な問題に光をあてる
• 著者はテストコードを書く際にRoomクラスを⽤意する必要は無いと判断をした
（数値を⽤いて表現できるから）
• Roomクラスを⽤いないことが良い⽅法であることを主張したいわけではない
• 最初にテストコードを書くことによって，⾮常に早い段階で設計上の重要な問
題に光を当てた事ができた
8
テストを最初に書くことによって，設計上の判断にふるいをかけられる
つまり

9. ソフトウェアに分離を強いる例
• 給料詳細（Payroll）アプリケーション
9
本書のp36から引⽤

10. テストコードを書く際の問い
• 次のような問いが⽣まれる
• どのDBを⽤いるか?
• どのようなデータを⽤意しておくか?
• どのように正しいデータが登録されているかを調べるか?
10
Mock Objectパターンを⽤いよう!

11. Mock Objectパターンを適応
11
結果的に周囲のモジュールが分離され設計の質が⾼まった!
• Payrollが抽象に依存するように変更
した
• モックを⽤いたテストが可能となっ
た
本書のp37から引⽤

12. 受け入れテスト
• システム全体の動作確認をするためにはユニットテストだけではな
く，受け⼊れテストが必要
• UIテストなどを⾏う場合は，より⾼度な分離が求められるのでアー
キテクチャに⼤きな影響を与える
• 早期から受け⼊れテストを許容する設計にすることで，分離が促進
される
12
具体例では，XMLにてUIを表現することによりユニットテストを許容するような例があった．→ 設計に影響を与える

13. 4章 まとめ
• テストを書くメリット
• 動作検証，および保証
• ⼀度あるレベルにて実⾏されれば，それ以降はそのレベルを下回ることはない
• コンパイルと実⾏が可能なドキュメントとして機能する．
• コンパイルと実⾏が可能なことにより，信頼できる
• ⾮常に明確な⾔語にて記述されている．
• アーキテクチャや設計に良いインパクトを与える
• テスト可能な状態にするためには，対象を周囲から分離する必要がある．
• テストしやすくすればするほどその分離性が促進される
13

14. 5章 リファクタリング
• リファクタリングの意義とリファクタリングを⾏う過程について⽰
している章である．
• リファクタリングの定義
• ソフトウェアシステムを変えるプロセスとは，そのコードの外部への振る舞
いを全く変えずににその内部構造を改善すること
• 正常に動くコードを改善する必要はあるのか??
14
正常に動作しているコードをリファクタリングする意味は?

15. モジュールの機能
• モジュールは下記に⽰す3つの（満たすべき）機能がある
• 特定の処理を実⾏する機能
• モジュールの存在理由そのもの
• 変化を許容する機能
• 変化を簡単にするのは開発者の責任
• 変更が⼤変なモジュールは動いたとしても壊れているのと同義（著者⽈く
• 読み⼿にモジュールの意図を伝える機能
• 詳細を知らない⼈であっても無理なく読めるようにする必要がある．
• 意図を伝えられないモジュールは動いたとしても壊れているのと同義（著者⽈く
15
正常に動いていても壊れているからリファクタリングしようねって事だと思う．

16. リファクタリングをする意義
• リファクタリングの⽬的はコードを⽇々こまめに整理することにあ
る
• システムの拡張や修正は最⼩限の努⼒で済ませたい
• コードが汚ければすべての原則やパターンが全く役に⽴たない
16
正常に動作しているコードをリファクタリングする意味は?

17. 読んだ感想
4章
テストを始めに書く⼿法はテスト駆動開発などから知っていた
⼀⽅で，テストを書くことによって設計が洗礼されるといった視点は無く勉強となった．
5章
リファクタリングの概要については今回学ぶことができたが，具体的にリファクタリングを⾏う
際に⽤いる指標が分からなかった．つまり，どのように既存のコードにメスを⼊れると良いかが
分からなかった．
今後の章からそれらを学ぶことができることを期待する．
17

18. 引用
• ロバート・C・マーチンほか.アジャイルソフトウェア開発の奥義 第
2版 オブジェクト指向開発の神髄と匠の技. SBクリエイティブ, 2008
18