Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アジャイルソフトウェア開発の奥義勉強会 4-5章
Search
k-kohey
June 19, 2019
Programming
0
120
アジャイルソフトウェア開発の奥義勉強会 4-5章
ロバート・C・マーチン著「アジャイルソフトウェア開発の奥義」の勉強会にて使用した資料.
k-kohey
June 19, 2019
Tweet
Share
More Decks by k-kohey
See All by k-kohey
ゲームボーイアドバンスでSwiftを動かそう
k_koheyi
0
1.1k
Swift Package Mangerのバグを直した話
k_koheyi
2
1.5k
swift-async-algorithms...? へえ…面白そうじゃん…?
k_koheyi
3
1.6k
[社内勉強会]Parchment-swiftの実装説明
k_koheyi
0
140
[社内勉強会]Combineの説明
k_koheyi
0
38
あるインスタンスの取る値が 何パターンあるか数えてみるンゴ!
k_koheyi
1
170
Tuistを用いた Xcode Project管理の紹介
k_koheyi
0
220
SwiftでわかるSOLID原則 iOSDC 2020
k_koheyi
3
2.8k
Visitorパターン
k_koheyi
0
200
Other Decks in Programming
See All in Programming
TROCCO×dbtで実現する人にもAIにもやさしいデータ基盤
nealle
0
110
대규모 트래픽을 처리하는 프론트 개발자의 전략
maryang
0
120
AIコーディングエージェント全社導入とセキュリティ対策
hikaruegashira
16
9.8k
LLMOpsのパフォーマンスを支える技術と現場で実践した改善
po3rin
8
920
Vibe coding コードレビュー
kinopeee
0
440
Scale out your Claude Code ~自社専用Agentで10xする開発プロセス~
yukukotani
9
2.1k
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
10
1.7k
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
5
590
Reactの歴史を振り返る
tutinoko
1
180
技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
rvirus0817
1
1.7k
Google I/O recap web編 大分Web祭り2025
kponda
0
2.8k
20250808_AIAgent勉強会_ClaudeCodeデータ分析の実運用〜競馬を題材に回収率100%の先を目指すメソッドとは〜
kkakeru
0
170
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
36
6.8k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
770
KATA
mclloyd
32
14k
Visualization
eitanlees
146
16k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
4 Signs Your Business is Dying
shpigford
184
22k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.6k
Making Projects Easy
brettharned
117
6.3k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
Transcript
ΞδϟΠϧιϑτΣΞ։ൃͷԞٛ ษڧձ ষ ஜେֶ ใϝσΟΞֶྨ ޱ ߤฏ 1
ࠓճͷಡΉൣғ • 4章 テスティング • P33-P42 • 5章 リファクタリング •
P43-56 2
ষ ςεςΟϯά • テスト主導型の開発がプロダクト開発に与える影響について述 べている章である. • 特にプロダクトのコードを書く前にテストコードを書くメリッ トについて述べている 3
ςετίʔυΛ࠷ॳʹॻ͘ϝϦοτ • テストが成功する限り,プログラムの変更を気軽に⾏える • 呼び出し側の⽴場からコーディングをするので,呼び出しやすい形 式の設計になりやすい • テストそのものがドキュメントとして機能する • テスト可能な設計を強いられることにより,ソフトウェアの分離が
促進される 4
ςετओಋܕιϑτΣΞ։ൃͷྫ • 未実装なテスト対象が存在することを前提としてテストコードを書く⼿ 法(Intention programing)がある. • ⾃分の意図することをコードを書く前にテストコードの中に記述してお く • このとき,⾃分の意図を単純かつ明瞭にしておくことによって,良い構
造のプログラムが書ける 5 テストを最初に書くことによって,設計上の判断にふるいをかけられる
۩ମྫ • あるゲームの実装におけるテストコードを考えてみる • このゲームは下記のような仕様を持つ • プレイヤーはダンジョンの中を探検する • ダンジョンには複数の部屋が有る •
部屋には東⻄南北それぞに1つ以上の通路があり,その通路は他の部屋と繋 がれいてる 6
*OUFOUJPO QSPHSBNNJOHΛ༻͍ͯॻ͍ͨ ςετίʔυ 7 ※ 本書にて記述されているコードに若⼲の修正を加えています
ςετίʔυ͕ॏཁͳʹޫΛ͋ͯΔ • 著者はテストコードを書く際にRoomクラスを⽤意する必要は無いと判断をした (数値を⽤いて表現できるから) • Roomクラスを⽤いないことが良い⽅法であることを主張したいわけではない • 最初にテストコードを書くことによって,⾮常に早い段階で設計上の重要な問 題に光を当てた事ができた 8
テストを最初に書くことによって,設計上の判断にふるいをかけられる つまり
ιϑτΣΞʹΛڧ͍Δྫ • 給料詳細(Payroll)アプリケーション 9 本書のp36から引⽤
ςετίʔυΛॻ͘ࡍͷ͍ • 次のような問いが⽣まれる • どのDBを⽤いるか? • どのようなデータを⽤意しておくか? • どのように正しいデータが登録されているかを調べるか? 10
Mock Objectパターンを⽤いよう!
.PDL 0CKFDUύλʔϯΛదԠ 11 結果的に周囲のモジュールが分離され設計の質が⾼まった! • Payrollが抽象に依存するように変更 した • モックを⽤いたテストが可能となっ た
本書のp37から引⽤
ड͚ೖΕςετ • システム全体の動作確認をするためにはユニットテストだけではな く,受け⼊れテストが必要 • UIテストなどを⾏う場合は,より⾼度な分離が求められるのでアー キテクチャに⼤きな影響を与える • 早期から受け⼊れテストを許容する設計にすることで,分離が促進 される
12 具体例では,XMLにてUIを表現することによりユニットテストを許容するような例があった.→ 設計に影響を与える
ষ ·ͱΊ • テストを書くメリット • 動作検証,および保証 • ⼀度あるレベルにて実⾏されれば,それ以降はそのレベルを下回ることはない • コンパイルと実⾏が可能なドキュメントとして機能する.
• コンパイルと実⾏が可能なことにより,信頼できる • ⾮常に明確な⾔語にて記述されている. • アーキテクチャや設計に良いインパクトを与える • テスト可能な状態にするためには,対象を周囲から分離する必要がある. • テストしやすくすればするほどその分離性が促進される 13
ষ ϦϑΝΫλϦϯά • リファクタリングの意義とリファクタリングを⾏う過程について⽰ している章である. • リファクタリングの定義 • ソフトウェアシステムを変えるプロセスとは,そのコードの外部への振る舞 いを全く変えずににその内部構造を改善すること
• 正常に動くコードを改善する必要はあるのか?? 14 正常に動作しているコードをリファクタリングする意味は?
Ϟδϡʔϧͷػೳ • モジュールは下記に⽰す3つの(満たすべき)機能がある • 特定の処理を実⾏する機能 • モジュールの存在理由そのもの • 変化を許容する機能 •
変化を簡単にするのは開発者の責任 • 変更が⼤変なモジュールは動いたとしても壊れているのと同義(著者⽈く • 読み⼿にモジュールの意図を伝える機能 • 詳細を知らない⼈であっても無理なく読めるようにする必要がある. • 意図を伝えられないモジュールは動いたとしても壊れているのと同義(著者⽈く 15 モジュールのの読みやすさや変更しやすさを追求するためにリファクタリングしよう
·ͱΊ • リファクタリングの⽬的はコードを⽇々こまめに整理することにあ る • システムの拡張や修正は最⼩限の努⼒で済ませたい • コードが汚ければすべての原則やパターンが全く役に⽴たない 16
ಡΜͩײ ষ テストを始めに書く⼿法はテスト駆動開発などから知っていた ⼀⽅で,テストを書くことによって設計が洗礼されるといった視点は無く勉強となった. ষ リファクタリングの概要については今回学ぶことができたが,具体的にリファクタリングを⾏う 際に⽤いる指標が分からなかった.つまり,どのように既存のコードにメスを⼊れると良いかが 分からなかった. 今後の章からそれらを学ぶことができることを期待する. 17
Ҿ༻ • ロバート・C・マーチンほか.アジャイルソフトウェア開発の奥義 第 2版 オブジェクト指向開発の神髄と匠の技. SBクリエイティブ, 2008 18