Ruby / Railsのつらみ
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
型がない
覚えゲー辛い
『この関数には何を渡すべきなのか』の覚えゲーになる。
週5でずっと同じ案件触ってる人はまだ良いかもしれないが、週2でRails案件とかだと何がしたいのかわからなくなりやすい。
他者の行動を縛れない
業務委託だと全員のコードレビューをして秩序守るみたいなことがしづらい。
linterの導入など、自動的に質を担保できる方法じゃないと秩序を守りきれない。
となるとやっぱり型がある言語のほうが秩序を保ちやすい。
型の発想がないコードは保守性が低い
そもそも型を意識しないコードは保守性が低くなりやすい。
(実装者自体が引数で渡ってくるものの型を想定せずに作ってるケースなど)
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
宣言的でない
時間軸とともにObjectの定義自体が変わる。(メタプロ)
DSLバリバリ作れて自分が遊んでる分には楽しいが、ドツボにはまったときに困る。
そしてDSLも結局覚えゲーになる。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
情報が少なくなってる?
困ったときに英語で検索してもヒットするのが数年前の情報であることが多い。
ライブラリも最終更新が数年前だったり。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
ActiveRecordのインターフェースガバ
ActiveRecordのインターフェースがガバガバすぎてどこでどの処理が呼ばれてるのか把握するのが難しい。
例えば「作成時に一緒にこの処理走らせたい」ってときとか。
ここでafterCreate系に頼るともはや何が起きるか想定できなさすぎて怖い。
バッチなど想定外のところからぷよぷよみたいに連鎖してわけわからない挙動が起こる恐れがある。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
Railsの思想
5年以上保守してるような古いプロダクトを触ってるとRails的な思想は辛くなってくる。
一方でとにかく「0->1」をスピード感持ってやってる人(完成したら別プロジェクトに異動するような系)はその辛みを経験せずにRailsの恩恵だけを受けられる。
そうした人がRailsを技術選択すると考えると、Rails案件は保守性よりも完成速度を意識したものである恐れがある。
たとえば色々な会社の技術顧問して0->1の設計してる人が「テスト書かない」「ビジネスは速度が大事」と言っていた。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
技術選択の背景2
Railsは全ての人が50点のコードを書けるのが強み。
特にDBのクエリなどを理解しなくても、なんとなく良い感じにキャッシュされ、ある程度クエリ最適化されたコードが書ける。
その背景もあり3ヶ月でエンジニアになるのに最適なフレームワーク。
(細かい原理を理解させなくても、書き方さえ暗記させればサービスを作れるようにできるので)
それを踏まえて合理的にRailsを技術選択したと考えると、「駆け出しエンジニアかき集めてとりあえず動くもの作りたい」みたいな背景である恐れがある。
→そこに後からJOINするリスク。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
DDD的 vs Rails的
- 「1つのリソースを色々なコマンドで操作する」サービスで、ずっとDDDっぽく書きたいと思っていた。
- 機能追加するたびにif文が色々なところに追加される末期症状
- 一方で機能追加が全く別のリソースを追加するものばかりなら、DDDの恩恵は薄いかも。
- Commandが少なくQueryが多いサービスも同様で、DDDの恩恵は薄そうに感じた。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
フロントエンド界隈のRails的フルスタックフレームワーク信仰への疑問
要するにblitz.js。
脱Webpackerで苦節を味わってる割にRails的なものに魅力を感じてそう。
フルスタックフレームワークはその時点のベストプラクティスでしかなくて、数年したらガムみたいにこびりついたレガシーになる。
たとえばNext+Nodeも、将来的にNext脱却したいけどできない、Node脱却したいけどできないみたいなことになりそう。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
Clean Architectureは依存を減らして交換可能性をあげようねって思想で、中長期的にプロダクトを運営してる人はこっちの思想になりやすい。(こびりついたガムをひたすら剥がす仕事になるので)
Rails的なモノリシックフレームワークは0->1を素早く作りたい人に好まれやすい。(すぐにある程度の質のものができるので)
フルスタックフレームワークがフロントエンド側で盛り上がってるのは、フロントエンドに後者の人が多いってのもありそう。
(フロントエンドは同じUIを何年も保守しなくても、捨てて書き直しやすい)
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
0->1の素早さという観点だと、もっと尖らせてFiriebaseみたいにDB直でいじれば良いんじゃないかと思う。
(サービスが流行ったら作り直すぐらいな気持ちでね。)
が、MVC+サービス層の記事の盛り上がりを見るに確かにRails的なものは好まれるし、業界をリードしてる人がお墨付きを与えればみんな飛びつきそうだ。
![dorarep](https://res.cloudinary.com/zenn/image/fetch/s---zuQOQO2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/deabfe2059.jpeg)
ただフルスタックフレームワークはTypeScriptの型の世界をどう波及させてくかの延長線上でもあるので、フロントエンドを中心に捉えると分からなくもない。
TypeScriptはいかに外部からの型を担保するかが鍵で、外部を内部に変えるフルスタックフレームワークはそれを解決する魔法。