フレームワークの思想、意識して使っていますか?

倉庫・庭付き5LDKの一軒家

大手メーカー提供でオプションもいっぱい。施工前なら台所やトイレの位置も変えられたり、ユーザーの細かいカスタマイズを実現。

部屋もたくさん、誰がどこに済むかもご自由に。どんな家族構成でも、どんなライフスタイルでも、対応できることでしょう。周りの家も同じ作りをした家ばかりなので、部品の交換や建物の修理など、平準化されていてとっても安心です。

間仕切りない1LDKのデザイナーズマンション

間仕切り少なく、広く開放感のある空間で、小窓からそよ風を取り込み、ソファの位置でちょうど快適リラックス、家族のコミュニケーションも絶えない広場。

デザイナーによてセレクトされたオシャレな収納家具付きなので、あまり準備せずに住むこともできます。ライフスタイルの提案付きで、レールに乗れば想像を超える快適さ。普通の住宅では味わえないサービスが満載。

狙ったメリットの享受

ぜんぜん違いますよね。この二つ。メリット、デメリット、大違いです。でも、世の中にはどちらもしっかりと存在しています。互いにニーズもあることでしょう。

5LDKの一軒家であれば、幅広い選択肢の分、ちゃんと考えて住まないとへんてこりんなことになります。1LDKのデザイナーズマンションであれば、提案されているライフスタイルと全く違うスタイルの生活をしようとすると、そのギャップで苦しみそうです。逆に...それぞれの思想がわかっていいて、それを狙ってメリットを享受するように判断していけば、すごく良い生活をしていけるでしょう。

フレームワークの思想

さて、ライフスタイルは、まさしく...

「プログラミングスタイル」
 or
「開発スタイル」

と言えるでしょう。

ディベロッパーにとって、
フレームワークは家のようなものです。

そこに住んで生活...
じゃなくてプログラミングをするわけです。

そして当然のことながら、
フレームワークにも思想があります。

なので、フレームワークの思想をちゃんと意識して、それを狙ってメリットを享受するように判断していけば、良い開発をしていけるでしょう。

(もし、思想という言葉がおおげさだと思うなら、「作り手の考え方」という言葉に置き換えても良いでしょう)

思想がわかってると?

フレームワークの思想がわかっていれば...

どう書けばフレームワークを最大限発揮できるかわかる

これに尽きます。同じことを実現するにしても、プログラミングは千差万別です。色々と迷いしますし、みんなで迷えば統一感のないコードで埋め尽くされるでしょう。プログラミングにおける判断要因の大きな一つとなります。

また、身近なところで言うと、機能の有無、機能の場所や名前、クラス名やメソッド名の推測がしやすくなるでしょう。もちろん、推測だけじゃなく最終的にはちゃんとした確認はしないとですが、かなり当たりを付けやすくなるでしょう。

などなど、住宅の例を想像すれば、思想をわかって使うことのメリットの大きさは想像ができるでしょう。

思想がわかってないと?

逆に、それを理解せずに使うということは、なにかいびつな使い方をしてしまうかもしれません。

単純に「もっとこうすればスムーズでより簡単に書けたのに」という効率の面も去ることながら...

「その "いびつさ" が原因で本番でパフォーマンス問題が発生した」

「その "いびつさ" が原因で本番でよくわからない問題が発生した」

「その "いびつさ" が原因でバージョンアップのときにすんなり動かない」

とかとか、十分ありえるわけです。

特にバージョンアップの話は重要です。けっこうフレームワークに近い部分、ちょこっと拡張が必要な部分とかで「動くからどっちでもいい」と適当に実装してしまうと、バージョンアップの大きな足枷になりやすいので、些細なことでも「こう書いてたほうがフレームワークは都合が良いだろうな」というのも想像しましょう。

また、コミュニティやコミッターに質問や相談をするときも、その "いびつさ" でコミッターも非常に答えづらい、なんて可能性も出てくるわけです。「そういう使い方をしているのであれば、こっちももう何もわかりません」と言われても仕方ないものです。フレームワークの作成者からすると、そういう使い方は想定していないわけなので。

jfluteなんかは「できるだけコミッターのいやがる使い方はしない」という感覚でいます。コミッターに会えることの方が圧倒的に少ないですが、ドキュメントやコード読んで、作りから思想を推測して自分なりに解釈することはできます。まずは "意識" です。

【追記】なので、企業がコミッターを雇ったり、コミッターを顧問に迎えたりするわけですね。そばにいるならどんどん話を聞いて欲しいと。

あえて違うやり方でも

とはいえ、時には思想に反する使い方をすることもあります。細かいところで現場の要件を合わなければ当然そうする必要があります。というか、けっこう jflute はやりますね(^^。(あれっ!? えっ!? ...時にはですよ。必要なんだから^^)

ただ、それは "わざとそういう風にやる" という意思があるのとないのとでは大違いということです。おおげさにコメントを書いたり、その拡張部分などをアプリの中で散財せず局所管理したりなど工夫は欠かせません。少なくとも、それに対する責任は常に頭の片隅に置いておくことでしょう。

そのいびつな部分で、先の通りパフォーマンス問題や、よくわからない問題や、バージョンアップしづらい問題が発生するかもしれませんから。

技術選定のときにも

そして、これ、技術選定のときにも重要なことですね。

フレームワークを選ぶというのは、
思想を選ぶ

と同義です。

思想が合わないのであれば使わないほうが良いし、使うのであれば思想に合わせるような意識でいたほうが良いでしょうし。選ぶ判断に大きく影響を与えるでしょうし、その後の施策などが変わってくるわけです。

作り手の意図と良い使い手

フレームワークの作成者が「こういう風にしたらいいんじゃないか?」という考えのもと、デザインをしています。フレームワークは、単なる機能の集まり(機能群)ではありませんから。

フレームワークがわかりやすい例なのでフレームワークと書いていますが、プログラミング言語やその他ツールなども同じですね。なんでも同じです。

作り手の意図を引き継ぐかどうか?
は別にして...

作り手の意図を大切にすることが、
良い使い手となる条件の一つ

でしょう。

...

【追記】こちらにも通じる話ですね。
 => 応援してる "A" にもデメリットはあるよ
 => フレームワーク選定という寂しい工程と一つの希望

f:id:jflute:20181014184036j:plain