Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
依存を意識して安定した変更に強いコードを書こう
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Akinori Takigawa
August 16, 2024
Technology
270
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
依存を意識して安定した変更に強いコードを書こう
良いコードの書き方勉強会 in 京都 で発表した資料です
https://kansai-web-app-dev.connpass.com/event/325588/
Akinori Takigawa
August 16, 2024
More Decks by Akinori Takigawa
See All by Akinori Takigawa
Nginxになりきって、FCGIでPHPと喋ろう
akinoriakatsuka
0
120
PHPUnitのテストイベントを使ってテストにかかる時間の計測をしよう
akinoriakatsuka
0
210
パイプ演算子の実装を 覗いてみよう
akinoriakatsuka
0
270
PHPでCQRS+ES入門
akinoriakatsuka
0
240
手軽に作れる電卓を作って イベントソーシングに親しもう CQRS+ESカンファレンス2026
akinoriakatsuka
0
1.1k
Rubyで作る物理エンジン - 叡電LT
akinoriakatsuka
0
53
パイプ演算子の実装を覗いてみよう - 【非公式】PHPカンファレンス福岡2025・前日Meetup
akinoriakatsuka
0
56
技術的負債の会計学 - PHPカンファレンス広島2025
akinoriakatsuka
8
1.6k
スクラムをちゃんとやる勇気
akinoriakatsuka
0
77
Other Decks in Technology
See All in Technology
TinyGo 開発サイクルを高速化する:Go で作るエミュレータ入門
zozotech
PRO
1
630
AIとペアプロを始める。人とのペアプロをやめる。ペアプロの良さを改めて知る。もっと好きになった。 / Rediscovering Pair Programming
honyanya
1
340
2026-09-10 【Snowflake World Tour Tokyo 2026】dbt Core と Snowflake で実現する多層的なデータガバナンス / Multi-Layered Data Governance Powered by dbt Core and Snowflake
civitaspo
0
330
作品が生態系になった ─ Mini Tokyo 3D から世界へ
nagix
0
150
AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する
nwiizo
8
7.9k
こんなアーキテクチャ図は嫌だ BEYOND THE TIME: 半年後の自分へ贈る15のメッセージ / 15 of Anti-pattern in AWS Architecture Diagrams
naospon
3
310
作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話
kinosuke01
0
310
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
220
AI-DLCって実際どう? 〜聞きたいこと全部聞いてみる〜
news_it_enj
0
260
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
280
Snowflakeで実現する全社横断の顧客の声(VOC)分析・活用基盤@Snowflake World Tour Tokyo 2026
yuto16
0
180
Sigmaで作る業務アプリ
kazushiro_honma
0
120
Featured
See All Featured
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
68
57k
Accessibility Awareness
sabderemane
1
210
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
450
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
GitHub's CSS Performance
jonrohan
1033
470k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.8k
Documentation Writing (for coders)
carmenintech
77
5.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
Designing Experiences People Love
moore
143
24k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
270
The SEO Collaboration Effect
kristinabergwall1
1
550
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