なぜフレームワークは難しいのか？
今回は「フレームワークはどうして難しいのか？」「どうやってフレームワークを攻略すればいいか」について考えます。
フレームワークについてはこちらの記事でも説明しています。
主に Web アプリケーションの開発について書いていますが、他のフレームワークについても通じると思います。
スクラッチとフレームワークの断絶
ここでは「(ほぼ) プログラミング言語の機能だけでアプリケーションを開発すること」を「スクラッチ」と呼ぶことにします。
たとえば、PHP では SQL 文を記述してデータを取り出し、結果を HTML に埋め込んで表示しているアプリケーションは「スクラッチ」で作っていることになります。
初心者向けのサイトや書籍でやるサンプルは大体スクラッチですね。
基本的な構文をひと通り学び、お問い合わせフォームや ToDo 管理などのアプリケーションをデータベースを使って実装していく、というのはよくある流れです。
付随して HTTP サーバーや IP アドレスなどの説明も行います。
ほとんどの人がインターネットに日常的に接している現代では、ここまでは直感的にわかりやすいと思います。
たとえばよくある用語は以下のように説明されています。
| 用語 | 説明 |
|---|---|
| 変数 | データを入れておく箱。 |
| 配列 | 複数の箱をまとめて扱う。 |
| データベース | データの保存場所。Excel の表のようなもの。 |
| サーバー | クライアントからの依頼を処理するプログラムやコンピューター。 |
| IP アドレス | インターネット上の住所。 |
初学者でも比較的イメージしやすい言葉が並んでいます。
プログラムを書く場合でも「自分でイチから書けない！」とか「こういうときはどうするかわからない！」といった難しさはあっても、まったく意味がわからないということはあまりないと思います。
ある程度スクラッチでプログラムで書けるようになると、次はフレームワークです。PHP でもっともメジャーなフレームワークである Laravel を見てみましょう。
Laravelは、すばらしい開発者エクスペリエンスの提供に努めています。
同時に完全な依存注入、表現力豊かなデータベース抽象化レイヤー、キューとジョブの
スケジュール、ユニットと統合テストなど、強力な機能もLaravelは提供しています。
これは Laravel のドキュメントの日本語訳サイトの Laravelとの出会い に書かれている一部です。
ドキュメントの冒頭なのに初学者にはさっぱり意味不明な言葉が並んでいます。
Laravel のドキュメントが特別難しく書いてあるわけではありません。使っている人が多いだけに情報量も多く、ドキュメントとしてはむしろ優秀な部類に入ると思います。
現代のフレームワークについて言葉で説明しようとするとこうなってしまうのだと思います。
一見するとスクラッチで学んできたことがほとんど役に立たない。実際、プログラムもスクラッチとフレームワークでは書き方、作り方がだいぶ違います。
これが僕が感じるスクラッチとフレームワークの間の断絶です。
なぜフレームワークは難しいのか？
とはいえ、初学者がいきなり Laravel のサイトを見て学習を始めることは皆無でしょう。
プログラミングスクールや学習サイト、動画、書籍など Laravel を解説してくれる二次的な情報から始める人がほとんどです。
それらの情報がこの断絶をある程度埋めてくれるので、一歩ずつ進めていけば初学者でもフレームワークを使ったり、理解できるようになります。
それでも大きな断絶があることに変わりありません。ここではその断絶、つまりフレームワークの難しさについて考えます。
フレームワークは「結果」
僕は なぜフレームワークを使うのか？ でフレームワークを使う理由のひとつに「巨人の肩に立つ」ためと書きました。
「巨人の肩に立つ」というのは、先人の積み重ねた業績をもとに何かを成し遂げることを言います。
フレームワークは先人の積み重ねた業績の「結果」です。
つまり、どういう経緯で、何が問題で、今の形になったのかがわかりにくく、結果だけを示されているのがフレームワークなのです。
PHP でフレームワークが作られ始めたのはおよそ 20 年前。PHP のフレームワークだけを見てもそれだけの時間の紆余曲折の集大成なわけですから、洗練されシンプルになっているとしても、より高度なものになっています。
これは僕の主観ですが、20 年前のフレームワークは今よりもスクラッチに近く、理解しやすかったように感じます。
認知負荷
認知負荷についてはこちらで説明があります。
人のワーキングメモリ (作業記憶) は容量と情報の保持時間が限られているので、学習するときは一度に多くの情報を与えないように配慮する必要があるそうです。
このサイトによるとワーキングメモリが一度に保持できる情報は 4-5 個だそうですが、先程の Laravel の説明(依存注入、データベース抽象化レイヤー、キュー、ジョブ)でもはやいっぱいです。
しかもスクラッチのときと比べて、ひとつひとつの用語の難易度は格段に上がります。
フレームワークは「結果」であって、経緯がわからないこと。
その「結果」がたくさんあって、しかもそれぞれの難易度が高いため、認知負荷がとても大きいこと。
これらがフレームワークを難しくしている要因だと僕は思います。
それでもフレームワークを使う理由
「そんなに大変ならスクラッチでもいいのでは？」と考えてしまうかもしれません。
しかし、それを乗り越える苦労を差し引いてもフレームワークを学ぶメリットは大きいと思います。
なぜフレームワークを使うのか？ にフレームワークを理由を書いていますが、それらに加えて、ここではエンジニアとしてのスキルに着目してそのメリットを考えてみます。
「結果」を表現するもの
フレームワークは積み重ねの「結果」と書きましたが、「結果」はコードだけで表現されているわけではありません。
なぜならコードは詳細すぎるので、他の人と認識を共有することが難しいからです。
そこで「結果」に名前をつけることにしました。それが考え方やパターンです。
フレームワークを学ぶ上で本当に重要なのはフレームワークの使い方や実装の詳細ではありません。この考え方やパターンを理解することです。
考え方やパターンはプログラミング言語を超える
ひとつの考え方やパターンは特定のフレームワークに特化したものではありません。
「依存注入」や「レイヤー」といった考え方は多くのフレームワークで採用されています。
その考え方はフレームワークはおろかプログラミング言語すら飛び越えて実装されています。
つまり、フレームワークを学び、そこで採用されている考え方やパターンを理解することで、他のフレームワークを学ぶときのコストをかなり軽減することができます。
さらにそれを自分が作るプロダクトに応用することでより柔軟で高度なシステムも構築できるようになります。
フレームワーク攻略法
最後に僕の考えるフレームワークの攻略法を 2 つ紹介します。
初学者はこういう形で進めれば段階的に学べるのではないか、という方法です。
方法1: フレームワークとスクラッチを比較する
１つ目はフレームワークとスクラッチで同じ機能を持つアプリケーションを作り、どういった点が変わっているかを比較する方法です。
この方法の利点は独学でもある程度進められる点です。
1. チュートリアルに従って作る
ほとんどのフレームワークには Getting Started をいう最初に行うチュートリアルがあります。
まずはこれに従って作ってみます。
2. 同じものをスクラッチで作る
次に同じ機能を持つものをスクラッチで作ってみます。
3. ふたつを比較する
1 と 2 で作ったものを比較してみましょう。
Web アプリケーションであれば、以下のような点を比較してみると良いと思います。
- プログラムファイルの構成の違い
- URI の制御 (どのリクエストを誰が担当するか)
- POST されたフォームのデータの受け取り方
- データベースの書き込み・読み込み
- HTML の出力
4. ふたつの差を生む技術(考え方、パターン)について調べる
Web アプリケーションであれば、全体の制御として MVC を採用していることが多いです。
PHP のフレームワークであれば POST されたフォームデータは直接 $_POST から取り出すのではなく、なんらかのリクエストオブジェクトを使っているでしょう。
データベースへの読み書きは ORM を介して行い、HTML の出力にはテンプレートエンジンが用いられるのが一般的です。
こうした技術について、ひとつずつ掘り下げてみましょう。
全部を完全に理解する必要はありませんが、個々に調べていくことで徐々に全体が見えてくると思います。
方法2: スクラッチにフレームワークの技術を取り込む
スクラッチで作った Web アプリケーションに少しずつフレームワークで使われている技術を取り込んでいく方法です。
いわばフレームワークの歴史の疑似体験です。
ダイナミックかつ段階的に形を変えていくので理解は進みますが、難易度が高いのでメンターがいないと難しいです。
1. スクラッチで実装する
なんでもよいのですが、ある程度の規模のデータベースを使うものが良いでしょう。
2. 段階的にフレームワークの技術を取り込む。
フレームワークで使われている技術は個々に独立してライブラリとして使用することができます。
たとえば Web アプリケーションであれば次のように順次取り込んでいきます。
- テンプレートエンジン
- ORM
- バリデーションフレームワーク
- MVC
3. 同じ機能のものをフレームワークで実装する
- 2 と 3 で作ったものを比較する
スクラッチと比べれば、2 と 3 はかなり近い実装になっているはずです。
それでも差はあるはずなので、その部分の実装がどうなっているかを調べることでさらに理解を深めます。
まとめ
スクラッチとフレームワークの間には大きな断絶があります。
この断絶を前にして、スクラッチに行くか、フレームワークに行くかはエンジニアとしてのひとつの分水嶺だと思いますが、僕は断然フレームワークに行くことをオススメします。
とはいえ初学者が学ぶにはなかなか大変です。
今回、紹介したフレームワーク攻略法を具体的なフレームワークで実践した例をいつか公開できればいいなと思っています。
Discussion