hitode909の日記

趣味はマリンスポーツですの日記です

ウェブアプリケーション作るためのフレームワーク、ジェネレータでControllerができるとか、RESTfulなルーティングを簡単に作れるとかあるけど、そういうのは手で書いてもすぐできる。
ジェネレータで作って終わりみたいなのがほとんどだけど、フレームワークから外れたことしようとするとすごい大変になる。フレームワークなければ普通に書けばいいけど、フレームワーク使ってると、規約に沿わないといけない。一部のメソッドを上書きしてちょっと変わった動きをさせるとか、そういう感じになって、フレームワークのバージョン上がったとき動かなくなったりする。
変なことをして無理に書くのはやめようと言われるけど、そう書かないといけないフレームワークが悪い。普通に書けるなら普通に書いてるはず。仕様決める人はフレームワークのことまで考えてるはずがないから、全員損してる。フレームワーク的には、きれいで完璧で整合性の取れたアプリケーションを書くことを想定しているけど、現実世界ではその範囲にない仕様があって、規約に添えない、ということがある。
規約を強いるようなフレームワークは使ってはいけない。規約とか設計はアプリケーションごとに定めないといけない。自分で規約持ってれば、現在の規約ではきれいに書けないような、変な仕様が出てきたとき、規約を変えて、既存のコードもそれに合わせることができる。
フレームワークを使うと、どうかこのクラスを呼び出してくださいみたいになって、呼び出し側をコントロールできない。クラスを呼び出す側も制御できる方が良い。
フレームワーク自作するのもそんなに良くなくて、仕様変えようとしたときに、他のプロジェクトで使ってるから後方互換性のある変更しかできなくて、進化が止まってしまう。また、本体を変更できないから、みんなモンキーパッチを当てて使いだして、利用状況がわからなくなる。
具体的には、Sinatraは使っていいけどRailsは使ってはいけないと思った。
Railsどういうときに役立つか考えたけど、能力の低いプログラマを集めてチーム作るときには良いと思う。規約に沿って書かないといけないから、誰が書いてもそんなに差がなくて、変なコードも生まれにくい。複数人でSinatra使うと、自由すぎて、コーディング規約揃えないとめちゃくちゃになると思う。規約作ったり、レビューして変なコードが入らないようにする必要があるから、手間は増えるけど、変更に強い。