今、WordPressのプラグイン開発をしている。
理由は、妻の会社でメンバーサイトを構築するため。
世の中にメンバーサイト構築用のプラグインは結構いっぱいある。
ただ、かなり調べたのだけど全て海外製だし、しっくりくるものがなかった。
WordPressでメンバーサイト作ってる人って、
英語必須だと思うんだけど、どうなのかねぇ。
ともあれ、
だったら日本特有の事情を加味しつつ、
もっとわかりやすい管理機構を持つメンバーサイト構築プラグインを作ることにした。
前からWordPressを使ってホームページのデザインはしているので、多少はWordPress本体の構造は知っていた。
なんかヘンな作りだとは思っていた。
しかし、プラグイン開発を開始してみると、
予想以上に拡張しずらいアーキテクチャだということを思い知った。
え、何これ。グローバル変数だらけじゃん・・・
いかにもPHPコミュニティらしいといえばそれまでか。
WordPressの最大のウリは、世に出ているプラグインやテーマの数が圧倒的に多いことだと思う。
でも、内部の作りはスマートとは言い難い。
本体のコードを眺めていると、グローバルな変数やファンクションの塊がわんさかと出てくる。
普通にグローバルな変数を使うことも珍しいことではない。
一体いつの時代だよ・・・。
たぶん初期のコードはすべて構造化プログラミングで作られていたのだろう。
現在はクラスもそれなりにあるようだが、コアな部分はやはりグローバルなファンクションで定義されている。
恐ろしく時代遅れな設計方針だ。
今でもこれを貫いているのは、
今さらこれらをカプセル化すると、動かなくなるプラグインが大量に出てしまうからだろう。
会社に例えるなら、
ずっとエクセルでやってきて他のシステムもエクセル依存だから、今さら変えられない。
といったところか。
よくこれだけの数のプラグインが世に出たものだと思う。
むしろ、古臭い設計だから初心者が手を出しやすかったということかも知れない。
まぁ、それでもWordPressはビジネス的に成功しているし、それでいいのだ。
ここ数年で一番学んだのはそこだ。
エンジニアはその職業柄から細部にこだわる。そこは美点でもある。
でもビジネスとして成功することのほうが重要だ。
ビジネスとしてやる以上は、ここは絶対だ。
とはいえ、
最終的にはそこそこのコード量になると思うのでそれなりの設計にしたいのだが、
いかんせん本体の作りがこれなので、四苦八苦している。
はやく画面とか、見える部分を作り込みたいなぁ。