コンポーネント指向って微妙かもしれない
Vue CLI 3を触ってみてVUEXとかNextだかNuxtだかReactだとか言うものは正確には分かっていないがひとまずコンポーネント指向ってそんなにイケてないんじゃないかな？と思いはじめてきた。たんにJavaScriptの仕様にまだモヤモヤしたものがあるからで、上手く使えていないだけと言われればそれまでなのですが、万能なものではない。
万能薬は色々マゼコゼしているうちに肥大化していき、一体何かが効いていることは分かっているのですべて詰め込みはじめる。体に良さそうなマルチビタミンと同じ。含まれているメソッドのなんかが作用していればOK…っていうことになるが、違うと思う。
特にソフトウェアにおいては、いくらストレージやメモリ領域はムーアの法則に従って大きくなり続けるとしても、根本的な解決にならない。同サイズでのパフォーマンスに悖るならいつまでも鈍いマルチタレントだ。吸血鬼を一掃する銀の弾丸はない。少なくともすべての言語に言えることだが、言語仕様とそのライブラリの隅々まで理解していないと、根っこにある問題解決に時間がかかるので、開発生産性は劇的に改善しない。単純なアプリケーション開発であれば、ライブラリ/フレームワークはベストな選択かもしれないが、それ意外の場合において肥大化はコストでしかない。
補足：テスラ社は技術的に優れているのではなくビジネスの発想が優れている？
どこかの掲示板で読んだのだが、テスラのEV社は技術が優れているのではなく、電池を増大させて航続距離を伸ばしたり、サブスク製にするなどのビジネスを含めた採算性が優れているという。
話はそれに近いものがあると思う。
鈍重な車両になってはダメだし、軽自動車は別分野のビジネスということになる。それぞれのビジネス領域における最適解を探さないといけないから、すべての自称に適用できる優れた法則があるわけではない。また、結局の優劣はビジネスの成功によって決まるところもある。
プロである以上はビジネスは無視できない（ただし商売と技術は別物ではある）
補足：場当たり的な肥大化
あまりフロントエンド界隈では言われない気がするがjsにも同じことが言えるのでは…
Javaや.netのようなクソデカランタイムもつらければ、dockerやsnapやflatpakのような全部入り環境も辛いし、Electronみたいなブラウザー組み込みもつらいし、本当に世の中は根本的な問題解決を取らずに場当たり的な対処出回っている。 https://t.co/irGCP5wf5w
— Ryou Ezoe(江添 亮) (@EzoeRyou) February 19, 2021
コンポーネント外の共通ライブラリを外出しすることなどは当然だとしても、それを仕事に追われながらフロントエンドのコードをなんとなく量産している人に言うのは酷すぎませんか。どれぐらい世のフロントエンド屋さんが忙しいか知りませんが。
「すごい商品ができたけど質量がが従来の３００％増です！」…それは本当にできたと言えるのか？問題。
性格とプログラミングスタイルの問題
あと自分の性格が大雑把なのと、１人で生産することが多いからなのか、コンポーネント（部品）を生成して組み合わせる工場ライン化みたいなことには向いていないと感じる。複数人で開発する場合はコンポーネント化が重要かもしれないが、そのようではない１人開発では無駄が多くなる。そのような性格に加えてメンバーが単か少か多かによってプログラミングスタイルは変わってくる。プログラミングはひとりでやるもの…と言う人は、チーム開発でのパフォーマンス最大化とどう向き合うのか（課題）。
オブジェクトとコンポーネントの粒度差
オブジェクト指向とコンポーネント指向の最も大きな違いは、（雑に言えば）粒度のサイズだと思う。オブジェクトよりコンポーネントのほうが粒度が大きくなりがちだろう。これはコードのサイズとかメソッドの数の平均値が多いとかではなくて、１コンポーネントに向き合う時間というようなニュアンスで言っている。
オブジェクト指向は整然としたものに見えるが、コンポーネント化は必ずしも規則性はないのでは？ユーザの要望の数だけ下位のコンポーネントが肥大する気がして、なんだか想像すると疲れる。慣れの問題かもしれないけど。
もちろん、そもそも抽象度が違うとか性質の差がオブジェクトとコンポーネントの間には横たわっているというのは、重々承知の上なのだけど、今の段階で自分の頭を整理すると、おおよそ上記の差が横たわっているな…、と思っている。
ここまでのまとめ
最適化より成果物を、最適化こそが成果物、と言えるようになりたい（愚痴
機能は完成したのでリファクタリングが終わったら完成です（謎
リファクタリングしたら壊れました（もっと謎
自分の悪い癖でもあるのでしょうが（汗
最後にイベントを前提に何が発生するのか？を定義したほうが人間の直感的に分かりやすいのでは？と思っているということを書きたかったのですが完全に忘れていました。
…イベント指向プログラミングという言葉があることを知った。
いや、イベントベースと言うのは、原始的でデスクトップアプリ全盛の時からあるものだと思うが、より膨らましてイベントの連動性を可視化するような考え方を挿入しないと複雑なプログラミングだと頭パンクしませんか？というのが最近のワタシの疑問というか提案です。
たんに、脳が古いだけかも…とも思っています。
物が先か態が先か…という話ですが、「態」つまり動かす意思が先にあって初めて「物」が動くのではないだろうか？
たい焼きが食べたいからといって、たい焼きを食べようとしてもうまくいかない。
食べたい思いがたい焼きを作らせたり、たい焼きを探し出して食べるのではないでしょうか。
（うーん、われながらわかりにくい）
コメント