PHP開発者として8年以上のキャリアを持つ開発者が、Laravel製のオープンソースCRMをリリースしました。
99.6%という驚異的な型カバレッジを達成しています。
そのプロジェクトから得た貴重な教訓を紹介します。
過剰な抽象化の罠
カスタムフィールドシステムの開発で、その開発者は痛い失敗を経験しました。
最初は「美しい」設計を目指しました。
そして、各フィールドを独立したオブジェクトとして扱ったのです。
$customer->field('company_size')->validate()->render()
このコードは確かにエレガントです。
しかし、200以上のフィールドを扱うようになると、システムは悲鳴を上げ始めました。
問題の本質は何だったのでしょうか。
各フィールドアクセスで複数のオブジェクトを生成していました。
さらに検証ルールを実行し、データベースにもアクセスしていたのです。
ページロードごとに小さなフレームワークが動いているようなものでした。
解決策は驚くほどシンプルでした。
フィールドをただのデータとして扱う。
そして、必要な時だけ検証を行う。
型別のカラムに値を保存し、一度のクエリで全て取得する。
配列を使った「退屈な」実装に変更した結果、パフォーマンスは劇的に改善しました。
彼のコメントが印象的です。
8年かけてようやく理解しました。 抽象化にはコストがある。 すべての『賢い』解決策はオーバーヘッドを追加する。 時にはデータベースとPHPの現実を尊重した退屈なコードを書く必要があるんです
フレームワークの規約を守る価値
DDDやカスタムアーキテクチャの誘惑に抗うのは簡単ではありません。
しかし、彼はLaravelの規約に従うことを選びました。
なぜか？答えは実用的です。
新しい開発者がプロジェクトに参加しても、カスタムの抽象化を学ぶ必要がありません。
Laravelの知識があれば十分です。
すぐにコードベースを理解できます。
フレームワークのアップグレードも、独自の実装に悩まされることなく進められます。
コミュニティからDDDについて質問された際、彼はこう答えています。
プロジェクトが比較的シンプルで、FilamentとLaravelが重い作業のほとんどを処理してくれるなら、DDDは過剰です
Livewireの使いどころ
Livewireは素晴らしいツールです。
でも、万能ではありません。
彼のプロジェクトでは、管理画面でのみLivewireを使用しています。
一方、マーケティングページでは従来のLaravelルーティングを採用しました。
コメントでのやり取りが興味深いです。
あるユーザーがLivewireのパフォーマンス問題を指摘しました。
すると彼は「小さなコンポーネントには最適ですが、大規模な使用では確かに問題があります」と認めています。
Filament V4とLivewire V4では、レンダリングをフロントエンドに移す予定だそうです。
これによりボトルネックを解決できるといいます。
技術の進化を見守りながら、現時点での最適な使い方を選ぶ。
これも重要な教訓でしょう。
型安全性への投資
99.6%の型カバレッジは偶然の産物ではありません。
PHPStan level 7という高い基準を設定しています。
そして、PHP 8.3の機能を積極的に活用しています。
しかし興味深いことに、彼はPHP 8の新機能について「特別なことではない」と謙虚です。
実際、attributesの使用は限定的です。
constructor property promotionも「Laravelではよくあること」だと言います。
つまり、新しい機能を使うことが目的ではないのです。
コードの品質と保守性を高めることこそが真の目的です。
オープンソースとビジネスの両立
このプロジェクトの動機について、彼はこう語ります。
散発的なチュートリアルの代わりに、私が知っているすべてを示す実際のプロジェクトを構築しています。 最良のケースではサステナブルなビジネスになります。 最悪でも素晴らしいポートフォリオピースになり、多くを学べます
実際、カスタムフィールドプラグインは元々有料でした。
しかし、コミュニティのためにオープンソース化しました。
ビジネスと貢献のバランスを模索する姿勢が見えます。
批判への対応
投稿には批判的なコメントもありました。
- 「Symfonyを使ってほしかった」
- 「次世代というが特に新しい機能はない」
- 「テストが少ない」
彼の対応は建設的です。
フレームワークの選択について、彼はこう説明します。
Symfonyは最初に学んだフレームワークで多くを学びました。 でも今はLaravelが私のワークフローに合っています
「次世代」という表現についても現実的です。
まず基本をしっかり作ることに集中しました。 AIの機能は開発中です。 でも、まずコアのCRMがちゃんと動くことが大事だと思ったんです
まとめ
8年間のPHP開発から得られた最大の教訓は、シンプルさの価値かもしれません。
賢い抽象化より退屈な解決策。
カスタムアーキテクチャよりフレームワークの規約。
完璧を目指すより、まず動くものを作る。
彼の経験は重要なことを教えてくれます。
技術的な卓越性と実用性のバランスを取ることの大切さです。
コードの美しさに酔いしれるのではなく、現実の制約と向き合う。
そして、ユーザーに価値を届ける。
それが本当のプロフェッショナルの姿なのでしょう。
オープンソースプロジェクトとして公開されたこのCRMは、これらの教訓を体現した作品です。
完璧ではないかもしれません。
でも、実際に動きます。
価値を提供します。
そして学びを共有します。
