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
110
OOC2024 登壇資料
(株)タイミーのスポンサーセッションとして発表したものです。
Hiromi Kai
April 02, 2024
Tweet
Share
More Decks by Hiromi Kai
See All by Hiromi Kai
#kaigieffect LT大会 at RubyKaigi2024 登壇資料
hiromikai
0
79
西区プログラミング勉強会発表資料
hiromikai
0
65
Other Decks in Programming
See All in Programming
From Spring Boot 2 to Spring Boot 3 with Java 22 and Jakarta EE
ivargrimstad
0
1.9k
APIのない大学ログインWebサービスをWKWebViewとJavaScriptでアプリ化した話
akidon0000
1
330
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
81k
Activities at Cairo Library
cairolibrary720
0
1.2k
20240706_CDKConf
takuyay0ne
0
1.2k
Polarsの成長: v0.14からv1.0までの変遷と今後の展望
zerebom
1
350
Google's Recipe for Scaling (Web) Security – LocoMocoSec 2024
lweichselbaum
0
170
入社1ヶ月でここまでやった!Findy Toolsインフラ支援の最適化
rvirus0817
6
1.4k
I/O Extended Android in Korea 2024 ~ Whats new in Android development tools
pluu
0
250
最近追加した型の紹介とその振り返り
aki19035vc
0
170
DDDを志して3年経ったら「DDDの皮を被ったクリーンアーキテクチャ」になった話【デブサミ2024夏】
texmeijin
1
620
DynamoDB コスト最適化っぽいことの基本 with Terraform
kuro_kurorrr
2
250
Featured
See All Featured
Side Projects
sachag
451
42k
Large-scale JavaScript Application Architecture
addyosmani
506
110k
Music & Morning Musume
bryan
43
5.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
Unsuck your backbone
ammeep
666
57k
Ruby is Unlike a Banana
tanoku
96
10k
[RailsConf 2023] Rails as a piece of cake
palkan
35
4.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
16
1.6k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Building Applications with DynamoDB
mza
89
5.8k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
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エンジニア同士で直近技術的に必要なことを話し合う - 仕組みはあるけど、まだまだやったもの勝ち - 率先してチャレンジすることが尊重される - ぼやいて、巻き込んで、やり通す
やっていきしよう