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
OOC2024 登壇資料
Search
Hiromi Kai
April 02, 2024
Programming
0
150
OOC2024 登壇資料
(株)タイミーのスポンサーセッションとして発表したものです。
Hiromi Kai
April 02, 2024
Tweet
Share
More Decks by Hiromi Kai
See All by Hiromi Kai
#kaigieffect LT大会 at RubyKaigi2024 登壇資料
hiromikai
0
120
西区プログラミング勉強会発表資料
hiromikai
0
71
Other Decks in Programming
See All in Programming
より安全で効率的な Go コードへ: Protocol Buffers Opaque API の導入
shwatanap
2
740
知っているようで知らない"rails new"の世界 / The World of "rails new" You Think You Know but Don't
luccafort
PRO
1
190
AI時代のUIはどこへ行く?
yusukebe
18
9.1k
🔨 小さなビルドシステムを作る
momeemt
4
690
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
120
How Android Uses Data Structures Behind The Scenes
l2hyunwoo
0
480
testingを眺める
matumoto
1
140
はじめてのMaterial3 Expressive
ym223
2
900
AIコーディングAgentとの向き合い方
eycjur
0
280
Zendeskのチケットを Amazon Bedrockで 解析した
ryokosuge
3
320
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.5k
複雑なドメインに挑む.pdf
yukisakai1225
5
1.2k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Thoughts on Productivity
jonyablonski
70
4.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
The Invisible Side of Design
smashingmag
301
51k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Context Engineering - Making Every Token Count
addyosmani
3
58
The Power of CSS Pseudo Elements
geoffreycrofte
77
6k
Code Review Best Practice
trishagee
71
19k
Facilitating Awesome Meetings
lara
55
6.5k
A designer walks into a library…
pauljervisheath
207
24k
Speed Design
sergeychernyshev
32
1.1k
Transcript
2024/03/24 甲斐 宏味 俺のオブジェクト指向開発のベストは この程度なんだろうか
目次 • 自己紹介 • 会社紹介 • 設計を振り返る
1 自己紹介
自己紹介 名前:甲斐 宏味(かい ひろみ) 所属:エンジニアリング本部 プロダクトエンジニアリング部 職種:バックエンドエンジニア(Rails) 経歴:SE → (転職失敗して紆余曲折)
→ Webスタートアップ数社 → タイミー SNS:やってますが技術の話はしません 得意:仕事やMTGが連続しているときに周囲に腹が減ったと言うこと 苦手:CLIでgit diffを読むこと
おことわり 本資料にはタイミー以前の経験を元にした内容が含まれていますが、 当時の内容を元に一部変更を加えています。
2 会社紹介
7
タイミーの実績 スキマ バイト No.1 ※2024年2月時点 ※1 [調査方法]インターネット調査 [調査期間]2021年2月9日~11日 [調査概要]スキマバイトサービスの実態調査 [調査対象]直近1年以内にスキマバイトを経験したことのある18〜69歳の男女1034名[調査実施]株式会社マクロミル 8
利用率・リピート率 ※1 導入事業者数 98,000企業 ワーカー数 700万人
9
10
3 設計を振り返る
皆さんは良い設計、できていますか? 私はできてません。
よい設計ってなんだろう? - オブジェクト指向の原則に従う - SOLID原則 - 単一責任の原則 - オープン・クローズドの原則 -
リスコフの置換原則 - インターフェース分離の原則 - 依存性逆転の原則 - デメテルの法則 - 構造化設計 - 凝集度を高く、結合度を低く
デメテルの法則 - 自分以外の振る舞いや実装などに関して持っている知識を最小にする - この法則に従うとメソッドチェーンがアンチパターンになる - Rails自体が自然とデメテルの法則に反する実装やりがち - ActiveRecordによるDB操作なんて何から何まで違反している -
自前で作ったクラスも、丁寧に相互関係を整理しないと暗黙的な呼び出しを やりがち
Serviceクラスの落とし穴 - 自分が見てきたRailsを採用しているサービスはみんなServiceクラスを採用 していた - Service間の依存関係を理解するのが難しい - 本来密結合させないといけない概念が無駄に分かれることがある - 凝集度の低下
- 業務を構成するためにはどのServiceを組み合わせたらいいの?という問いの 正解が誰もわからなくなるときがある
以前経験した設計の失敗 - 在庫管理のSaaS - 出荷に関するService設計 - ここでの出荷に関する定義 - 出荷は完了したか否かの状態を持つ -
1つの出荷には複数の出荷品目が存在する - 出荷品目も状態を持つ - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する - 出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ 出荷Service
出荷Serviceの多義化による失敗 1. Serviceの依存関係が整理できなくて、ある外部サービスを追加する際に呼び 出すクラスを間違えた - 出荷Serviceの一部の呼び出し先だけを呼び出してしまい、「出荷」が正しく完了していない 状態だった 2. 時と場合によって「出荷とは何か」の定義がブレた -
提携する外部サービスの追加に伴い、出荷にまつわるチャネルが増えた - 「ある流入元限定で通知を飛ばさないで欲しい」という要望 - 外部サービスによって出荷品目の分納ができたりできなかったりする
失敗1:Serviceの依存関係が整理できなくて、 ある外部サービスを追加する際に呼び出しクラスを間違えた - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する
- 出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ - 外部サービスのCSVから出荷を読み込む - DBの出荷と突き合わせる - 出荷品目でループする - 在庫減らすServiceを呼び出す - 外部サービスのCSVから出荷を読み込む - DBの出荷と突き合わせる - 出荷Serviceを呼び出す 誤 正 結果:本番で障害起こしてから気づいて修正することに…
失敗2:時と場合によって「出荷とは何か」の定義がブレた - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する -
出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ 出荷Service ある連携サービス限定で通知を飛ばさない 連携サービスによって更新ルールが違う 条件分岐やオプション追加で出荷Serviceがどんどん複雑になっていく
当時の総括 • ドメイン面 ◦ 異なる概念に名前を付けずに単一クラスで扱っていたのかもしれない ◦ PO・PMが場合分けを言語化できなくなったら危険信号 ◦ 「複雑なドメインにPMと開発が一体となって取り組む」ことが重要 •
設計面 ◦ 「システムが複雑になっても出荷のコードは共通」というルールを見直してもよかったかも ◦ 単一責任原則とは何か、という考え方がチームで揃ってなかったかもしれない ▪ オブジェクト指向実践ガイドを読み直したが、正直まだ自信がない
自分なりに考え尽くした。 同僚もGoサインを出した。 それでもこんなもんなのか。
技師ヒロミ 「努力はしている! 神殿上司ミヤケ 「ならば、その努力も もうおしまいだなッ!
つよつよエンジニアは何も言わずに日頃から クソコードの拡大に抗い、用意された時間の 中でリファクタリングをこっそり実施してい たりします。 デキる人はいちいち「リファク タリングをやりましょう」とか言わずに勝手 に改善しているのです。 出典:会社がリファクタリングに賛同してくれないたったひとつの理由 https://shiodaifuku.io/idea/refactoring-skill
できることからやる
モブプロで意見出したり チームでリファクタリング することもできる
タイミーのバリュー オールスクラム
弊社実例 給与計算クラスをリファクタリングしたら 0分稼働でエラー落ちして巻き戻した
給与計算と労働時間計測のロジックが1 クラスに混じっていたからクラス分けの リファクタリングをしていた
- 稼働開始と稼働終了が同じ時刻 - 普通に考えたら存在しないパターン - テストケースもなかった - 実際は、空っぽの実績でタイムカードをつけて修 正依頼するケースが少数存在した -
今までは動いていたがリファクタリングで落ちる ようになってしまった
自分より優秀な同僚でも 一発で正解には辿り着けない
設計を良くする取り組み - コードオーナー制 - 組織ごとにナワバリとするパッケージがある - 実際には各開発者が色んなパッケージを変更する - 一番良く触る組織の人がレビュアーに加わる -
Chapter会議 - Railsエンジニア同士で直近技術的に必要なことを話し合う - 仕組みはあるけど、まだまだやったもの勝ち - 率先してチャレンジすることが尊重される - ぼやいて、巻き込んで、やり通す
やっていきしよう