TL;DR

設計とかコードレビューとかの話でRails Way Dis記事ではない。

Rails使ってきて思うこと

僕はRuby On Railsを使ってそろそろ10年になろうとしているが、10年の間には結構「ダメだなあ」とおもうことも「天才かも」と思うこともやったし、でかいアプリも小さいアプリも面倒みたし、rails newする案件もでかいアプリのバージョンアップもやったし、Railsアプリの集合体のマイクロサービスもみたし、んで巡り巡ってRailsで自社サービス作ってる今の会社で働いているんだけど、なんか市場にでてるRails使っている人の特徴（問題点ではない）って結構両極端な気がする。

• rails newする案件が多くこなしてきて、大きなアプリケーションをみない人
• 大きなアプリを開発・運用する経験が多い人

得てして「Railsしか使えないエンジニアは本当に使えない」みたいな烙印を押されがち（必ず押されてしまうわけではない）のは前者な人の気がする。それでも優秀な人はいっぱいいるのだから、そんなふうにみられるのは悲しい。

設計と実装

確かにスキルはあるのだけど、極端にRails Wayにこだわってしまったり、コードレビューで瑣末なことに強く指摘し続けたりする。（昔の僕だ！）

ただいき過ぎたRails Wayって大きいアプリケーションにはあまりあわないこともあるし、僕は最近そこまで強く意識しないようにした。

そもそも大きくなると最初は簡単だったのが大きくなると複雑になってしまいがちかなあって。メソッドチェイン、ダックタイピング、オープンクラス、null対応、ベストプラクティスがアンチパターンしたり……STI、form_for、callback地獄……などなど。

大きくなるにつれて「これがいい」を柔軟に変えていく思考が必要だなと感じる。

設計と巨大化したRailsアプリケーション

結果「大きくなったRailsと設計と実装のベストプラクティスが初期と真逆になる」みたいなことで、耐えきれなくなった人たちはgoとかの他の言語での書き換えに走ったりするんだろうなーとTwitterみてて感じるが、Rails Wayと現状のバランスを取れる人たちで構成されるのが一番よいのかなって。

誤解しないでほしいのだけど、僕はカオスになったRailsアプリケーションを作るべきといっているのではなく、Rails Wayの秩序を保ちながら、わかりやすい設計を心がけましょうという話に終始する。

設計とDB

データベースの話にうつるけど、概念を抽出->論理の分割->正規化->物理の形にするをちゃんとやればいいんだけど、DB意識しないでコード書くとよくない方向に落ちがちだなあと思っている。使う側、アプリケーションエンジニアはちゃんと古からの手順とアーキテクチャに想いを馳せつつ設計をしていきましょう、初めてRailsアプリケーションに接する勢は「Railsではこう言う特徴がある」というのを一式頭にいれてから臨みましょう、というのをDB設計についてはわりかし思う。

「外から来たからRailsのことわかってない」「Rails使う人はDBのことわかってない」となってしまうのはもったいないし、かなしいことだ。

おわり

みんなのいいところをいかして最高のプロダクトをつくるという目標なので、その上でPull Requestにどんな粒度感で指摘をしたほうがいいのかもっと考えていきたいなと思った。