Railsに感じていたこと

IT

Railsの騒がれ方を見ていて、その見せ掛けの生産性に関する部分の議論にはどうもなじめなく、かつもやもや感があったのです。

テーブルは次の2つです。

これ、Railsも必ずここから始まるのね。つまり「DB設計が完了した状態から始まる」のです。で、だ。みんなそんなにDB設計さくさく出来るんだ。ふ〜ん、知らなかったよ。じゃあ質問ね。DB設計のインプットは何ですか？　繰り返す。DB設計の元となる情報はどこからどうやって入手するの？　そのリレーションシップはどういう根拠を持って設定されてるの？　その列がここのテーブルにある理由はどうやって担保してるの？　結局UI設計をするしかないんじゃないの？

そうですよね、直感DB設計でさくさくっと作っちゃいましたの世界では、弊社の得意なMS-ACCESSの方がよっぽどお手軽です。それで、結局はぶさんの書いているようなひどい目にあっているわけですけど。その癖が抜けなくて、DB設計難民になって、インピーダンスミスマッチなんて八つ当たりをはいている自分に、はっと気づかされました。というわけでRailsの生産性の部分は対する引っかかりは、自分自身のMS-ACCESSによる苦い経験からのもやもやでしたのですね。
でもそれを乗り越えて、「Rubyという言語の柔軟性とRailsとフレームワークの筋の良さ」に期待したいところもあるのです。弊社みたいなところのエンジニアが簡単なシステムで直感的なDB設計後、あるいは達人よるちゃんとしたDB設計後に、泥沼のコードをひたすら書くのではなく、Railsとフレームワークの筋の良さに引っ張られて少しでもまともなコードが書けるようになればいいなと思います。

業務ソフトは典型的な80:20の法則であって、80%は単純なものだ。80%でよければ銀行のオンラインなんて単なる足し算と引き算だ。誰がやってもすぐできる。しかし、これを90%にすると何千万円になって、99.99%にすると何十億円になる。

この記事によってさらにRailsの立ち位置がはっきりしてきたように思えます。
弊社の場合上記の80%のさらに複雑でない方の40%くらいのところで、細々やってます。