OOC2024 登壇資料

(株)タイミーのスポンサーセッションとして発表したものです。

Transcript

1. 2024/03/24　甲斐 宏味 俺のオブジェクト指向開発のベストは この程度なんだろうか
2. 目次 • 自己紹介 • 会社紹介 • 設計を振り返る
3. 1 自己紹介
4. 自己紹介 名前：甲斐 宏味(かい ひろみ) 所属：エンジニアリング本部 プロダクトエンジニアリング部 職種：バックエンドエンジニア（Rails） 経歴：SE → (転職失敗して紆余曲折) → Webスタートアップ数社 → タイミー SNS：やってますが技術の話はしません 得意：仕事やMTGが連続しているときに周囲に腹が減ったと言うこと 苦手：CLIでgit diffを読むこと
5. おことわり 本資料にはタイミー以前の経験を元にした内容が含まれていますが、 当時の内容を元に一部変更を加えています。
6. 2 会社紹介
8. タイミーの実績 スキマ バイト No.1 ※2024年2月時点　※1 [調査方法]インターネット調査 [調査期間]2021年2月9日~11日 [調査概要]スキマバイトサービスの実態調査 [調査対象]直近1年以内にスキマバイトを経験したことのある18〜69歳の男女1034名[調査実施]株式会社マクロミル 8 利用率・リピート率 ※1 導入事業者数 98,000企業 ワーカー数 700万人
11. 3 設計を振り返る
12. 皆さんは良い設計、できていますか？ 私はできてません。
13. よい設計ってなんだろう？ - オブジェクト指向の原則に従う - SOLID原則 - 単一責任の原則 - オープン・クローズドの原則 - リスコフの置換原則 - インターフェース分離の原則 - 依存性逆転の原則 - デメテルの法則 - 構造化設計 - 凝集度を高く、結合度を低く
14. デメテルの法則 - 自分以外の振る舞いや実装などに関して持っている知識を最小にする - この法則に従うとメソッドチェーンがアンチパターンになる - Rails自体が自然とデメテルの法則に反する実装やりがち - ActiveRecordによるDB操作なんて何から何まで違反している - 自前で作ったクラスも、丁寧に相互関係を整理しないと暗黙的な呼び出しを やりがち
15. Serviceクラスの落とし穴 - 自分が見てきたRailsを採用しているサービスはみんなServiceクラスを採用 していた - Service間の依存関係を理解するのが難しい - 本来密結合させないといけない概念が無駄に分かれることがある - 凝集度の低下 - 業務を構成するためにはどのServiceを組み合わせたらいいの？という問いの 正解が誰もわからなくなるときがある
16. 以前経験した設計の失敗 - 在庫管理のSaaS - 出荷に関するService設計 - ここでの出荷に関する定義 - 出荷は完了したか否かの状態を持つ - 1つの出荷には複数の出荷品目が存在する - 出荷品目も状態を持つ - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する - 出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ 出荷Service
17. 出荷Serviceの多義化による失敗 1. Serviceの依存関係が整理できなくて、ある外部サービスを追加する際に呼び 出すクラスを間違えた - 出荷Serviceの一部の呼び出し先だけを呼び出してしまい、「出荷」が正しく完了していない 状態だった 2. 時と場合によって「出荷とは何か」の定義がブレた - 提携する外部サービスの追加に伴い、出荷にまつわるチャネルが増えた - 「ある流入元限定で通知を飛ばさないで欲しい」という要望 - 外部サービスによって出荷品目の分納ができたりできなかったりする
18. 失敗1:Serviceの依存関係が整理できなくて、 ある外部サービスを追加する際に呼び出しクラスを間違えた - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する - 出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ - 外部サービスのCSVから出荷を読み込む - DBの出荷と突き合わせる - 出荷品目でループする - 在庫減らすServiceを呼び出す - 外部サービスのCSVから出荷を読み込む - DBの出荷と突き合わせる - 出荷Serviceを呼び出す 誤 正 結果：本番で障害起こしてから気づいて修正することに…
19. 失敗2:時と場合によって「出荷とは何か」の定義がブレた - トランザクションを張る - 出荷品目でループする - 在庫減らすServiceを呼ぶ - 出荷品目のステータスを更新する - 出荷ステータスを更新する - 通知飛ばすServiceを呼ぶ 出荷Service ある連携サービス限定で通知を飛ばさない 連携サービスによって更新ルールが違う 条件分岐やオプション追加で出荷Serviceがどんどん複雑になっていく
20. 当時の総括 • ドメイン面 ◦ 異なる概念に名前を付けずに単一クラスで扱っていたのかもしれない ◦ PO・PMが場合分けを言語化できなくなったら危険信号 ◦ 「複雑なドメインにPMと開発が一体となって取り組む」ことが重要 • 設計面 ◦ 「システムが複雑になっても出荷のコードは共通」というルールを見直してもよかったかも ◦ 単一責任原則とは何か、という考え方がチームで揃ってなかったかもしれない ▪ オブジェクト指向実践ガイドを読み直したが、正直まだ自信がない
21. 自分なりに考え尽くした。 同僚もGoサインを出した。 それでもこんなもんなのか。
22. 技師ヒロミ 「努力はしている！ 神殿上司ミヤケ 「ならば、その努力も もうおしまいだなッ！
23. つよつよエンジニアは何も言わずに日頃から クソコードの拡大に抗い、用意された時間の 中でリファクタリングをこっそり実施してい たりします。 デキる人はいちいち「リファク タリングをやりましょう」とか言わずに勝手 に改善しているのです。 出典：会社がリファクタリングに賛同してくれないたったひとつの理由 https://shiodaifuku.io/idea/refactoring-skill
24. できることからやる
25. モブプロで意見出したり チームでリファクタリング することもできる
26. タイミーのバリュー オールスクラム
27. 弊社実例 給与計算クラスをリファクタリングしたら 0分稼働でエラー落ちして巻き戻した
28. 給与計算と労働時間計測のロジックが1 クラスに混じっていたからクラス分けの リファクタリングをしていた
29. - 稼働開始と稼働終了が同じ時刻 - 普通に考えたら存在しないパターン - テストケースもなかった - 実際は、空っぽの実績でタイムカードをつけて修 正依頼するケースが少数存在した - 今までは動いていたがリファクタリングで落ちる ようになってしまった
30. 自分より優秀な同僚でも 一発で正解には辿り着けない
31. 設計を良くする取り組み - コードオーナー制 - 組織ごとにナワバリとするパッケージがある - 実際には各開発者が色んなパッケージを変更する - 一番良く触る組織の人がレビュアーに加わる - Chapter会議 - Railsエンジニア同士で直近技術的に必要なことを話し合う - 仕組みはあるけど、まだまだやったもの勝ち - 率先してチャレンジすることが尊重される - ぼやいて、巻き込んで、やり通す
32. やっていきしよう