独自のPHP フレームワークを作成するという冒険 (1)
オレオレフレームワークという、アンチパターンがあります。
Image generated by OpenAI's DALL·E
(ChatGPI画伯のコメント: こちらが「オレオレフレームワーク」を表現したイラストです。プログラマーが自信満々でユニークなフレームワークを指し示し、カオスながらも機能している様子をユーモラスに描いています。楽しんでいただければ幸いです！)
ひどいコード、おまけにオレオレフレームワーク、というのが恐怖のストーリーとしてセットになっていることが多いようです。
厨二病的熱狂に冒されて、自分でフレームワークを書きたくなった方への最善のアドバイスは、今でも「よく考えたほうがよい」です。
なぜ、アンチパターンと知りつつ自力でフレームワークを作る決断をしたのか、そして、なにをよく考えたほうがよいのかをこれから書いていきたいと思います。
FuelPHPがメンテされてない問題
開発コミュニティがちょっと停滞してるなぁと感じてましたが、2019年の6月の1.8.2のリリースを最後に、FuelPHPの更新がされなくなりました。GITHUBの更新も5年間ぐらいされてないようです。
FuelPHPは日本語の書籍もたくさん出ているし、使っている人も結構多いし、比較的軽量で性能も良さそうだし、ということでチョイスしてましたのでこの事態は結構想定外です。
PHPの方は、堅実にバージョンアップを重ねていって、7からPHP8になりました。PHP8で動かすパッチとかがコミュニティ開発で続けられるのかなと期待していましたが、そういうまとまった動きもないようです。
FuelPHPのコードはレガシーのものも混じっているし、結構難読化してるし、なかなか手を入れることが難しいのかもしれないです。
その時の私の選択肢は次の二つです。
- FuelPHPの8.1パッチを自分で開発する
- FuelPHPと互換性の高いPHPフレームワークを自分で開発する。
フレームワークを乗り換えるという選択肢もありますが、既存のプログラム資産が維持できないという大きめのコストが伴います。私のアプリは業務アプリで、その時点でユーザーが数百人いましたし、CakeとかLaravelへの移行ははかなり再開発工数がかかるので、結局選択肢から外しました。
とりあえず、1.についてはエラーが出たところを直す、みたいなやり方でパッチを開発して、動くことは動くようになりました。おそらくFuelPHPのユーザーはそうしているのではないかなと思います。とりあえず、延命させる選択肢は確保したと考えました。
2.の選択肢ですが、着手する前に、プロジェクトの成功確率を上げるための取り組みをしました。
FuelPHPの実装の調査
セッション管理
DBの実装
PHPの細かい仕様を調査
オートローダー
ヘッダーの出力
HTTP変数の取得方法
仕様の検討
実装方針の検討
慎重に十分に準備をしながら進めたら、一応動くものが作れそうかな、と思い始めました。
FulePHPに関しては、一部のコードが難読化していて手がつけられないこと、DBのトランザクション周りの実装が、たとえばシングルトンなどを使うなど適正にされてなくて、多くの場合には別のセッションが立てられているから、ロールバックがされないことがわかってきました。なんとなくそうかなと思っていましたが。
どういう設計思想や哲学で作るのか
メタ開発というか、自分がどういう発想で開発しているのかを意識することは、大事だと思います。キーワード的には次のような考え方で日々仕事をしてます。
これを意識しないと開発が進展しても、いろいろ定まらず後半に苦労することになります。
動けば官軍
最終的に動いて役に立てば良いのです。十分に人の役に役に立てれば飯は食えます。「正しい理屈」では飯が食えません。世の中の流行りや定石と違っていても、ちゃくと動くことが第一です。
評論やマウントを取りたい人には、好きにさせておけばよいのです。自分の顧客の付加価値を作ることが、職業プログラマの最大の正義であり錦の御旗です。
データベース中心
SQLで書かれた真な命題の集合によって、ビジネスロジックを記述することが背骨。データベースが主役のアプローチを第一にする。同じ理由から、ORマッパーのようなSQLをラップする機能は、使わないし今後も使う予定はありません。
グルーコード
主役がDBだとするとPHPとフロントエンドのJavsScriptは脇役で、それぞれ多少は重複しつつも、糊付けの役割に徹することになります。
ボイラープレートコードなし
ロジックを書くときにはそれに集中したいです。難しい場合もありますが、できたらファイルの上のほうにuseとかnamespaceを書きたくないのです。
間違ってたら動かないし、人手で書く意味がそんなにないのに、その度に微妙な工数がとられることは、私のような零細ソフト開発者には死活問題です。
名前空間を複数持たせることで得られるメリットは、名前空間が衝突しない以外には多分ないはずです。
組み込まれた開発ツール
気の利いた設計は大体、自己診断する機能がついてます。開発ツールそのものがコアの部分に組み込まれていることで、問題を早期に見つけることが可能になります。
ベストな部品は部品がないこと
なるべく少ない構成要素で製品を作ります。部品がなければそれがベストです。
ライブラリの使用は避ける
ライブラリを使うことは、自分のソフト資産の一部が自分が直接コントロールできないものに依存することです。ライブラリ周りのトラブルはコントロールしにくく、リスクを含むことになるので避ける選択肢が第一です。
Discussion