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
Railsアンチパターン_suzuki_mar_zeals.pdf
Search
suzuki masayuki
May 29, 2020
Programming
1
220
Railsアンチパターン_suzuki_mar_zeals.pdf
suzuki masayuki
May 29, 2020
Tweet
Share
More Decks by suzuki masayuki
See All by suzuki masayuki
緊張をしちゃう人用_のLTのやりかた
suzukimar
1
7
UseCaseクラスを使って FatControllerやFatModelにしない
suzukimar
2
360
ChatGPT にいる 9人の生成AIロールとの日常
suzukimar
1
290
CQRS/ESのクラスとシステムフロー ~ RailsでフルスクラッチでCQRSESを組んで みたことから得た学び~
suzukimar
0
240
バイブコーディング_TDD.pdf
suzukimar
0
67
RailsでCQRS/ESをやってみたきづき
suzukimar
2
1.8k
ドメイン駆動設計の考えをもとに競合優位性や アウトカムを得る
suzukimar
0
200
ドメイン駆動設計に挫折をしないで一歩目を歩く
suzukimar
0
190
変更につよいユニットテストの書き方.pdf
suzukimar
2
120
Other Decks in Programming
See All in Programming
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
540
ASP.NETアプリケーションのモダナイズ インフラ編
tomokusaba
1
420
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
550
ふつうの技術スタックでアート作品を作ってみる
akira888
0
150
Select API from Kotlin Coroutine
jmatsu
1
190
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
47
31k
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.6k
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
460
エラーって何種類あるの?
kajitack
5
310
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
540
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
470
エンジニア向け採用ピッチ資料
inusan
0
160
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Facilitating Awesome Meetings
lara
54
6.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Raft: Consensus for Rubyists
vanstee
140
7k
How to Ace a Technical Interview
jacobian
277
23k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Transcript
ZealsのRailsチームで抱えていた問題と対策したこと アンチパターンとその解決策 テクノロジー開発部 鈴木将之 (suzuki_mar)
• 自己紹介 • 今回話す目的 • アンチパターンと解決策 • まとめ Agenda
自己紹介
- StudyPlus - iOSアプリエンジニア - フリーランス - Zealsも社員ではなく、業 務委託 -
Rails, Ruby - OOP XP(TDD など) DDD Rails プロジェクト コードオーナー suzuki_mar :suzuki-mar :suzuki_mar : :suzuki_mar
今回話す目的
ZealsのRails プロジェクトで、アーキテクチャレベルでの リファクタをしてきました そのリファクタしてきた中で特に自分が重要だと思った内 容を説明します LTを聞いた人が関わっているプロジェクトのアーキテク チャを考えるきっかけにしてもらえたら幸いです 今回話す目的
Railsプロジェクトは、去年末ぐらいからアンチパ ターンに書いてあるよなリファクタを適宜していっ た 現在は、RailsでDDDを上手に活かす方法を模索中 今のRailsプロジェクトの状況
アンチパターンの説明に以下のプロジェクトを使用します プロジェクトの種類:TODOアプリ 実装している機能:Taskの作成、削除、編集 Taskを完了する Taskの予定の調整 Model Task Log TaskGroup
User Schedule サンプルプロジェクトの説明
1. Serviceクラスの名前を抽象的にする 2. 開発者だけでモデリングする 3. concernの乱用 4. 属人的なコードレビュー 説明するアンチパターン
アンチパターン1 Serviceクラスの名前を抽象的にする
サービスにしたい処理 Taskを作成するときに、TaskGroupなどの複数のレ コードをまとめて作成する そのクラス名をTaskServiceにしてしまう Serviceクラスの名前を抽象的にする アンチパターンの例
TaskServiceだと問題になってしまう箇所 • クラス名からなにをするServiceなのかがわかり づらい • 抽象的なので、どんどんサービスを加えてしま う ◦ その結果、クラスが肥大化してしまい、ゴッ ドクラスになってしまう
Serviceクラスの名前を抽象的にする アンチパターンになってしまう説明
名前を具体的にする:TaskCreatorなどにする • クラス名からタスクを作成するということが簡 単にわかる • 具体的なので、当初考えいていたサービスの責 務以外を加えない ◦ TaskCreatorに、Taskを削除するサービスを 追加することは不自然となる
Serviceクラスの名前を抽象的にする アンチパターンの改善案
アンチパターン2 開発者だけでモデリングする
プロダクトオーナーなどに意見を聞かずにRDBを設 計する RDBを設計した内容をモデリングとして扱ってしま う 開発者だけでモデリングする アンチパターンの例
エンジニアとプロダクトオーナーが話すときに、翻 訳が必要 プロダクトオーナー”Todoを完了したときに、Userのステータス を変更してほしい “ エンジニア “Taskを完了したときにUserのステータスを変更すればいいんで すね” (TodoはTaskと翻訳している) 開発者だけでモデリングする
アンチパターンになってしまう理由
先程の例のような言葉を翻訳する必要が出てく ほっておくと後々大きな問題になってしまう • 新しいエンジニアがチームに加入したとき ◦ 翻訳内容を覚えてもらう必要がある • 仕様などの複雑な会話をするとき ◦ 翻訳して話していくのがコストがかかってしまう
開発者だけでモデリングする アンチパターンになってしまう理由
先に、プロダクトオーナーなどの関係者と、モデル 名などの名前を決める 先程の例だとTaskにするのか、Todoにするのか その名前をもとに、RDBの設計やクラス設計をする 詳しくは、ユビキタス言語を参照 開発者だけでモデリングする アンチパターンの解決策
• ユビキタス言語をきめたあとも、ユビキタス言 語を使用するように保守をする ◦ コードレビューなどをする • ユーザーが別の名前を使用しているるとき ◦ プロダクトオーナーと相談をして、名前を変 更するかきめる
開発者だけでモデリングする アンチパターンの解決策
• RDBのテーブル名やカラム名を変更できなく なってしまう • 名前を変更するときに、変更するコストが莫大 になってしまう ◦ 技術的負債になってしまう • 別のサービスにも影響してしまう
◦ マイクロサービスの場合 開発者だけでモデリングする 放置すると
アンチパターン3 concernの乱用
委譲するコードを書くのがめんどくさいので、 concernを使用する Taskを完了したときと、Scheduleを変更したとき にメールを送信する処理を共通化するために concernを使用する concernの乱用 アンチパターンの例
処理をどこに定義してあるのかがわからりづらい concernでnotifyメソッドを定義する task.notify とかける だが、Taskを見ただけでは、notifyがどこに定義しているの かがわからない 修正するときに、コード検索をするなど手間が必要になり技 術的負債になっていs舞う concernの乱用 アンチパターンになってしまう例
処理を委譲する 共通にしたい場合は、Serviceクラスなどに定義す る コード例 Notify.send(task) そうすれば、コード例のようにどこに実装している のかがわかる concernの乱用 アンチパターンの解決策
concernを使用する場合は、concernを使用する以 外に選択肢がないのかを考える 処理を共通化したいだけなら、サービスクラスを作 成する concernの乱用 アンチパターンの解決策
アンチパターン4 属人的なコードレビュー
コードレビューで判断する項目がないので、レビュ アーが各自で判断して、RequestChangeやApprove をする 属人的なコードレビュー アンチパターンの例
Aさんは小さいところ(NITS)でも、RequestChangeにする Bさんは、テストコードを書いていないとかの、確実に RequestChangeにするべきところでも、Approveしている コードレビューで担保したいところを守れていなかったり、 必須じゃないところでも変更してしまう 属人的なコードレビュー アンチパターンになってしまう例
コードレビュー時にMustなところを、GitHubのPRのテンプ レートに書く(PULL_REQUEST_TEMPLATE.md) レビューイ(レビューしてもらう人)は、PRを出す前に自分で チェックをする レビュアーは、Mustなところをチェックして、対応していな かったらRequestChangeにする 属人的なコードレビュー アンチパターンの解決策
• ユニットテストを書いているか • N+1がないか • クラス設計が適切か ◦ Serviceにするべき処理をModelに書いていないか • APIドキュメントを書いているか
属人的なコードレビュー チェックするべき例
チェック項目は、あくまでもリストアップしたもの リストアップに含まれていないけど、マージしたらまずいも のはあるので、そのときはコメントする 必要であれば、RequestChangeにする あまりにも頻繁に発生するものや、今後絶対にマージ指定は いけないものは、チェック項目に追加していく 属人的なコードレビュー チェック項目じゃないけどコメントしたい場合
自動化できるところは自動化する CIなどで、チェックを自動化できるところはチェックを自動 化する仕組みづくりをする bulletなどのGemも積極的に利用する 人間が確認するところは、目視で確認する クラス設計などは目視で確認したほうが確実 属人的なコードレビュー 補足
まとめ
まとめ • Serviceクラスは具体的な名前をつける • プロダクトオーナーなどと一緒にモデリングする • concernを使用しないで共通化できる方法を考える • コードレビューで確実にチェックする場所は、PRの Templateに定義する
まとめ 今回のアンチパターンはZealsのRailsプロジェクトで対応したアン チパターンです プロジェクトによっては、今回説明したアンチパターンでも問題 ないケースもあります みなさんのプロジェクトでもアンチパターンとなっていそうな部 分を共有していただきたいです
LET'S START NEXT INDUSTRIAL REVOLUTION WITH OUR FLYING SHUTTLE
アピールポイント • ChatBotの広告(チャットコマース)という新しいドメインモデリングができます • 社内のユーザーが多く使用している広告管理画面を作成するので、フィードバック をもらえやすいです ◦ サービス自体は、日本のChatBot広告システムとして、エンタープライズ市場 NO1なので、大きなクライアントにも使用してもらっている •
RailsでDDDをうまく使っていく方法を模索できる ◦ DDDの勉強会や設計共有会を頻繁にしている ◦ DDD歴が長いアドバイザーからRailsのDDDについて教えてもらえる
Thank you!!