Pine Frameworkとは

Pine Framework

Pine Frameworkは、PHPを利用して作成された高品質で高性能なWEBアプリケーションフレームワークです。

Pine Frameworkは従来のWEBフレームワークのメリットを活かしつつ、不便な点について改善を図った、最先端のフレームワークです。

Pine Frameworkが作られた経緯

世界における多くのものが悪臭を放っている。この事実のうちに、知恵が潜んでいる。吐き気が翼を創り出し、泉を求める力を生む。

ニーチェ『ツァラトゥストラはかく語りき』

Pine Frameworkの歴史は2013年に始まります。

作者がシステム開発分野で独立していた当時に共同参画したWEB業務システム受託開発案件で、システム基本設計を行った会社のエンジニアの能力不足から、極めて低品質な製品をリリースする事になったのがそもそもの発端です。

元請けのプロジェクトマネージャはMVCフレームワークを想定して発注を行いましたが、基本設計を行った共同参画会社のエンジニアはOOPに関する知識が乏しく、場当たり的で柔軟性の低い基本設計を行ってしまいました。

この設計に引きずられて開発は難航し、燦々たる状況でのリリースとなってしまいました。

システム開発においては初期段階での失敗は取り返しようがなく、後からどんなに人員を導入してももはやどうにもならない状況になることが少なくありません。こうなると、1から作り直すより他に手立てはありません。

この時の失敗から、システム開発を高速且つ効率的に行うためには、堅牢でありながら柔軟性に富んだ高品質のフレームワークをあらかじめ整備しておくことがとても重要であると痛切に感じるようになりました。

PHPはフレームワークが乱立する言語として有名ですが、そのどれもが実用性には乏しく、小さなWEBアプリケーションを構築するのであれば確かに初動こそ工数を減らせますが、開発規模が大きくなってくるといずれ破綻してしまうのが目に見えている設計の物ばかりです。

これは、WEBフレームワークとしては恐らく最も有名な『Ruby on Rails』も同様で、PHPの多くのフレームワークはRailsの影響を強く受け過ぎたために同じ問題を抱える事となったRailsの劣化コピー群とも言えるでしょう。

Pine Frameworkは、こういった問題を解決し、長期の機能増強にも耐えうるように設計された、堅牢で極めて先進的なWEBフレームワークです。

なお、当然のことではありますが、このサイトはPine Frameworkを使って構築されています。

Pine Frameworkの系譜

Pine Frameworkは2013年から開発が始まり、2019年現在で7年ほどの歴史を持ちます。

開発の歴史の中で何度も見直しが図られ、全面的なリファクタリングが繰り返されてきました。

これが、その大まかな変遷の歴史です。

Pine Frameworkの系譜

Feijoa Prototype Framework(第1世代)

当初のプロダクト名は 『Feijoa』でした。

これは、植物である『Feijoa』に由来し、その花言葉は『豊穣』です。元々業務システムを高速開発するためのフレームワークとして設計されたため、企業が利益を上げ繁栄する事を願ってこの名前がつけられました。

Feijoa Prototype Frameworkは、MVC2フレームワークである『Feijoa Framework』と、管理画面の雛形である『Feijoa Prototype』を統合して1つのパッケージとなっていました。

Feijoa Prototype Frameworkでは、出来るだけ少ないコードで均一の品質が担保できるような配慮がなされました。

従来のいくつかのフレームワークでは『Model』は永続化層へのアクセス手段として位置づけられていたため、ビジネスロジックを記述する場所がControllerになってしまう事が頻繁にありました。

同様に、Viewは描画を行う場所として位置づけられており実体がtempleteであったため、描画に関するロジックも全てController領域へと追いやられ、結果としてControllerがどんどん肥大化して本来のControllerの目的から逸脱した実装が行われる事が少なくありません。

そこでFeijoa Prototype Frameworkでは、ControllerとModelの間に『Action』という概念を取り入れました。

Pine Frameworkのデザインパターン

Modelの実行に先立って行われるべきユーザーからの入力の妥当性検査や、Modelに渡すデータの整形など、そして、Modelで取得した結果について出力に先立って整形を行う処理などを『Action』が受け持ちます。この『Action』という概念はPHPの著名なフレームワークである『Symfony』を参考に導入されました。

この『Action』の採用により、Controllerにビジネスロジックが溢れるのを防いでいます。

また『Model』については永続化層へのアクセスという処理を分離し、あくまでもビジネスロジックを記述する場所という位置づけにしました。『Ruby on Rails』の影響を大きく受けてしまった『CakePHP』ではModel自体に永続化層に対する定義が記述され、『Model=永続化層にアクセスするための物』、という間違ったデザインがなされていました。

FeijoaではModelは永続化層には直接的に関与しません。

永続化層へのアクセスは専用のORマッパーである『DataMapper』を利用します。

DataMapperはシングルトンパターンでデザインされており、ユーザーからの1回のアクセスの間全てを通して1つのDBスキーマに対して1つの接続のみを流用します。つまり、低品質なアプリケーションで頻繁に行われるような、DBアクセスのたびに接続と切断を繰り返すといった負荷の高い処理をする事はなく、DBアクセスのコストを実装者が特別意識する必要無しに最適化する事が可能です。これは同時に、複数のDBスキーマに対してはそのスキーマの数だけ接続情報が適切且つ暗黙的に保持される事を意味します。

Controllerの肥大化防止はビジネスロジックだけにとどまりません。

従来のフレームワークではViewが実質的にTemplateとして扱われ、そこにロジックを書くのは避けるべきであると考えられてきました。

このため、描画に必要な分岐処理やループ処理等が行き場を失い、結果的にControllerに記述される事も少なくありませんでした。こうした矛盾は長期的に見た時にプロダクトの品質をどんどん損なっていき、最終的にはメンテナンスを不能にします。

Feijoa FrameworkではViewとTemplateを完全に分離し、Viewから任意のTempleteを呼び出して描画を行うように抽象化を行いました。

また、本来のMVC2デザインパターンではViewから永続化層のデータを取得する事を制限していないのですが、多くのフレームワークは設計の不備からこれが出来ない事が少なくありません。

Feijoa Frameworkでは、ViewからDataMapperを介して永続化層のデータを自由に参照し、これをデータソースとして描画処理を呼び出す事が可能です。

実際に描画を行うTemplateエンジンについては、2013年当時普及し始めていた『Twig』を採用し、これは現在の第5世代であるPine Frameworkでも受け継がれています。

『Twig』から提供される便利な変数展開やinclude機構、柔軟なfilterやfunction機能は、templateから分岐やループに関するロジックを分離するのに大きく貢献してくれます。

Controllerはアプリケーションの振る舞いをActionに移譲し、Actionはアプリケーションの本質についてのみModelに移譲する、Controllerは描画に関する処理をViewに移譲し、Viewは実際の描画処理のみをTemplateエンジンに移譲する、こうした高度に抽象化された仕組みが、それぞれのアーキテクチャが本来の仕事のみに専念する事を可能にし、朽ちることなく長く生存できる『資産』となるアプリケーションの構築に大きく寄与することとなるのです。

この考え方は第5世代となった現在のプロダクト『Pine Framework』でも脈々と引き継がれ、より高度に洗練されて現在に至っています。

Feijoa2(第2世代)

Feijoa Prototype Frameworkを制作し終わった段階で発覚した大きな問題は、プロダクト全体がFeijoa Prototypeに密接に結びつき過ぎている事でした。

管理画面が必要なアプリケーションを開発する事のみに特化していて、小さなWEBサイトを構築するには無駄が多過ぎるという問題が分かってきました。これは、小規模なWEBサイトを構築するのに適したCakePHPやCodeIgnighterといった著名なフレームワークに比べて利便性が劣る結果となってしまっていました。

このため、Feijoa2ではコードの全面見直しを行い、Prototypeを完全に廃止して純粋なフレームワークのみに特化したプロダクトの再構成を行っています。

Master Frame(第3世代)

この当時に特定派遣社員として勤務した人材紹介会社の既存システムの全面リプレイスに伴い、コード品質の向上を目指してFeijoa2からフォークしたプロダクトです。

システム開発会社ではなく一般企業であったため、既存システムのコードが劣悪で、通常業務としての改修がほぼ絶望的であったため、やむなくコードを持ち込む事になりました。

持ち込みにあたっては、セキュリティ上の問題からデジタルメディアの接続が出来なかったため、手作業でのコードの再入力の必要性が生じました。この工数の削減のために比較的コード量の多いORマッパー『DataMapper』からクエリビルディング機能を削除して、SQLクエリでの問い合わせのみ可能なシンプルな構成に機能限定を行いました。

Feijoa4(第4世代)

前述のMaster Frameの際にコードが流出してしまったため、著作権上の問題から全面的なリファクタリングを行ったプロダクトです。

基底クラス類について、大幅にコードを整頓・リファクタリングしました。

特に、ユーザーリクエストに対するヴァリデーションライブラリ『RDC(Request Data Controller)』について、ヴァリデーションの定義を設定ファイルに切り出す事で、より柔軟なアプリケーション構築を可能にしています。

また、永続化層へのアクセスの要であったORマッパー『Data Mapper』は名称を『Wizzy』に改め、コードのより一層の抽象化と高機能化を図りました。

Pine Framework(第4.5世代)

この時に就職していたソフトハウスの既存WEBサービスについて、全面改修を前提としてフォークされたプロダクトです。

印刷会社の子会社として設立されたソフトハウスでしたが、システム開発技術・知識は乏しく、設立当初の思想は完全に形骸化してしまっている会社でした。

ほとんど素人が作成した既存WEBサービスのコードが400万行ほどの負債となっており、これを改善するためにやむなくコードを持ち込みました。

持ち込みにあたってプロダクト名を変更、会社の頭文字『松』をもじって『Pine Framework』としました。これに伴い、ORマッパーは『竹』を意味する『Bamboo』、ユーザーからの入力の要となるヴァリデーターは『梅』を意味する『User-request Manipulate Engine(UME)』と改めました。『松竹梅』というジョークです。

コード品質の維持を目的として、CLIによる自動コード生成機能『pine』コマンド、CLIによる自動DBマイグレーション機能『bamboo』コマンドなどを整備しました。

しかし、会社側のシステム開発に対する根本的な理解の欠如は致命的で、全体的な従業員の能力不足、職場環境の騒音、不平等な待遇等、入社当初の話し合った業務内容から大きく逸脱して環境が悪化したため、最終的にはこの会社を去る事になってこのプロダクトは私の手を離れました。

Pine Framework(第5世代)

現在のプロダクトです。

名称は、『Feijoa』から『Pine Framework』となりました。4.5世代の時の名前が個人的にかなり気に入ってしまい、元々私が考えたただのプロダクトネームで商品展開しているわけでも、商標等を取得しているわけでもなかったため、名称についてだけ引き継ぎました。『Bamboo』と『UME』という名称も同様です。

ただし、著作権上の問題からソースコードについては全面的な書き直しを行いました。4.5世代までは既存システムの古い環境に縛られてPHP 5系を想定したコードでしたが、第5世代からはPHP 7系の機能を制限なく利用しています。

これに伴い、当初のFeijoa Prototype Framework時にあった管理画面雛形について、マルチサイト管理機能サイトテンプレート機能を導入することで、再び実現されるようになりました。

4.5世代で導入された『pine』コマンド、『bamboo』コマンドなどの概念もコードを全面的にリファクタリングして採用し、より一層便利で先進的なフレームワークとして成長しています。