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
Deep Dive into Kotlin Flow
jmatsu
1
360
テストカバレッジ100%を10年続けて得られた学びと品質
mottyzzz
2
610
知っているようで知らない"rails new"の世界 / The World of "rails new" You Think You Know but Don't
luccafort
PRO
1
180
Reading Rails 1.0 Source Code
okuramasafumi
0
250
ProxyによるWindow間RPC機構の構築
syumai
3
1.2k
print("Hello, World")
eddie
2
530
Tool Catalog Agent for Bedrock AgentCore Gateway
licux
7
2.5k
より安全で効率的な Go コードへ: Protocol Buffers Opaque API の導入
shwatanap
1
320
テストコードはもう書かない:JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成
makun
0
410
AI Coding Agentのセキュリティリスク:PRの自己承認とメルカリの対策
s3h
0
230
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
kishida
22
5.8k
Improving my own Ruby thereafter
sisshiki1969
1
160
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
140
7.1k
Statistics for Hackers
jakevdp
799
220k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Practical Orchestrator
shlominoach
190
11k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Scaling GitHub
holman
463
140k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Rails Girls Zürich Keynote
gr2m
95
14k
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エンジニア同士で直近技術的に必要なことを話し合う - 仕組みはあるけど、まだまだやったもの勝ち - 率先してチャレンジすることが尊重される - ぼやいて、巻き込んで、やり通す
やっていきしよう