いやまぁいろいろあちこちで議論が出てきたので、まとめて。
もちろん当然ながら、以下は「おいちゃんの見解」であって、それ以上でもそれ以下でもありませんので、その辺は踏まえたうえでご覧くださいませ。
端的に「おいちゃんが個人で自分用の物を作る」んなら議論の余地もなくMagicWeapon一択で終わるのですが(笑
つまりは「おいちゃんでない人」や「個人じゃないところで」とか「他人用のものを作る」場合、それ以外の選択肢の可能性も、十分にあるわけです。
ただンじゃ「選択基準」ってのもいろいろとあろうかと思うので、その辺の指針を考える上での、考察状のポイントを少しまとめたいなぁ、と。
とりあえず「一番多くて」「一番痛い目にあう」のが「＊＊ってフレームワークは有名だしよく目にするから」。
類似品として「＊＊さんがいいって言ってたから」。「＊＊のイベントで」とかそーゆーのも同根。
なんで駄目な論拠なのかはゆっくり述べていきますが、とりあえず上述は気をつけましょう(100%駄目とは言いませんが、それでも99%までは駄目です、実際)。
いや別に「地雷を踏むのが趣味」とか「炎上案件に住んでないと息が出来ない」とか「現場に意趣遺恨の類が以下略」とかいうケースであれば、それをとめる理由もありませんが B-p
とりあえず、何はともあれ「フレームワーク」の定義を先にしておきましょう。
フレームワークは、ぶっちゃけると「面倒なことを」「楽にするための」道具です。少なくとも「楽なものを面倒にする」ものではありませんっていうかンなもん誰も使いません。
フレームワークを使うと、使わないときと比較して「なにがしかのメリット」があるから使うわけで。んで、普通メリットってのは「誰かしら」が「なにがしかのタイミング/フェーズ」で楽であるもの、ってのが定石です。
つまり、必ずしも「プログラマーが」「プログラミングのフェーズで」楽である、だけではなく。「プロジェクトマネージャが」「ソースコードの品質管理のタイミングで」楽である、なんていうケースもあるわけですね。かつ、この条件は必ずしも排他的ではない、って点にも注意が必要です。
えぇもちろん「排他的条件」も存在しますが B-p
で。
上述を前提にすると、ポイントは「何を持って面倒であるとして」「その面倒を、どの方向に展開することでどんな風に楽であるとするか」っていうのが、フレームワークの哲学の根っこでもあり、考察として本質的に重要なところでもあります。
というわけで、以下、そのあたりに焦点を当てて。
TRPGの例題で恐縮なのですが「何を持って初心者向けのシステムとするか」って話があって、よく議論が出てきます。
おおむね２つあって。
・ルールが少なくてシンプルなほうが初心者向けである
・決め細やかにルールと数字が全部決まっているほうが初心者向けである
って話があって、ぶっちゃけ「どっちもどっち」です*1。
端的には「状況にあわせろ」って話ですね。
だとすると。
本質的には、フレームワークの選定基準は簡単で
・「あなたにとって」面倒な、システム開発における四方山とはなんであり
・その四方山を「どんな風に解決したいか」
・自分の「四方山と理想的な解法」に、似通った思想をしているフレームワーク
っていう流れが、一番美しくも自然なわけであります。
ちなみに、現場仕切りが「あなたではない」場合、そこは「現場を仕切る人にとって」にすり替わります。まぁこの辺はやっぱり「リーダーさんに合わせる」のが社会ってもんなので、その辺は「そーゆーもんだ」と思いましょう。
このあたりが「みんな使ってるから」でチョイスをすると痛い目にあう理由その１ですね。
「みんな」と「あなた」では、技術背景も所持スキルも案件内容も今回のクライアントさんの希望も、多分「全一致」はしていないと思うので。
酷いと「全不一致」かもしれませんしねぇ B-p
まぁ理想論ではありますが、実際これが「理想」だと思うので。
少なくとも「自分にとっての、解決したい面倒ごととその理想的な解法」は、ちゃんと返答できるくらいの考察を、日々重ねておきたいものです。
一方で。これとは「まったく別」の見解があります。
具体的には「政治と経歴」。生臭いですねぇｗ
「このフレームワークの経験者」というのは、場合によっては、経歴書上とても有利なケースがあります(その募集の仕方が適切であるかどうか、ってのはともかく)。具体的には、特に「派遣における営業さん」が大変に喜ぶものがございます。受託における営業でも似たようなもんかな。
会社的に「うちはこのフレームワークを使ってサービスを作った」というのは、場合によっては「広報用の武器になる」ケースがあります。場所によっては「人事的に」有利である場合も以下略。
この場合、選択基準は「メジャーである」「案件が多い」「最近注目されていて、今後メジャーになると予想される」といったあたりが基本になります。
もちろん、もうちょっと正確に書くと「腕っこきの技術者にとってメジャーである」と「技術のぎの字も知らない、一発当てたい山師さんにとってメジャーである」とかっていう、ドメインによる差異は存在するのですが。
まぁ、上述、基本的には特段否定するものではありません。
フレームワークの哲学とシステム開発者の哲学に「一定以上の齟齬」があると、いろいろと大変でしょうが(まぁ…「がんばってください」としか言えないですねぇ B-p)。
こういう場合には、その辺の背景(下心|政治)にそったフレームワークを選択しておきましょう。
んで。
実際のところ、本当の戦いは、フレームワーク選定「後」に始まります。
ここ、試験に出るからチェックしておいてくださいね。
本当の戦いは、フレームワーク選定「後」。
とっても大切な事なので、２回言ってみました。
大抵の(愚かな)現場仕切り人*2は、フレームワーク選定が終わった時点で「仕事は終わった」くらいの勢いで次の作業に進んでしまうのですが。
実際のところ、同一のフレームワークを使っても、大抵各人ごとに使い方は「ばらんばらん」になります。
その辺の「自由度の高さ」は、フレームワークとしてはある程度まで「売り」にできるのでしょうが、１つの現場で「十人十色」なコーディングをされても、ぶっちゃけ「邪魔くさい」だけになります。
また。大抵のフレームワークは、割と簡単に「そのフレームワークが本来意図している使い方以外の使い方」が簡単にできてしまいます。
そのフレームワークの目玉の機能を「回避する」的な、ほとんど「嫌がらせ」としか思えないようなコードも以下略。
しかし、それをやると「そのフレームワークをチョイスした意味」が大きく減少します。その状態で「このフレームワークは駄目だ」とか騒いでも、多分見えてる人からは「駄目なのはてめぇの頭だボケ」って切り替えされてしまうことでしょう。
というわけで。
最低限、CRUDであるとかvalidateの仕方であるとかDBとのやり取りの仕方であるとか認証の方法であるとか、基本的な流れについては「こーゆー実装をしてね」という方向性を決めて、ちゃんと全員で「同じような書き方」をしておきましょう。
もちろん、その書き方は、できるなら「フレームワークの哲学に添う」ものを、でなくても最低限「フレームワークの哲学に真っ向から逆らうモノではない」ものを。
このあたりで、きちんと規約を決めた後に「ペアプロ」やっとくと「個体差と隔離によるガラパゴスソースコード」の突然変異確率が下げられてよい感じです。
で、ここが第二の「＊＊ってフレームワークは有名だしよく目にするから」が地雷である理由です。
大抵「有名だから」選ぶ人は、じゃぁその有名どころが「どんな風にそのフレームワークを使っているのか」ってのを理解しないでただ「フレームワークを使えばどうにかなる」って思ってるんですね。
で、実際問題「全く適切なフレームワークの使い方をしていない」上に「各人でばらんばらん」だったりする。
ストラディバリウスやらMartinやらヤイリギターやらフェンダーやらスタインウェイやらYAMAHAやらWurlitzerやら。
これ全部いわゆる「名器」ってやつなのですが、これらの名器を「素人が」ひいても、周りから投げてもらえるのはおひねりじゃなくて、石と怒号くらいのもんでしょう。
道具は大切ですが、同じくらい、道具は「所詮道具」です。
使う人間の練度と教育と、道具への「使い方の考察」が伴って、初めて「それなりに意味がある」ものになるのです。
フレームワークは、うまいこと自分や現場や案件にあうものを選ぶと「とてもよい相棒」になります。
でも一方で「雑に選ぶ」と、それはもぉみごとなくらいに「足を引っ張って」くれるものでもあります。
元々、フレームワークを使う時点で「学習ハードルが一つあがる」訳ですし。
とりあえず、割合とあちこちで「有名だからこのフレームワークを選んだ」「フレームワークを選んだんだから品質は一定レベルが担保できるんだ」という不幸な勘違いを拝見するので。
どっかのタイミングで「書きたいなぁ」って思ってたので、書いてみました。
不幸な事例が、１つでも減るといいなぁ、って、割と本気で切に思ってます orz
