フルスタックよりも、シングルタスクの方が良いんじゃないか、という話

読了まで:約5分


概要: フルスタックフレームワークよりも、シングルタスク


いつもなら こんにちま! で始める所ですが、 今日はまじめに語りたいので、ユヤタンのパロディは封印しておきます。

本日の議題: フルスタック or シングルタスク

僕は思うのですが、Web アプリケーションフレームワークとか、 あるいは O/R Mapper とかについては、 機能満載のフルスタックフレームワークを使うより、機能はしぼられていても、 拡張がしやすいシングルタスクフレームワークを使った方がいいんじゃないか、 と思ってます。

なんでかっていうと、フルスタックフレームワークは、 型にハマった作業を行うときにはとても役に立つと思うのですが、 型から外れた作業とか、あるいはちょっと変則的な技を使おうとすると、 とたんコストが跳ね上がるように思うからです。

また、フルスタックフレームワークは、 モノによりますが速度面とか、リソース消費面でも、 シングルタスクフレームワークに劣るコトもあり、 メモリとか CPU をじゃぶじゃぶ使える環境なら良いかもしれませんが、

安 VPS しか使えん とか、あるいは _ 共有サーバで CGI という地獄_ とか、

そういったリソースの省エネが要求される環境では、 使いづらいと思うのです。

あと、一番重要というか、これからフレームワークを選ぶプログラマーに重要なのは、 そのフレームワークの 学習コスト だと思います。

まず、大抵のフルスタックフレームワークは、そのフレームワーク流の、 流儀というか作法みたいなモンがあり、それを学習するのに、コストがかかる、 というのは誰しも納得が行くことだと思います。

で、僕みたいな、 プロフェッショナル開発童貞 なんかは、 完全な独学でプログラミングをやってきて、 プログラマーなら知っておくべきデザインパターンとか、 あるいはデータモデリングの方法論、 大規模開発における負荷分散とか、 そういったプロフェッショナルな領域というのが、さっぱりさっちゃんなワケです。

で、そういった状態で、フルスタックフレームワークを使おうとすると、 大抵フレームワークに振り回されて挫折します。 というか挫折しました 。 Catalyst とか Django とか無理だった。DBIx::Class とか暗号文!

んで、その分シングルタスクなフレームワークは、実装がシンプルで、 やれることも少ないけど迷わずに済み、またリソースも省エネ、 という感じで、非常に使いやすい感じではあります。

もっとも、シングルタスクフレームワークは、シングルタスクな分、 ちょっとしたコードでも追加コードを書かなきゃいけなかったり、 あるいは複数人で作業する際にクオリティーが一定しないとか、 あるいはライブラリ自体が枯れてなくて、 企業ユースのプロダクション環境では使えない! とか、一応、問題となる点がない訳では無いと思います。

まあでも、本番環境に裂けるリソースが少ない、 個人とか小規模のスタートアップとかだと、しがらみも少ない分、 そういったシングルタスクフレームワークを使うのもありなんじゃないかなー、 と思います。

もう一個の議題: ブラックボックス化はアリかナシか

で、このフルスタック or シングルタスク問題(今名付けた)に関連することとして、 フレームワークの内部処理が、 ブラックボックスとなる問題について考えを書いていくと、 僕は、

  1. コンポーネント単位(モデルとかビューとか)でのブラックボックス化は _ 推奨_
  2. アプリケーション全体が暗号文化することは _ 絶対に避けるべき_

と思ってます。

で、 1.コンポーネント単位のブラックボックス化は推奨 、というのは、 モデルとかビューの場合、場合によっては、最初の作業時からの要求が変わり、 MySQL の変わりに MongoDB 使いたい! とか、あるいは、 テンプレートエンジンを C 拡張を使った高速なモノに切り替えたい! と言ったような場合、コンポーネントの内部変更に伴って、 コントローラー側で使う API もかわってしまう、というコトを避けるために、 積極的にブラックボックス化していくべきではないかなーと僕は思います。

逆に、フレームワークに振り回されて、アプリケーションでのコード全体が、 暗号文のような、何が何だかわからない……、という状態になるのは、

絶対に避けなければならない 、と僕は思います。

と、言うのも、自分の書いてるコードが暗号文化すると、 後で修正するときにめっちゃ困りますし、また、企業内とかで、 コードの引き継ぎとかする際に、後任の人がウボアします。

なんで僕は、極力何やってるかわからなくなるようなフレームワークは、 あんまり使わない方が良いんじゃないかなーと思います。

議題終わり

という感じで、以上が今日僕が朝っぱらになんとなくぼーっと考えていた、 アプリケーションとかでのフレームワークについて考えていたコトです。 ま、こうやって考えを書いてみると、結構スッキリするなー。

で、まあ僕は本格的な開発というか、 いわゆる ジョブとしてプログラミングをしたことがない ので、 実際に企業に勤めてるプログラマーの方だと、

いや、そのりくつはおかしい とか、色々変な所があるかもしれません。

まあでも、上記のコトは、僕が 2006 年からプログラミングをやってきて、 ようやく理解しつつあることなので、まああんまり外れてはいないかなー、 とは思いますが。


というような感じで、今日はプログラミングに関係する考え事をまとめて見ました。

まあそもなんでこんなコトしてるかっていうと、最近ブログのアクセスが減ってきて、 もうそろそろブログの内容を自分の得意分野にピボットした方が良いかなー、 なんて思ったので、自分の意見を書いてみた次第です。

っていうか僕、最近、プログラミング系記事を書いても、 あんまりぱっとしないというか、自分で読んでもわかりづらい記事しか書けてないので、 やっぱりプログラミング本体の内容より、 それにまつわる考え方なんかを発信していった方が良いのかなー、なんて思ってます。

まあこのブログ、空繰再繰(カラクリサイクル)は、 一応 Tech 系のコトを中心に、とか考えているので、 今後もそれに関連する今日のような記事を書いていきたいと思います。

というワケで以上で、本日は筆を置きたいとおもいまふ。

ノシ

#FIXME

にゃるら(カラクリスタ)

『輝かしい青春』なんて失かった人。
次に備えて待機中。

今は趣味でプログラミングをして
生活しています。