このブログで、何度か書いているように、私はフレームワーク反対派です。今日は、フレームワークに対するライブラリの優位性を、開発者のシステム理解度の観点から説明します。
フレームワークとは、システムの大枠です。フレームワークが、システムの共通処理部分を実行してくれるので、一般開発者は、業務ロジックに特化した部分を、フレームワークの処理の流れの中に、組み込むことになります。
図にすると、こんな感じです。
一般開発者は、フレームワークが実行している処理について、ドキュメントを読んで、大まかに理解していることが多いですが、ソースコードを追うことは、あまりありません。
フレームワークを使わずに、ライブラリを使った場合は、以下のようになります。
フレームワークがないので、処理の流れ全体を、一般開発者が作成します。一般開発者は、ライブラリのドキュメントを読みますが、ソースコードを追うことは、まずありません。
一見すると、フレームワークのほうが、ソースコードを読まれる可能性が高い分、システムに対する理解度が増すのではないかと思いますが、それは間違いです。先ほどの図で、一般開発者が、実装している独自処理部分に、注目してください。
フレームワークを使用した場合は、処理の流れの中で、フレームワークのロジックと、業務ロジックが交互に実行されます。これでは、一般開発者は、処理全体の流れを把握するのは大変です。大体こんな処理をしているだろうという想像は出来ますが、完全に全体を理解するには、他人が書いたソースを追うしかありません。フレームワークの中で、理解不能の例外が発生した場合などは最悪です。フレームワークは、取り外し不可能なので、必死で原因を調査して、ツギハギ的な対応をすることになります。しかも、そのような例は、比較的大きなフレームワークでも起こったりします。
ライブラリの場合は、一般開発者は処理の流れを全て把握できます。ライブラリは、処理の流れの中に、特定の機能を組み込むため、一般開発者によって、能動的に呼び出されます。ライブラリの中で、理解不能の例外が発生したら、その箇所では、ライブラリを使わないという選択もできるので、ハマることがありません。
一般開発者が作った画面は、通常、一般開発者によってメンテナンスされます。その際に、処理全体の流れが見えていないと、とんでもないポカをやらかす可能性がでてきます。フレームワーク作成者しか、全体の流れが見えないシステムを作るのでなく、一般開発者全員が、処理の流れを細部まで、理解しているシステムを作る。そのためには、フレームワークという枠組みは邪魔でさえあるのです。