なぜsymfonyのPolyfillが必要なのか(...そしてなぜ必要ではないのか)

セバスチャン・ルザック

PHP ユニットリーダー

次の記事では、symfony の Polyfill がどのように動作し、symfony のプロジェクトにどのように関係するのかを説明します。また、このライブラリが解決しようとするアイデアについても深く掘り下げます。

ほとんどの現代では PHP プロジェクトに大きく依存していることに気づくだろう。 symfony ポリフィルライブラリにあります。この記事では、ライブラリーの仕組みや、ライブラリとの関連性を説明するだけでなく、ライブラリーがどのように機能するのか、また、ライブラリーがどのように機能するのかについても説明する。 symfonyプロジェクトしかし、その解決しようとする問題の考え方にも深く踏み込んでいく。

ちょっとした歴史

PHP はかなり長い間、悪い状態にあった。2005年にアンドレイ・ズミエフスキがプロジェクトをネイティブでサポートする。 PHP 様々な評価と多くの懸念のため PHP は間違った方向に進んでいる開発 PHP 6.xは始まった。しかし、完成することはなかった-それはまた別の日の話だ。それから10年後、2014年から2015年にかけて、ドミトリー・ストゴフ、シンチェン・ホイ、ニキータ・ポポフの3人が6.xをスタートさせた。 phpng - プロジェクトで使用されている Zend Engine を最適化し、リファクタリングしました。 PHP.

>_ PHP 7誕生

そして過去数年間、 PHP 現在安定版8.1である。

イメージ

言語の新機能が急速に開発されたため、開発者だけでなく、インフラやホスティングサービスもその変化に対応しなければならなかった。

私たち開発者が、私たちの愛するプログラミング言語の最新かつ最高の機能を使えるようにするために symfony ポリフィル プロジェクトが誕生した。

symfony のポリフィルとその機能

このプロジェクトは、最新の PHPバージョン また、いくつかの拡張機能や関数の互換性レイヤーを提供する。これは、以下のような場合に使用されることを意図している。 PHPバージョン とエクステンションが望まれる。

これは純粋な描写である。 symfony ポリフィルしかし、それは何を意味するのか？

急速に進化する PHP言語 そして、ISPの段階的でないソフトウェアのカスタマイズにより、ほとんどの開発者は単純な選択を迫られている：

開発者として、私は古いバージョンの PHP で、その言語の最新機能を使うことができない。
開発者として、私は最新のアプリケーションを作成する。 PHP.

しかし、すでに両社で使用されている他のツールやサービスとの互換性を維持する必要があった。コードの古いバージョンを使用している。 PHP読者の皆さん、この2つのソリューションのいわゆる「面白さ」について言及する必要があるだろうか？

2015年、オープンソースコミュニティは、開発者の道を容易にするために、次のようなものを作成した。 Polyfillの最初の安定バージョンは1.0です。.開発者の生活は楽になり、symfony のポリフィルは異なるプラットフォーム間のコードの移植性のような多くの問題を解決したと言えます、 PHPバージョン その結果、アプリケーションのリファクタリングと技術的負債の削減が非常に容易になった。

残念ながら、すべての問題がひとつのツールで解決できるわけではない。

複数バージョンの環境維持に伴う問題

複雑な場合 ITプロジェクト顧客/支店/部署ごとに異なるバージョンの環境を維持することは、一般的な手順である。その結果、多くの異なるブランチのアプリケーションを同時に開発する必要が生じ、多くの場合、異なる機能要件と独自のトラクションを持つことになります。私は、異なるPHP5 / PHP7環境で異なる顧客向けに同じアプリケーションを保守するという問題に何度も直面しました。 symfony ポリフィル.

開発チームのメンバー間のスキル格差

に組み込まれている機能が急速に増えているためだ。 PHPしかし、多くの開発者は変化のスピードについていけていない。上位バージョンの PHP などの新機能は外部ライブラリで簡単に実現できる。 PHPファイバー.を選択するチームメンバーであれば、スキルのマッチングを確認したり、静的解析ツールやバージョン回帰エラーの早期発見によってコード提供プロセスの一貫性を高めたりするのは良い考えだ。

変化を嫌う

イメージ

新しい言語機能の採用はまだかなり低い。 PHP 5のシェアが24%を上回っていることは明らかだ。 PHPプロジェクトの4分の1が7.x未満のバージョンを使用している。のセキュリティ・サポートが2022年12月6日に終了する。つまり、この記事を書いている時点で、25%を超えるPHPベースのウェブ・プロジェクトが、年末までにすべての新しいセキュリティ脆弱性に対して潜在的に脆弱になるということだ。「もしうまくいくなら、なぜ悩む必要があるのか？

結論

言語の変化にはできるだけ早く対応し、最新のソリューションをできるだけ早く使うべきだ。レガシー・プロジェクトを移行する可能性がある場合、以下を含める価値がある。 symfony ポリフィル をヘルパーとして使い、ストラングラー・パターンや現在流行のBDD手法のようなテクニックを使う。 symfonyフレームワーク.ということは、私たちは本当に symfony ポリフィル?