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
Akinori Takigawa
August 16, 2024
Technology
1
200
依存を意識して安定した変更に強いコードを書こう
良いコードの書き方勉強会 in 京都 で発表した資料です
https://kansai-web-app-dev.connpass.com/event/325588/
Akinori Takigawa
August 16, 2024
Tweet
Share
More Decks by Akinori Takigawa
See All by Akinori Takigawa
Rubyで作る物理エンジン - 叡電LT
akinoriakatsuka
0
4
パイプ演算子の実装を覗いてみよう - 【非公式】PHPカンファレンス福岡2025・前日Meetup
akinoriakatsuka
0
3
技術的負債の会計学 - PHPカンファレンス広島2025
akinoriakatsuka
6
1.2k
スクラムをちゃんとやる勇気
akinoriakatsuka
0
24
キャリアを拓く! 登壇のススメ - PHPカンファレンス関西アフターパーティー in スマレジ
akinoriakatsuka
1
130
カンファレンスに参加したあなたが明日からできること
akinoriakatsuka
1
200
DIってなんだか難しい? 依存という概念を「使う・使われる」 という言葉で整理しよう
akinoriakatsuka
2
990
なぜ、パスワードハッシュのソルトはハッシュと同じ場所に置いて良いのか
akinoriakatsuka
0
500
PHPカンファレンス関西2025 コアスタッフ説明会
akinoriakatsuka
0
120
Other Decks in Technology
See All in Technology
巨大モノリスのリプレイス──機能整理とハイブリッドアーキテクチャで挑んだ再構築戦略
zozotech
PRO
0
230
プロダクト負債と歩む持続可能なサービスを育てるための挑戦
sansantech
PRO
1
670
技術広報のOKRで生み出す 開発組織への価値 〜 カンファレンス協賛を通して育む学びの文化 〜 / Creating Value for Development Organisations Through Technical Communications OKRs — Nurturing a Culture of Learning Through Conference Sponsorship —
pauli
5
500
AIと自動化がもたらす業務効率化の実例: 反社チェック等の調査・業務プロセス自動化
enpipi
0
760
Rubyist入門: The Way to The Timeless Way of Programming
snoozer05
PRO
7
540
大規模モノレポの秩序管理 失速しない多言語化フロントエンドの運用 / JSConf JP 2025
shoota
0
300
仕様は“書く”より“語る” - 分断を超えたチーム開発の実践 / 20251115 Naoki Takahashi
shift_evolve
PRO
1
1.1k
持続可能なアクセシビリティ開発
azukiazusa1
6
290
社内外から"使ってもらえる"データ基盤を支えるアーキテクチャの秘訣/登壇資料(飯塚 大地・高橋 一貴)
hacobu
PRO
0
4.6k
レガシーで硬直したテーブル設計から変更容易で柔軟なテーブル設計にする
red_frasco
4
500
Tomcatが起動しない!?SecureRandomと乱数デバイスの罠
fujikawa8
1
110
Building AI Applications with Java, LLMs, and Spring AI
thomasvitale
1
230
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
6.1k
BBQ
matthewcrist
89
9.9k
Site-Speed That Sticks
csswizardry
13
970
Building Applications with DynamoDB
mza
96
6.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
Code Reviewing Like a Champion
maltzj
527
40k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.3k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Typedesign – Prime Four
hannesfritz
42
2.9k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
Code Review Best Practice
trishagee
72
19k
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