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
依存を意識して安定した変更に強いコードを書こう
Search
akatsuka
August 16, 2024
Technology
0
170
依存を意識して安定した変更に強いコードを書こう
良いコードの書き方勉強会 in 京都 で発表した資料です
https://kansai-web-app-dev.connpass.com/event/325588/
akatsuka
August 16, 2024
Tweet
Share
More Decks by akatsuka
See All by akatsuka
DIってなんだか難しい? 依存という概念を「使う・使われる」 という言葉で整理しよう
akinoriakatsuka
1
890
なぜ、パスワードハッシュのソルトはハッシュと同じ場所に置いて良いのか
akinoriakatsuka
0
420
PHPカンファレンス関西2025 コアスタッフ説明会
akinoriakatsuka
0
92
PHPで物理エンジン(PHPysics)を作ってみた - PHPカンファレンス沖縄2024
akinoriakatsuka
0
140
password_hash に詳しくなりたい - PHPオレカンファレンス
akinoriakatsuka
0
380
composer dump-autoloadを「なんとなく使う」から「理解して使う」になる
akinoriakatsuka
0
3.7k
リバーシを作って学ぶテスト駆動開発
akinoriakatsuka
0
150
OSS Gateに参加したら Larastanに コントリビュートできた - Kobe Laravel
akinoriakatsuka
0
130
知っておきたいautoloadのはなし - PHPカンファレンス関⻄2024
akinoriakatsuka
1
1.8k
Other Decks in Technology
See All in Technology
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
260
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
2
670
shake-upを科学する
rsakata
7
800
【LT会登壇資料】TROCCO新コネクタ「スマレジ」を活用した直営店データの分析
kazari0425
1
110
衛星運用をソフトウェアエンジニアに依頼したときにできあがるもの
sankichi92
1
160
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
440
ビギナーであり続ける/beginning
ikuodanaka
3
790
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
180
PO初心者が考えた ”POらしさ”
nb_rady
0
220
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
440
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
1
130
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
Balancing Empowerment & Direction
lara
1
440
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Building an army of robots
kneath
306
45k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Why Our Code Smells
bkeepers
PRO
336
57k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Transcript
依存を意識して安定した 変更に強いコードを書こう 良いコードの書き方勉強会 in 京都 2024/8/17 あかつか
自己紹介 • あかつか X: aki_artisan • 神戸でPHP書いてます • レガシーPHPをLaravelに移植 •
PHPカンファレンス関西2025実行委員長 2
そもそも良いコードとは? • 読みやすいコード • 保守しやすいコード • 変更しやすいコード • パフォーマンスが良いコード •
安全なコード • バイト数が少ないコード(コードゴルフではね) 3
つまり、良いコードとは? • 読みやすいコード • 保守しやすいコード • 変更しやすいコード • パフォーマンスが良いコード •
安全なコード • バイト数が少ないコード(コードゴルフではね) 目的を満たすコード 4
ソフトウェア開発において良いコードとは? • 自社プロダクトか受託で作るシステムなのかにもよる ◦ 仕様が変化しづらく、再現性を求められる? ◦ 環境に適用して柔軟に振る舞いを変えていくことが求められる? ◦ パフォーマンス最優先? 目的によって、良いコードは異なる
自分たちで考えていくことが大事 5
今回は自社プロダクト開発の文脈で話します プロダクト開発にはアジリティが求められる 作ったものが正しいとは限らない 頻繁に機能拡張や、仕様変更、バグ修正、リファクタリングが行われる 6
変更しやすく保つ必要がある アジリティを失わないようにするためには、 変更しやすく保つ必要がある • テストコードを書く • 疎結合な状態を保つ • こまめにリファクタリングする 7
変更しにくくなる原因は? • 影響範囲がわからない • 複数の責務をもつクラスやメソッド、関数がある • 大事なところほど、手が入りやすくどんどん複雑になっていく 依存関係が複雑になっている 8
「依存」をキーワードに考えてみよう 9
「依存」ってなんだか難しい? AがBに依存している→ピンとこない 大胆に「AがBを使っている」と言い換えよう! AがBを使っている。Bがないと機能しない。AはBに依存している。 AはBを使っている。だから、Bの変更の影響を受ける。 10
11
依存しているとは使っているということ 12
「AがBに依存ている」とは A B AがBを使っている状態 13
例:「ユーザー登録機能がメール送信機能を使っている」 ユーザー 登録機能 メール送信 機能 AがBを使っている状態 14
依存すると何が困るのか 15
依存すると変更の影響をうける(A視点) A B AがBを使っている状態 変更 影響が 波及 16
依存されると変更しづらくなる(B視点) 共通モジュールを変更したら、いろいろなところでバグが波及した! A B AがBを使っている状態 変更し づらい 17
実際のプロダクト開発では 実際の世界では、依存先(われわれが使うもの)は外部のものだったりする メリットの方が大きいので依存することを選んでいるとも言える わたしたちの プロダクト Laravel PHP 18
実際のプロダクト開発では わたしたちの プロダクト Laravel PHP LaravelやPHPのバージョンアップに振り回されるのはこのため だからこそ、できるだけ安定なものに依存したい → 依存注入というアプローチが一役買う 19
実演:依存性を注入してみよう 20
最初の状態 ログ出力処理が べた書き ログ出力の仕様を変えたい時、毎回全ての箇所で変更しないといけない 21
level1 : ログ出力を外部に委譲 ログ出力処理を 切り出した 22
level1 : ログ出力を外部に委譲 ログ出力処理を 切り出した 直接ロガーを 使っている 23
level2 : ログ出力用クラスを外から与える どのロガーを使うかを 外から与えるようにした ログ出力機能との結合が疎になった 24
level2 : ログ出力用クラスを外から与える どのロガーを使うかを 外から与えるようにした ログ出力機能との結合が疎になった 25
level3 : ログ出力用のインターフェースに依存させる logメソッドを 持てば良い (抽象化) 26
level3 : ログ出力用のインターフェースに依存させる logメソッドを 持てば良い (抽象化) 27 抽象に依存するとより安定に
依存を外から与えるメリット 28
依存を外から与えると差し替えることができる • テストがしやすい ◦ 例えばテストの時はログ出力をオフにしたい、などの場合、 logメソッドの実装が空のモックで置き換 えるなどで、安全にテストが行える ◦ 時間がかかる、お金がかかる、副作用が許容できない、など様々なパターンに対応できる •
拡張性が上がる ◦ 既存の部分に影響を与えることなく、別の実装を使うように差し替えることが可能 • 依存関係が追いやすい 29
良いコードの書き方 30
良いコードを書くには依存を意識する • 変更しづらいコードはビジネスとして価値を産みづらい • 無自覚な依存はコードを変更しづらくする • 「これに依存して大丈夫?」「これはどのくらい安定?」と問いかける • 依存しないといけない時は、依存を外から与えるようにする ◦
コンストラクタ経由で与える ◦ Laravelだと、サービスコンテナを使うなど 31
おすすめ資料① https://speakerdeck.com/blue_goheimochi/phperkaigi2024 32
おすすめ資料② なぜ依存を注入するのか DIの原理・原則とパ ターン (Compass Booksシリーズ) 33
まとめ • 依存とは使っている ということ • 変更の影響を受けないように、安定なものに依存しよう • 依存を外から与える ようにすると疎結合になる(依存注入) •
何が何を使っているかを意識してプログラミングしよう • 依存する時は、「それはどのくらい安定?」 を考えるようにしよう 34