Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita

この記事はCrowdWorks Advent Calendar 2016 の24日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 昨日の記事は @suzan2go による「ラーメン屋で考えるRailsのデータモデリング」でした。 はじめに CrowdWorksは、2011年の創業以来、約5年間の開発を続けてきました。サービスの立ち上げ期においては、サービスの継続性・変更容易性を高めることよりも、サービスを成長させ、存続に繋がるフェースまで素早く立ち上げることが最重要な観点です。 一方で、サービス提供も5年が経過し、多くの方にご利用頂く「社会インフラ」に一歩ずつ近づいてきています。そういった環境の変化もあり、「日々改善し続ける」「日々変更し続ける」ことに重要視する観点が移り変わってきました。そのような価値観の変遷に取り組む過程で考えている「大規模で複雑な業務要件を担う

[tadyjp]

開発当初「レールに乗ればどのFWよりも生産性が高いぜ」; 中規模「FWが悪いんじゃない、開発メンバーが言うことを聞かないんだ！」; 大規模以降「うちも大きくなったしマイクロサービスにするか他言語手出しちゃう？」

[aki03]

書きました。クラウドワークス アドベントカレンダーの24日目。

[astap]

commetnモデルをSTIにしてクラスを分けるとか、そもそもブログとプレスのコメントは別テーブルだよね。とか出来る気がするけど、やったことないから使い勝手はわからんな。

[diveintounlimit]

一通り読んで思ったことは「ものは使いよう」だけど、将来を見据えて設計するのってだいぶ難しいので幾分やってしまいそうな気はした。

[takryou79]

Ruby on Rails

[daaaaaai]

ServiceLayerよさそう。ただ、callback、単純なものなら便利なんだよな・・・

[takaesu]

service や formをハンドリングするクラス

[rochefort]

Concern使わない

[yatmsu]

concernとARのCallbackは原則使用禁止でいいと思う。

[YusukeIwaki]

大規模かどうか、というよりは、組織にRails初めてさわる人が増えても間違った設計をしないためのいい設計とは、という内容かも。

[nakag0711]

まとめると、単一継承は悪

[hamichamp]

Concernで頭痛くなった。

[nilab]

Railsで大規模アプリケーションを正しく設計するために避けるべき3つの機能 - Qiita

[oakbow]

コールバックに関しては、規模の大小に関係なく基本的に使わない方がいいな。サービスハンドラはどうかなあ。考えたことはあるけどあんま変わんなさそうで試したことはないや。