読者です 読者をやめる 読者になる 読者になる

おうさまのみみはロバのみみ

ネット上での木の洞

フレームワークの選定

先日↓の話題がちょっとだけ社内で話題になった。

www.webprofessional.jp

個人的にこのエントリは以下の点からあまり真に受けるのは良くないと考えています。

他のフレームワークLoverな方々からはもっとマサカリが投げられると思いますが ぼくが感じただけでも「この内容はちょっと恣意的じゃないか?」と思いました。

ぼくはまだLaravelを使い始めて日が浅いですがそれでもLaravelの設計思想やわかりやすさなどに好感を持っています。 CakeやZend、Symphonyなどよりは好みなフレームワークであると思っています。 (FuelPHPやYiiはあまり馴染みがないので比較できていませんが…) ですがこの内容には少々懐疑的…というか否定的です。

Laravelが優れたフレームワークであるということをぼくは否定しません。 明快な設計思想ですし、MVCの基礎がわかっていれば非常に扱いやすいPHPフルスタック(?)フレームワークだと思います。 ですがそれは他のフレームワークを引き合いに出して比較する必要はないことだと考えます。 閑話休題

何が問題か?

さて本題に戻りましょう。 この問題は要約してしまえばこの1点につきるのですが

「プロダクトやチームによって最適なフレームワークは異なる」

という大前提を抜きにして考えてしまうケースがあるということです。

この辺の話しはフロントエンドフレームワークの話しではありますが先日参加した ng-kyoto#5 の↓が非常にわかりやすかったですね。

www.slideshare.net

問題あるある

たまにエンジニアと話していると「やっぱりこれからは○○だよね!△△はもう時代遅れだよ!」のような発言が飛び出すことがあります。 だいたいこの発言には「△△の何がデメリットで、○○のなにがメリットか」がセットになっています。

ですがその中でまれにこのメリット・デメリットの説明がセットになっていないことがあります。 そういう場合、ぼくは「あ、この人は流行りに乗っかってるだけで思考停止してしまってるんだな…」と感じます。 だいたいまあそんな感じの人が多いという経験からも大きく外れることがなかったですしね。

では問題の詳細はどこにあるのか?

しょせん、言語やフレームワークというのは手段でしかないです。 手段に固執するというのは非常にわかりやすい危険信号ですね。

補足

なんか手段を目的にするのは悪!みたいな書き方になってますが自覚があればOKかなと思ってます。 例えばGo言語で開発したい!なのでGo言語でバリバリ開発している○○社に入社します!とかは全然ありだと思いますし、気持ちもわかります。 問題だと思っているのはこの辺が無自覚な場合ですね。 無自覚に手段が目的化している人というのは他人の意見や客観的な判断が出来ないことが多いので駄目になったとき「めんごめんご、やっぱり○○は駄目だったわ、あれはクソだね!」とか言い出して死ね!ってなりますね。 これはボク自身も含めての話ではありますが。 補足終わり。

当たり前の話しですが会社やチームによって知識や技術的背景というのは異なります。 先程の資料では「マトリクスを書く」ということでその部分の見える化を行っています。

本来フレームワークのような影響力の大きなものはこのような経緯を踏んだうえで選定されるべきだとぼくは考えています。 (これは過去に自分がそれを出来なかったからこそ、より強く実感している内容でもあります。)

つまりはまとめにある以下の手順が守られる、あるいは意識されていればOKです。

  • 現時点でどれだけ知識/技術があるか
  • 要件を整理して、ベター(もしくはベスト)な選択か判断
  • 危険を察知したら"いつもの"を使う勇気

ボク個人として追加するならば「チームとしての合意を取る」が必要かなと思います。 「今度の案件はこれが最適だと思うのでこれでいきます!」となったときに周りを巻き込みやすいからですね。 また合意が取れていれば駄目だったときに「こういう風に考えていたけど○○な点が駄目だった、難しかった」という振り返りの材料にもなるかなと。

まとめ

新しいものは既存の問題を解決するために開発されている。

基本的にはぼくは新しいものに手を出すのが好きですし、楽しいと思っています。 ですがそれは「プロダクトや案件、チームにとってベターな選択かどうか?」とは別軸の評価です。 きちんとマトリクスで見える化していこうな!って気持ちです。

以上、終わり!