アジャイルソフトウェア開発の奥義勉強会 4-5章

ロバート・C・マーチン著｢アジャイルソフトウェア開発の奥義｣の勉強会にて使用した資料．

Transcript

1. ΞδϟΠϧιϑτ΢ΣΞ։ൃͷԞٛ ษڧձ ষ ஜ೾େֶ ৘ใϝσΟΞ૑੒ֶྨ೥ ઒ޱ ߤฏ 1
2. ࠓճͷಡΉൣғ • 4章 テスティング • P33-P42 • 5章 リファクタリング • P43-56 2
3. ষ ςεςΟϯά • テスト主導型の開発がプロダクト開発に与える影響について述 べている章である． • 特にプロダクトのコードを書く前にテストコードを書くメリッ トについて述べている 3
4. ςετίʔυΛ࠷ॳʹॻ͘ϝϦοτ • テストが成功する限り，プログラムの変更を気軽に⾏える • 呼び出し側の⽴場からコーディングをするので，呼び出しやすい形 式の設計になりやすい • テストそのものがドキュメントとして機能する • テスト可能な設計を強いられることにより，ソフトウェアの分離が 促進される 4
5. ςετओಋܕιϑτ΢ΣΞ։ൃͷྫ • 未実装なテスト対象が存在することを前提としてテストコードを書く⼿ 法（Intention programing）がある． • ⾃分の意図することをコードを書く前にテストコードの中に記述してお く • このとき，⾃分の意図を単純かつ明瞭にしておくことによって，良い構 造のプログラムが書ける 5 テストを最初に書くことによって，設計上の判断にふるいをかけられる
6. ۩ମྫ • あるゲームの実装におけるテストコードを考えてみる • このゲームは下記のような仕様を持つ • プレイヤーはダンジョンの中を探検する • ダンジョンには複数の部屋が有る • 部屋には東⻄南北それぞに1つ以上の通路があり，その通路は他の部屋と繋 がれいてる 6
7. *OUFOUJPO QSPHSBNNJOHΛ༻͍ͯॻ͍ͨ ςετίʔυ 7 ※ 本書にて記述されているコードに若⼲の修正を加えています
8. ςετίʔυ͕ॏཁͳ໰୊ʹޫΛ͋ͯΔ • 著者はテストコードを書く際にRoomクラスを⽤意する必要は無いと判断をした （数値を⽤いて表現できるから） • Roomクラスを⽤いないことが良い⽅法であることを主張したいわけではない • 最初にテストコードを書くことによって，⾮常に早い段階で設計上の重要な問 題に光を当てた事ができた 8 テストを最初に書くことによって，設計上の判断にふるいをかけられる つまり
9. ιϑτ΢ΣΞʹ෼཭Λڧ͍Δྫ • 給料詳細（Payroll）アプリケーション 9 本書のp36から引⽤
10. ςετίʔυΛॻ͘ࡍͷ໰͍ • 次のような問いが⽣まれる • どのDBを⽤いるか? • どのようなデータを⽤意しておくか? • どのように正しいデータが登録されているかを調べるか? 10 Mock Objectパターンを⽤いよう!
11. .PDL 0CKFDUύλʔϯΛదԠ 11 結果的に周囲のモジュールが分離され設計の質が⾼まった! • Payrollが抽象に依存するように変更 した • モックを⽤いたテストが可能となっ た 本書のp37から引⽤
12. ड͚ೖΕςετ • システム全体の動作確認をするためにはユニットテストだけではな く，受け⼊れテストが必要 • UIテストなどを⾏う場合は，より⾼度な分離が求められるのでアー キテクチャに⼤きな影響を与える • 早期から受け⼊れテストを許容する設計にすることで，分離が促進 される 12 具体例では，XMLにてUIを表現することによりユニットテストを許容するような例があった．→ 設計に影響を与える
13. ষ ·ͱΊ • テストを書くメリット • 動作検証，および保証 • ⼀度あるレベルにて実⾏されれば，それ以降はそのレベルを下回ることはない • コンパイルと実⾏が可能なドキュメントとして機能する． • コンパイルと実⾏が可能なことにより，信頼できる • ⾮常に明確な⾔語にて記述されている． • アーキテクチャや設計に良いインパクトを与える • テスト可能な状態にするためには，対象を周囲から分離する必要がある． • テストしやすくすればするほどその分離性が促進される 13
14. ষ ϦϑΝΫλϦϯά • リファクタリングの意義とリファクタリングを⾏う過程について⽰ している章である． • リファクタリングの定義 • ソフトウェアシステムを変えるプロセスとは，そのコードの外部への振る舞 いを全く変えずににその内部構造を改善すること • 正常に動くコードを改善する必要はあるのか?? 14 正常に動作しているコードをリファクタリングする意味は?
15. Ϟδϡʔϧͷػೳ • モジュールは下記に⽰す3つの（満たすべき）機能がある • 特定の処理を実⾏する機能 • モジュールの存在理由そのもの • 変化を許容する機能 • 変化を簡単にするのは開発者の責任 • 変更が⼤変なモジュールは動いたとしても壊れているのと同義（著者⽈く • 読み⼿にモジュールの意図を伝える機能 • 詳細を知らない⼈であっても無理なく読めるようにする必要がある． • 意図を伝えられないモジュールは動いたとしても壊れているのと同義（著者⽈く 15 モジュールのの読みやすさや変更しやすさを追求するためにリファクタリングしよう
16. ·ͱΊ • リファクタリングの⽬的はコードを⽇々こまめに整理することにあ る • システムの拡張や修正は最⼩限の努⼒で済ませたい • コードが汚ければすべての原則やパターンが全く役に⽴たない 16
17. ಡΜͩײ૝ ষ テストを始めに書く⼿法はテスト駆動開発などから知っていた ⼀⽅で，テストを書くことによって設計が洗礼されるといった視点は無く勉強となった． ষ リファクタリングの概要については今回学ぶことができたが，具体的にリファクタリングを⾏う 際に⽤いる指標が分からなかった．つまり，どのように既存のコードにメスを⼊れると良いかが 分からなかった． 今後の章からそれらを学ぶことができることを期待する． 17
18. Ҿ༻ • ロバート・C・マーチンほか.アジャイルソフトウェア開発の奥義 第 2版 オブジェクト指向開発の神髄と匠の技. SBクリエイティブ, 2008 18