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
160
依存を意識して安定した変更に強いコードを書こう
良いコードの書き方勉強会 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
880
なぜ、パスワードハッシュのソルトはハッシュと同じ場所に置いて良いのか
akinoriakatsuka
0
410
PHPカンファレンス関西2025 コアスタッフ説明会
akinoriakatsuka
0
87
PHPで物理エンジン(PHPysics)を作ってみた - PHPカンファレンス沖縄2024
akinoriakatsuka
0
140
password_hash に詳しくなりたい - PHPオレカンファレンス
akinoriakatsuka
0
370
composer dump-autoloadを「なんとなく使う」から「理解して使う」になる
akinoriakatsuka
0
3.6k
リバーシを作って学ぶテスト駆動開発
akinoriakatsuka
0
140
OSS Gateに参加したら Larastanに コントリビュートできた - Kobe Laravel
akinoriakatsuka
0
120
知っておきたいautoloadのはなし - PHPカンファレンス関⻄2024
akinoriakatsuka
1
1.8k
Other Decks in Technology
See All in Technology
Tensix Core アーキテクチャ解説
tenstorrent_japan
0
350
(新URLに移行しました)FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
wooootack
0
690
What's new in OpenShift 4.19
redhatlivestreaming
1
220
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
130
基調講演: 生成AIを活用したアプリケーションの開発手法とは?
asei
1
130
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
220
Devin(Deep) Wiki/Searchの活用で変わる開発の世界観/devin-wiki-search-impact
tomoki10
0
300
Amplifyとゼロからはじめた AIコーディング 成果と展望
mkdev10
1
180
今からでも間に合う! 生成AI「RAG」再入門 / Re-introduction to RAG in Generative AI
hideakiaoyagi
1
160
OCI Oracle Database Services新機能アップデート(2025/03-2025/05)
oracle4engineer
PRO
1
140
RubyOnRailsOnDevin+α / DevinMeetupJapan#2
ginkouno
0
300
Snowflake Intelligenceで実現できるノーコードAI活用
takumimukaiyama
1
210
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
480
Docker and Python
trallard
44
3.4k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Bash Introduction
62gerente
614
210k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Speed Design
sergeychernyshev
30
990
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Why Our Code Smells
bkeepers
PRO
337
57k
Embracing the Ebb and Flow
colly
86
4.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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