Composerを理解するとPHPが嫌いじゃなくなる - Web開発における知見共有系ページ

結論から言うと、PHPが苦手に感じられる理由の多くは文法ではありません。
依存関係の扱い方を知らない状態で触っていることが原因になりがちです。

同じPHPでも、Composerを前提に触る場合と、そうでない場合では印象が大きく変わります。
そして多くの場合、「扱いづらい」と感じた体験は、言語そのものではなく運用方法の問題です。

PHPを触り始めると、次のような流れになりやすいです。

require 'lib/library.php';

ファイルが1つ増えただけで挙動が変わります。
この体験が「雑然としている」という印象につながります。

しかし、これは現在の標準的なPHPの使い方ではありません。

Composerを使うと、入口が1つになります。

require __DIR__.'/vendor/autoload.php';

これだけです。
クラスの場所を手動で管理する必要がなくなります。

そして重要なのは、これは便利機能ではなく設計です。
PSR-4規約に従って、クラスとディレクトリが対応します。

結果として次が変わります。

コードの見通しが良くなります。

Composer以前のPHPでは、ライブラリ導入は手作業でした。

これでは管理対象が増え続けます。

Composerではこうです。

composer require monolog/monolog

この1行で、依存関係を含めて導入されます。
さらにcomposer.lockによって状態が固定されます。

つまり、ライブラリは追加するものではなく、
前提として宣言するものになります。

PHPが苦手と言われる理由の1つは「何でもできる」点です。
自由度が高く、構造を決めてくれません。

Composerはこの部分を補います。

結果として、挙動が予測可能になります。
予測可能になると、言語の印象は安定します。

Composerを「パッケージインストーラ」とだけ理解すると、
効果が見えにくいです。

実際には、

を提供しています。

つまり開発の土台です。

Composerを導入しても、
次の状態では体験は改善しません。

これは旧来の使い方と混在しています。
効果が半減します。

Composerは「使う」より「合わせる」必要があります。

PHPは1つのスタイルに固定されていません。
そのため、初期体験が大きく印象を左右します。

同じ言語でも別物に近い体験になります。

Composerを理解すると、
PHPは自由なだけでなく、制御可能な言語に見えてきます。

言語の好き嫌いは文法だけで決まりません。
開発中の安心感が大きく影響します。

Composerは派手な機能ではありませんが、
PHPの開発体験を整える基盤になっていると感じます。