イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです


このエントリーをはてなブックマークに追加

なぜフレームワークを使うのか

こんにちは、日々メダリストたちの勇姿をみて「まだまだ鍛え方が足りないな」と決意を新たにしている塚本です。残暑お見舞い申し上げます。

今回はフレームワークのお話です。

Webアプリケーション開発においてのサーバサイドフレームワークの話です。

サービスを作る際に、なんの言語を使い、どのフレームワークを用いるか という議論は避けて通ることはないテーマかと思います。

調べればそれぞれのメリット・デメリットは出てきますが、そこそこ使われているフレームワークたちはおおよその機能はカバーしており、目に見える差がなくなってきています。 なので、([APIのみ作るのでマイクロフレームワーク]というようなピンポイントのケースを除き)使ったことがない人にとっては、世の情報が判断材料になり得ないケースが見られます。

ここで、「その前になぜ私たちはフレームワークを使用するのか」から考えてみましょう。

Webにおけるアプリケーション開発とは、

  • URLにアクセスしてリクエストされたデータをデータベースから取得し、そのレスポンスをブラウザ上で表現する

  • 二者間通信はHTTPプロトコルベース

というざっくり概念の上で行われます。

この概念に実装を載せるにあたり、上のフローを粒度細かく分割し、それぞれの役割を担当するコンポーネントを集めて機能するようにしたのがフレームワークであり、 誤解を恐れずに言うと、"それらの再開発を避けて、これから作るシステムのビジネスロジックに集中できるようにするため" フレームワークを使います。

例えば、POSTリクエストの扱いであったり、ルーティングの振り分け、レスポンスのボディをHTML形式に変換したりは、ドメインレベルに関係なく共通に行われる処理です。

こういった部分の実装は、フレームワークに任せてしまおうという理由が一般的には大きな理由です。

さらに、それらのコンポーネントがパッケージとしてOSS上でアップデートされているものならば、自分たちの運用コストも減ります。
また、それぞれのフレームワークにはソフトウェア設計に対する思想が乗っかっており、考え方がカチッとはまるのであればその思想に身を委ねてしまうほうが楽であります。 (大方のフレームワークには、ジェネレーター的なコマンドが用意されており、それを使って内部アーキテクチャを構築してほしいという願いが垣間見えます)

と挙げていけばキリがないほどに理由があるわけですが、当然 "使わないことと比べてのデメリット or 使わないケースのメリット" もまたキリがないほどあり(ここでは割愛しますが)、 その双方を天秤にかけた結果、 「使ったほうが生産性が高い && その他もろもろ」という判断がなされ使用に至ります。

大した前段構えた割にはありきたりな結論ですが、フレームワークを使う理由は大まかには以上な感じです。

しかし、後々大きな意味を持ち始めるものでありながら、議論の的から外すべきでないポイントが有ります。 先述のフレームワーク作者の思想にも関係してきますが、結果的にそれはチームや開発者の今後の方向性や指向性を大きく左右するものです。

フレームワークの自由度

世に出ているOSSのフレームワークには程度の差こそあれ、独自の文法みたいなものが存在します。

例を挙げてみましょう。 Webフレームワークと言えば代表の一つがRuby on Railsで、RoRと言えばConvention over Configuration(設定より規約)です。 要は書き方であったり、設計パターンを決めてしまい、「こういうときはこう書くんですよ」とルールにしてしまえば、ただでさえ考える事が多いのを少しは減らすことができます。 Railsはこれがキッチリ固まっている代表格でありフレームワークとしての自由度は低いです。 PHPのような元の言語の規約自体が緩い場合、同じI/Oをもつメソッドでも色んな書き方ができるため、「どれがよいかなー」と考えることに時間を取られるよりもフレームワークに決めてもらったほうがよかったりします。

そしてその規約が緩いほど「自由に書いていいよ」という思想の現れなのですが、ある程度チームメンバーのスキルが一定の水準に達していれば、自由度が高いほうが好まれる傾向があります。 また逆に、規約でガチガチに縛ってもらったほうが、バラつかなくて良いという人もいます。

このように使い始めの段階としては、好みの問題で自由度の話はでてきます。

けれど、この自由度の部分は使い続けていくほどに、開発者がどこに時間を使うことになるのか、何の腕を磨くことになるのか、といった部分にしぶとく影響していくため、 "(フルスタックではないけれど)何でもできるようになりたいと思っていた"人の意向に実はそぐっていなかった。 といった事態にもなりえます。

ここが自分たちを苦しめもするし、楽にもするので、後々「好みの問題っていうほど軽くなかった」となることがありました。

つまり、「自分たちがどういう技術者集団であるか」という観点でこの自由度の部分を議論しておくべきだと思います。

定義が曖昧であることを捉える

Web開発の歴史を浅いと捉えるか、そこそこ歴史が積み重なってきたと捉えるかは人それぞれでありますが、未だに言葉の使い方使われ方、定義やイメージが固まりきっていないため 「なんか話が噛み合ってなかった」といったツライ思いをすることがあります。

例えばMVC

Web Framework Img

(解釈に幅があるとしても)多くの開発者に馴染みがあって、理解もしやすいアーキテクチャパターンであるからして、MVCを当然として採用するのが私のキャリアの中での通念でした。 しかし、複雑なプロダクトそのものが示すように、モデルの役割とは余りに幅広く曖昧すぎて、もはや何であるかわからないことがよくありました。

「もっと違う言葉で、具体的に定義して、MVC自体を考えなおそう」

なんとなく近年はそういう流れがきているように感じます。 (むしろフレームワークのほうからDDDへアプローチしていっているようにも見えますが、みなさんいかがでしょうか?)

このように、多くの人に使われるようになることで、解釈の拡大が進み、言葉が生み出された当初の意図とかけ離れていく という現象はフレームワーク界隈でも多く見られます。「このことを意識しながら情報をキャッチしていかないといけない」という面倒さと向き合いましょう。

余談

直近のプロジェクトでPHPのLaravelを使用しておりまして、LaravelはいつからかMVCを謳わなくなったそうです。 LaravelとMVC

ここでもMVCをなんと捉えるかによって、LaravelはMVCであるとも言えるし、そうでないとも言えると言及されています。

「Eloquent=モデルみたいな誤った理解が広がっていくのを止めたかった。だからModelsを無くした」というのはすごくワカル。 そもそもコントローラーでEloquentモデルを利用することは密結合ですしね。

このように理解が異なる言葉を前提に進めることは明らかにリスクのほうが大きいように思えます。

とはいえ、

  • Web開発の世界では「関心の分離」はすべき

  • コントローラー的な役割の必要性は変わらないと言える

  • 問題はMの部分でORMとごっちゃにしている人が多い

(流れ上、誤解されそうなので釈明しておくと)だから、MVCライクなパターンは変わらず指針としてあるべきで、モデルの定義が曖昧なままで良いわけでもなく、正解はその現場のチームが持っているはずのドメインモデルです。

という持論です。(余談ここまで)

まとめ

長々とまとまりのないことを書きましたが、個人的意見と言いつつ断定してしまえば、

チーム開発で最も重視するのは、

ソースコードの再利用性とテスト可能性、プラス可読性

です。

フレームワークを利用することはこれが担保されやすい。

さらにそれよりも、チーム開発においては、個々のスキルやビジネス理解の不均一があるため、共通言語を構築する作業が必要であり、 それにフレームワークを利用するという手があります。デザインパターンの話を合わせるのにも使えますし、上記の「モデルとは?」みたいな話にも持っていきやすいかと思います。

気が向いたらどれを利用するのかについての話もいつか書きます。

追記

テスト書かない問題 OR 書けない問題

別途諸々ありますが、せっかくなので書きたいですよね @twadaさんお呼びするとかですかね。

こちらからは以上です。