知の壺は管理人「もとやん」がたまに書きたくなったことを書いているノートです。大体誰かに宛てて書いています。2015.09.17シンフレームワーク(薄いフレームワーク)とフルスタックフレームワーク(重厚なフレームワーク)はどちらが良いのか。言えば、どちらがどういうものに向いているのか。最近の私の考えを書きたい。豊富なライブラリまず前提として、開発言語におけるフレームワークに、デファクトスタンダードが無いことがあると思います。rubyにおいてはほとんどrails一強で、マイクロフレームワークとしてのsinatraなどはあるものの、railsの普及度には一歩劣るところでしょう。その言語での事実上の標準が決まっているほどにシェアを持っているものがあるのなら、コミュニティのノウハウの集約度的にそれを使うのが良いと思います。枯れているという意味で。大規模開発に向いているのはフルスタックフレームワークとシンフレームワークの比較だと、前者は大規模開発に向き、後者は小規模なアプリケーションに向いているという説明が多いように私には見受けられます。どれぐらいからが大規模というのか、という問題は人や会社によって異なるので、別に定義をしようとは思いません。基本的にこれは逆のことが多いのではないか?と最近常々思っています。シンフレームワークは大規模開発に向いていて、フルスタックフレームワークは小規模なアプリケーションに向いているということです。理由としては簡単で、プログラム全体のサイズが大きくなればなるほど、フレームワークの占める割合は小さくなります。相対的に自作した時との差が出ない。限定された機能群を持つ薄いフレームワークを採用し、必要な部分を自作していくというのは、システムの柔軟性において大きな価値になります。railsでもよく言われることですが、railを踏み外す(フレームワークの流儀に沿わない設計を行う)と苦労が大きい。最初からrailが引かれていないフレームワークは有利。オレオレフレームワークが一般的に嫌われがちなのは、メンテが滞りがちになってしまうことや、低品質なフレームワークになってしまうことを嫌うからだと思います。あとはドキュメントが整備されていないことによるメンバーの学習コスト。言え、じゃあフレームワークのメンテが滞りがちになってしまうような開発体制の会社で、キチンと社外製のフレームワークのアップデートに追随できるのかとか、開発やサポートが止まっても自分でパッチ当てれるのかは甚だ疑問です。いう開発体制のチームだと、低品質なフレームワークになるのは、むべなるかな。ドキュメントに関しては、懸念点は正しいと思います。ドキュメントを作るコストというのはそれなりに重く、ある程度知名度のあるフレームワーク級に纏まっているドキュメントはジョインしたてのメンバーにとって価値あるものです。薄いフレームワークに、業務やプロジェクトに合わせた内製ライブラリて組み合わせが、大きな開発だといいじゃないかなーと。アプリケーションの仕様をフレームワークの仕様に寄せる権限があったり、フレームワークの流儀に乗って、作りきれるならフルスタックフレームワークOKかと。rails1.6~2.0ぐらいの頃にこういうこと言うと、railsでも大規模サイトできるよ!twitterとかそうだよ!みたいな話が絶対出てましたけど、当時のtwitterのサイズでもrailsの恩恵をどの程度受けていたかは疑問です。プロトタイピングの段階はともかくとして、当時のサイズでもまぁActiveRecordにおんぶ抱っことか絶対無理だし、確実にコア部分にも手を入れまくっていたでしょう。いうことが読めるんだったら、逆に大変ってのも読めるよねー。関連記事スマホアプリを作ることになった。その1ノリでコンピュータ将棋を開発し始めた。コメントをキャンセルメールアドレスが公開されることはありません。views試して分かった。Appsの無料版がなくなったので、無料で使えるメールサーバのニーズが個人的に上昇。ドメインたくさん持ってるので、一つのアカウントで複数ドメイン+複数アカウントを管理できるように作りこみました。無料で履歴書が作れたりするサービスなんです。これが不思議と意外に使われているっぽい。アドセンスは全くクリックされないんだけれども。views試して分かった。Appsの無料版がなくなったので、無料で使えるメールサーバのニーズが個人的に上昇。ドメインたくさん持ってるので、一つのアカウントで複数ドメイン+複数アカウントを管理できるように作りこみました。無料で履歴書が作れたりするサービスなんです。これが不思議と意外に使われているっぽい。アドセンスは全くクリックされないんだけれども。Twitter@calcsさんのツイートタイトルとURLをコピーしました。