[Day 1: C-8] 7年目を迎えたRailsアプリケーションの傾向と対策


yhirano55
yhirano55 commented 4 months

登壇者: 株式会社キッチハイク 小川 剛

弊社キッチハイクでは創業当初からRailsを使ってきて、いまや七年目を迎えました。

Railsアプリケーションは一定の規模になってくるとRailsのレールから外れるシーンも増えてきます。その一方でレールから外れた際にどうするか、定番のパターンとされるものはありますが、そのノウハウはまだまだ共有はされていない印象です。

本セッションではキッチハイクがレールから外れた際に試行錯誤してきた設計パターンについて、成功 / 失敗の体験談含めてお話したいと思います。


  • このセッションに関する質問を募集中です
  • 事前に聞きたいことがあれば、何でも書き込んでください。
  • 質問への回答はお約束できません。あらかじめご了承ください

Like(0)

Questions and feedbacks (8)

taogawa
taogawa commented 4 months

@pokotyamu 社内wikiや自社のテックブログを読んでもらっています。 記事にまとめると、背景含めて説明しやすいのでおすすめです!

Like(1)

taogawa
taogawa commented 4 months

@expajp いまのところ、そんなに切り分けているわけではなく、関連ドメインで切り分けているような感じです。このあたりはキッチハイクでも試行錯誤中です。

Like(0)

taogawa
taogawa commented 4 months

@fursich チーム内で「サービス、なんかごちゃごちゃしているよね」の声が出てきたらサービスの整理の頃合いかなと思います。 app/services はなんでも置き場として便利なのは否めません・・・。たとえばFactoryクラスがいるな〜と思っても、1つしかなければトップレベルにディレクトリ掘るのはためらわれる -> services に置いておく、はありそうな流れです。 DDD本の3種類のサービス定義の話をしましたが、最初からすべてあれらが必要かというとそうでもないでしょうし。

ただ、概念として別物にしたいなというもの(例えばアプリケーションサービス)が出てきたときはそれと区別できるようにしておくのがいいかなと思います。

Like(0)

taogawa
taogawa commented 4 months

@nard-tech はい、分割しています! あとはアプリ向けAPIエンドポイントもあるので、それでcontroller数が増えている側面もあります。

質疑のときにもお話しましたが、DHH流ルーティングはまともにやるとリソースの階層がめちゃくちゃ深くなりがちなので、そこが気を付けどころです。

Like(0)

pokotyamu
pokotyamu commented 4 months

新しい人が join した時に、既に導入されているレールから外れている部分の知識はどんな感じで認識を合わせていますか?

Like(0)

expajp
expajp commented 4 months

「app/service の下に大量のサービスクラスが作成されててわけわからん」ってあるあるだと思うのですが、 app/serviceの下で名前空間を切ったりされていますか?

Like(0)

fursich
fursich commented 4 months

サービスになんでも突っ込む問題はとてもあるあるだと思って共感しました。

サービスが腐らないために、コードレベルで「これはやりすぎじゃないか」、「これが見えたらやめたほうがいいのでは・・」という具体的なガイドラインとか、チームで大切にしているcode smellのようなものはありますか?

Like(0)

nard-tech
nard-tech commented 4 months

controller の数が随分多いと思ったのですが、DHH流の分割をしているのでしょうか?

Like(0)

Create Comment

Please sign in to comment.

Sign in with GitHub
This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano