gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

せっかくなんで考えてみたい「モダンってなにさ?」

元ネタ
「モダンなPHP Framework」と「PHPdisって申し訳ございませんでした」
http://blog.sumyapp.com/2014/05/modern-php-frameworks/


とりあえず「弁明にすらなってないよねぇ」ってのは置いといて。
ちと違う角度から「興味深いなぁ」って思ったので、再度、取り上げてみたいと思います。


まず、ざっくりと全体を突っ込んでから、本丸に。

個人的に今後のPHPフレームワークにおいては、下記がキーポイントになってくるのではないかなと思っています。
DB Scheme、ライブラリ管理、テストツール、優れたテンプレートエンジン、優れたORマッパー(Hashじゃなくてオブジェクト返してね!)、高い可読性、実行速度、低学習コスト

「DB Scheme」が何を指してるのか不透明。多分「DB マイグレーション」あたりを指してるんだろうなぁ、って思う。或いは「Scheme マイグレーション」。
これが「全体としてのRDBMSの移行ツール」なのか「スキームのバージョン管理」なのか、ってのもあるんだけど、多分今までの文脈から、後者と仮定。
ん…個人的には、要不要できかれると「欲しいけど辞めといたら?」って思う機能だ。
確かに「ちょっとした所で便利」なんだろうけど、そこにガッツリよりかかった時に、どちらかというと「面倒な事象」ばかりが想像つくので。
おいちゃんはよく「劇薬」って表現をするのですが、「用量用法をまもって、最低限」ってのがいいように思う。
詳細な考察は一端オミット。要望があったら書いてみます。


「ライブラリ管理」も結構不明 & それって「フレームワーク」で持つものなのか?
個人的には「複雑な依存関係、になってしまった」時点ですでに一敗しているので。基本的にはまず「負けないこと」。
で、やむを得ず「負けてしまった」場合の、次善策として、composerとか。…でも、正直、おいちゃんは「開発手法」でカバー出来ているので、composerのメリットをあんまり感じてはいないんだけど。
「開発手法」を、広義な意味で「フレームワークに含む」ってんなら、まぁ。でも昨今のフレームワークって、違うよね?
うちのMagicWeaponにしても、開発手法は「オプション的に」提供しているだけだし。


「テストツール」も激しく微妙。
勿論必要なんだけど「それ以前の問題」も多いし。
後、多少なり好みとか背景とかもあるので、「フレームワークで1つを決めうち」は、あんまり好まない方向性かな。
この辺の細かい議論も一端オミット。


「優れたテンプレートエンジン」は、優れた、の方向性にもよるんだけど。
「最低限の機能で性能がめちゃくちゃよい」ならいいんだけど「多機能」の方向性なら積極的に「イラんってかヤメロ!」って感じだ。
テンプレートエンジンは「ロジックとデザインの分離」が哲学だよ? ってのを、忘れてないのかしらん?(苦笑


「優れたORマッパー(Hashじゃなくてオブジェクト返してね!)」もおいちゃんは否定的だなぁ。
否定は「優れた」にかかるんじゃなくて「ORM」にかかるんだけど B-p
いつも思うし質問もするんだけど「なぜSQL文書かないの?」
ここで、おいちゃんが腑に落ちるレベルの回答をみたことがないんだよねぇ。
「本質的な哲学」の部分では特に否定をしないんだけど(肯定もせんが)、現状の実装をみていると、割と積極的に「否定したい」んだよねぇ、正直。
「ちょろっと使う」分には便利な事も多々あるんだけど、少し進むとあっという間に色々あるので、結果的に否定的な見解に傾くかなぁ。


「高い可読性」これをフレームワークに求めるのは色々とどうなんだろう?
フレームワーク以前の問題じゃなかろうか?
フレームワークに起因して、可読性が落ちた」状況ってのが、今ひとつ想定しにくい。「裏であちこちにプログラムカウンタを動かすから全体の流れを追いかけにくいフレームワーク」ってのはあるけど、そーゆー意味かしらん?


「実行速度」も…勿論「FWがボトルネックになってる」ケースもあろうけど、それ以外がネックになってるケースのほうが多いように体感しているので、そこを「フレームワークに求めても」なぁ、ってのは、色々。
まぁ「より軽いFW」ってのは勿論考え方としてもあるし必要だとも思うんだけど*1


「低学習コスト」これはまぁわかる。
ただ「何を以て"低学習コスト"とするのか」っていう部分については、丁寧な議論が必要な気がする。


…とまぁ、初手から突っ込みどころは満載でございます(苦笑
面倒なんで、個々のFWのあたりは省略。
…まぁ「感想」だと思うので、いちいち突っ込んでもねぇ。


で、次。

ただ要注意なのが、低学習コスト系フレームワークは「おれおれコード」みたいなのになってしまいがちなんじゃないかなと。

…あぁ、「低学習コスト」って「自由度の高い ≒ ルールと縛りの少ない」って意味合いなのかな?
根本的な勘違いがあるような気がするなぁ…ってのがおいちゃんの感想。


んと…フレームワークってのは本来的には「お道具箱」なので。
「無くても一式作れるスキルを持っている人間」を前提に「でも合った方が楽だよねぇ」なお道具が詰まっているモノ、だと、本来的には思うです。
ただ、一方で「スキルを持っていなくても、お道具箱のマニュアルの通りに作ると、それっぽいなんちゃって、くらいまでは出来る」ようなフレームワークも、勿論あって。
その辺の「本来要求されているスキル」部分とかを念頭から外して考えると、色々とヒドイ事になるんじゃないかなぁ、っと。
まぁここの考察はある程度省略。
ニーズがあったら別途書きますんで言ってくださいませ。


で。

なぜPHPをdisったかというと、「とりあえずCakePHP」「とりあえずCodeigniter」で開発をスタートしちゃう人たちが未だに多いように思うからです。PHP言語自体をdisる気持ちはありません。

うんだとすると書き方としては「PHPではなくPHPerをdisったんです」ってお話。

CakePHPのような実績あるフレームワークは実績がないフレームワークより良いような気がしますが、享受できるはずの恩恵を受けられないフレームワークを今から使いはじめるのはもったいないなと思います。

ん…まず「享受出来るはずの恩恵」ってのは何で、それは本当に「恩恵なのか?」って考察があって、ってのが全部足りて無くて。
ついでにじゃぁ「PHP以外の言語では、そういった事象は存在せず、PHPerだけが、そのような状態になっているのか?」っていうところへの考察も言及もエビデンスもなくて。
それでは、「書き殴る」にしても色々と足りない過ぎて「意味も無く反感を買って不要に炎上させるのが目的ですか?」って聞かれて、Noと言える根拠とかが、今のところあまり見当たらない感じ。

とりあえずRailsの方がとりあえずCodeigniterよりはまだマシかなという気がするのも理由の1つです。レールが厳しいですから

「気がする」を理由にしている…より正確には「気がする」以外の論証もエビデンスも考察もなにも出していない時点で、煽る意図、以外のなにも感じられない感じですねぇ。
当人は、facebookで「意味が無い記事を描いているつもりはない」とおっしゃってましたが、「ボクがこう思うから駄目」ってのは、何かそこに「大きな意味を感じ取れる」とは、到底思えない内容です。


で…多分、この辺から核心になっていくのですが。

もっと「モダン」を触ったり、スキーマファイルを書いたり、今後エンジニアが楽するための時間を業務時間中にくれよ!というところです。

せめて新規プロジェクトは全て「モダン」で行きましょうよ!そのために、モダンを使えるようにしましょうよ!と思います。コピペエンジニアが書いたコードを後から保守は皆さんしたくないですよね?

一言で片付けると「モダン、って言葉に固執する老害になるんだろうなぁ」としか思えない状況だなぁ、と、みています。


まぁ、所謂「モダンプログラミング」とか「モダン開発」ってのは、実際、割と声高に歌われる事も多くなってきた昨今ではあるので、少しここで、考察をしてみましょう。


まず「モダンってなんだろう?」って思う訳なのですが。
http://dictionary.goo.ne.jp/leaf/jn2/219236/m0u/%E3%83%A2%E3%83%80%E3%83%B3/

[名・形動]《「モダーン」とも》現代的であること。今風でしゃれていること。また、そのさま。「―な建物」「―な人」

「近代」って言っちゃうとまた色々と意味合いが異なってきそうなのではあるのですが。
いわゆる「モダンプログラミング」とかが出てきた背景って「それ以前の、コピペ万歳だの動いてるコードは触るなだの関数さえまともに切れてないだのバージョン管理はコメントですだの」といった、諸々の「困った古い、レガシーコード」に対するアンチテーゼだと思うのです。


んと…技術は、本来的に「無くて困っている人が、困らなくするために編み出す」のが技術で。
その「せっかく困らなくするために編み出した技術を使わず、困ったままで居る」のがいわゆる「レガシーコード」とかの類いで、それに対するアンチテーゼとしての「モダンプログラミング」ってのがあるんだろう、と思います。


…が、ここでまず、一差し、水を注いでみます。
「技術ってのは本来、枯れててなんぼ」な世界です。
人間の頭の中にあるうちは、全て名画で全て神ゲーです。それを実装すると「思いも寄らない」糞になり、使い続けていくうちに「さらなるアラ」が出てきます。
枯れてる技術ってのは、その辺の風雪に耐えた、耐えてきた、耐えられた技術です。


その辺を考えた時に。
別に「枯れてる技術が全て素晴らしい」とか言う積もりはないのですが、一方で「モダンだから全て素晴らしい」のか? ってのにも、一定の疑問を投げておかないと、とても危ないと思うのです。
いわゆる「モダン」は、その辺の「長年の風雪に耐えた」実績がないので、もしかすると「びっくりするような問題を抱え孕んでいる」可能性、が、否定できないので。


ついでに書くと「何がモダンで何がレガシーなの?」「レガシーって本当に駄目なの? なんで? その駄目が"駄目じゃない"例外ってどんな時?」「モダンって本当にいいの? なんで? そのいいが"良くない"例外ってどんな時?」っていう、丁寧な考察が、全部きれいさっぱり吹き飛んでいるです。
っつかそも、いわゆる「モダンな技術」って、ほとんどが「レガシーの上に立脚してる」ですしねぇ、とかって突っ込みもあるし、とか、色々。


で…その辺を考えた時に。

せめて新規プロジェクトは全て「モダン」で行きましょうよ!そのために、モダンを使えるようにしましょうよ!と思います。コピペエンジニアが書いたコードを後から保守は皆さんしたくないですよね?

例えばこれって、文脈的に「モダンなプログラミングではゼッタイにコピペをしない」と読み取れるのですが。
古参のエンジニアでも、真っ当な人はまずコピペをしません。やる時は「メリットとデメリットを天秤に載せた」上で、最低限、やります*2


…なんていう風に。
そも「モダン」の言葉の定義すら、極めて曖昧…というか限定的で、正直、内容が非常に「感情的かつ煽動的」な一方、論証も検証もエビデンスもないので、役に立てようって考えても、それが物凄く難しい内容なんですよね。


結局の所。
脳内で「モダン」と「レガシー」の構図を作っているのはいいのですが、その構図があまりにも見識の狭いものなので、結果的に「物凄い違和感」になっているわけです。
ただこれって「ラベリングした状態で議論する」と割と落ちやすいダークサイドだと思うので、定期的に、意識的に気をつけておいたほうがいい内容です。


その辺の「見識の狭さ」は、例えばここにも見て取れて。

はじめてのプログラミングで生PHPを使ってコードを書く、というのは学習用としては非常に良いと思います。しかしながら、そのままでPHPエンジニアを名乗ってはいけないような気がします。

ん…そうしたら「どうやってコードを書く」事を推奨している、んですかね?


一つの見方としては「PHP Extensionくらい使おうよ」となるのですが。そうすると、所謂「PHPをやっている人」で、実務で通用するレベルで「PHP Extension」書ける人ってどれくらい存在するんでしょうか? っていうか、ンな求人みたことないんですがねぇ? 影では結構あるんですかね?


別の見方では「フレームワークや様々なライブラリを使おうよ」となるのですが。ここについてはより辛辣で…これは一定レベル以上の人相手への発言なのですが「フレームワークやライブラリを使わなきゃコードを書けないようなら、レベルとしては真ん中より下だよねぇ」とかいう考え方もあるわけです。
所謂車輪の再発明周りに付いては、 http://d.hatena.ne.jp/gallu/20080129/p1 http://d.hatena.ne.jp/gallu/20090210/p1 あたりで一度考察をしていますが。
ん…そうだなぁ「ライブラリを使おう」に対する、おいちゃんがよくやる一発目の質問は「ソースコード全部読んで、理解して、問題点もメリットも把握した上で、使う事を決めましたか?」ってあたり。
ソースコードすら読まずに選んでも、それは「使ってる」んですかねぇ? 「使われてる」んですかねぇ? 「振り回されてる」んですかねぇ? って疑問が、山ほど。
ある程度以上のレベルになったら「そのライブラリが実装できる、程度のスキルレベル」を当然のように求めるし、必要なら勿論書いてもらうので、っていうことは「生PHPを使ってコードを書く」ってのは、むしろ大切だし重要なスキルになるです。


えぇ勿論、ご当人は「全てのライブラリを一度はちゃんと目を通し、それなりに突っ込みを心の中や身内で入れた上で、最終的に使う事をチョイスした」可能性がある、事も否定はしませんが。
その辺って「出来ていない」事が多いので、この辺を本当にやっている上で上述のようなことを言及するのであれば「大抵、ついでに言及するよねぇ」とか思う訳なのですが、言及されていないなぁ…ってあたりで「…読んでるのかなぁ?」という疑問が、沸き立つわけです。


で…そこら辺のグラデーションを考えずに

はじめてのプログラミングで生PHPを使ってコードを書く、というのは学習用としては非常に良いと思います。しかしながら、そのままでPHPエンジニアを名乗ってはいけないような気がします。

と言ってしまう、浅さ。
もうちょっと突っ込むと「"なぜ"ライブラリを使っていないのか」に対する考察がない、という点に起因する浅さ、は、割と気になります。


おいちゃん的には「上っ面のインタフェースと売り文句だけでライブラリやフレームワークに飛びつく」ほうが、よほど「そのままでPHPエンジニアを名乗ってはいけないような気がします」。
別に名乗って頂いてよいと思いますし、その辺の名乗りは全く考慮用の変数に入れないので、おいちゃん的には「どうでもいい」内容ではあるのですが。


もう一つ。
「モダン」については…特に若い人がこれに固執するのは、気持ちがわからないでもないです。

単純な話で。
若い人がキャリアを積んだ人間と格闘をしようとしても、本来的には「積んでいる経験と時間」で圧倒的に不利なので。
そうすると、「枯れた技術」の土俵では勝ち目が半端なく低くなるので、多少なり勝ち目が考えられる「モダン」の土俵のほうが、バトルがしやすいので。


或いは。
「モダン」な技術は、本来的には「枯れた技術、では補いきれなかった問題点の解法の一つ」として出てくる事が多いので。
そうすると、経験がある人間は「"解法"かもしれないが枯れていない、問題があるかもしれない技術」と「問題が明らかではあるが、それ以外については枯れている技術」とで天秤を図るのに対して、若い人は「解法がある」vs「明らかな問題がある」って見方をするので、そりゃまぁ、若い人は「モダン」に寄るだろうなぁ、っと。


若い人は、「若さ」でしか勝負がしにくい土壌に居る、ってのは、それはそれでわかる話なので。
ただ、最近割と若い子が「モダン萬世!」ってのをみていると、「それって結局「今俺が知ってるのがいい」ってしがみつきだとしたら、老害がやってることと変わらんよ?」って思ってしまう瞬間が、ちょこらちょこらあるので。

先述したような、停滞しているプログラマが少しでも前に進むといいなと思います。

なんて発言の前に。
「なぜ停滞しているのか?」「本当に停滞しているのか?」を考えてみたりするほうがいいんじゃないかなぁ、とか思って、おもむろに筆を進めてみました。


あぁ。
経験がある人間は、経験があるからこそ「己という器の中にある茶を全てすてて、空っぽの状態で」技術を評価する必要があるし。
新しい技術についても、人柱になったり人柱を提供したり人柱に祈ったりしながら*3、常に「無常観」をもって、己を更新していく必要がある、なんてのは言わずもがなな話ではありますので、念のため。

*1:「1プロセスのメモリの食いっぷり」で最小を目指す、とかいってるフレームワーク作ってる人間の発言じゃねぇわなw

*2:んと…「関数callにはコストがかかるよねぇ」ってのが理解できると、ここが少しだけわかります。…まぁ「マクロ」組む事がほとんどですが、その場合

*3:マテ