型がない

覚えゲー辛い

『この関数には何を渡すべきなのか』の覚えゲーになる。
週５でずっと同じ案件触ってる人はまだ良いかもしれないが、週2でRails案件とかだと何がしたいのかわからなくなりやすい。

他者の行動を縛れない

業務委託だと全員のコードレビューをして秩序守るみたいなことがしづらい。
linterの導入など、自動的に質を担保できる方法じゃないと秩序を守りきれない。
となるとやっぱり型がある言語のほうが秩序を保ちやすい。

型の発想がないコードは保守性が低い

そもそも型を意識しないコードは保守性が低くなりやすい。
（実装者自体が引数で渡ってくるものの型を想定せずに作ってるケースなど）

宣言的でない

時間軸とともにObjectの定義自体が変わる。（メタプロ）
DSLバリバリ作れて自分が遊んでる分には楽しいが、ドツボにはまったときに困る。
そしてDSLも結局覚えゲーになる。

情報が少なくなってる？

困ったときに英語で検索してもヒットするのが数年前の情報であることが多い。
ライブラリも最終更新が数年前だったり。

ActiveRecordのインターフェースガバ

ActiveRecordのインターフェースがガバガバすぎてどこでどの処理が呼ばれてるのか把握するのが難しい。
例えば「作成時に一緒にこの処理走らせたい」ってときとか。
ここでafterCreate系に頼るともはや何が起きるか想定できなさすぎて怖い。
バッチなど想定外のところからぷよぷよみたいに連鎖してわけわからない挙動が起こる恐れがある。

Railsの思想

5年以上保守してるような古いプロダクトを触ってるとRails的な思想は辛くなってくる。
一方でとにかく「0->1」をスピード感持ってやってる人（完成したら別プロジェクトに異動するような系）はその辛みを経験せずにRailsの恩恵だけを受けられる。
そうした人がRailsを技術選択すると考えると、Rails案件は保守性よりも完成速度を意識したものである恐れがある。
たとえば色々な会社の技術顧問して0->1の設計してる人が「テスト書かない」「ビジネスは速度が大事」と言っていた。

技術選択の背景２

Railsは全ての人が50点のコードを書けるのが強み。
特にDBのクエリなどを理解しなくても、なんとなく良い感じにキャッシュされ、ある程度クエリ最適化されたコードが書ける。

その背景もあり３ヶ月でエンジニアになるのに最適なフレームワーク。
（細かい原理を理解させなくても、書き方さえ暗記させればサービスを作れるようにできるので）

それを踏まえて合理的にRailsを技術選択したと考えると、「駆け出しエンジニアかき集めてとりあえず動くもの作りたい」みたいな背景である恐れがある。
→そこに後からJOINするリスク。

DDD的 vs Rails的

• 「1つのリソースを色々なコマンドで操作する」サービスで、ずっとDDDっぽく書きたいと思っていた。
  • 機能追加するたびにif文が色々なところに追加される末期症状
• 一方で機能追加が全く別のリソースを追加するものばかりなら、DDDの恩恵は薄いかも。
• Commandが少なくQueryが多いサービスも同様で、DDDの恩恵は薄そうに感じた。

フロントエンド界隈のRails的フルスタックフレームワーク信仰への疑問

要するにblitz.js。
脱Webpackerで苦節を味わってる割にRails的なものに魅力を感じてそう。
フルスタックフレームワークはその時点のベストプラクティスでしかなくて、数年したらガムみたいにこびりついたレガシーになる。
たとえばNext+Nodeも、将来的にNext脱却したいけどできない、Node脱却したいけどできないみたいなことになりそう。