MENU
  1. ホーム
  2. PHP
  3. PHPでComposerを使用したPSR-4オートロード設定方法を徹底解説

PHPでComposerを使用したPSR-4オートロード設定方法を徹底解説

PHP

PHPプロジェクトを効率的に管理するためには、クラスの自動読み込み（オートロード）は欠かせません。オートロードを利用することで、必要なクラスファイルを手動で読み込む手間が省け、コードがシンプルかつ保守しやすくなります。PHPのコミュニティでは、PSR-4という標準的なオートロード規約が広く採用されており、これに従うことでコードの構造が一貫性を持ち、再利用性が高まります。

本記事では、Composerを用いてPHPプロジェクトでPSR-4規約に基づいたクラスローディングを設定する方法を、手順を追って詳しく解説します。オートロード設定を行うことで、効率的な開発環境を整え、プロジェクトの成長に対応できるスケーラブルなコード設計を実現しましょう。

目次

ComposerとPSR-4の概要

ComposerはPHPの依存関係管理ツールで、パッケージの導入やバージョン管理を容易にするために使われます。Composerのオートロード機能を利用すると、プロジェクト内のクラスファイルを自動的に読み込むことができ、クラスの手動インクルードを避けることが可能です。

PSR-4とは

PSR-4は、PHP-FIG（PHP Framework Interop Group）によって策定されたオートロードの標準規約です。この規約に従うことで、クラス名とファイルパスを対応させ、クラスローディングを自動化することができます。PSR-4では、名前空間をディレクトリ構造と一致させることで、クラスファイルの場所を特定します。

ComposerとPSR-4の連携

ComposerはPSR-4に対応しており、composer.jsonファイルに設定を追加することで、プロジェクトのクラスローディングをPSR-4規約に従って行うことが可能です。この設定により、名前空間に基づいてクラスファイルを自動的にロードできるようになります。

Composerのインストール方法

Composerを使用するには、まずシステムにComposerをインストールする必要があります。ここでは、Composerのインストール手順を解説します。

ステップ1: Composerインストーラのダウンロード

公式サイト（https://getcomposer.org）からComposerのインストーラをダウンロードします。ターミナルやコマンドプロンプトを開き、以下のコマンドを実行してインストーラをダウンロードします。

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

ステップ2: インストーラの実行と検証

次に、ダウンロードしたインストーラを実行してComposerをインストールします。以下のコマンドを実行してください。

php composer-setup.php

その後、インストールが正しく行われたかを確認するために、次のコマンドでインストーラを削除します。

php -r "unlink('composer-setup.php');"

ステップ3: システムパスに追加する

Composerをグローバルに使用するために、システムパスに追加します。以下のコマンドで、Composerを適切なディレクトリに移動します。

mv composer.phar /usr/local/bin/composer

Windowsの場合は、インストーラを使ってインストールすることでシステムパスが自動的に設定されます。

ステップ4: Composerのバージョン確認

インストールが完了したら、以下のコマンドでComposerが正しくインストールされているかを確認します。

composer --version

これで、Composerのインストールが完了し、PHPプロジェクトで利用できるようになります。

プロジェクトにComposerを導入する

Composerをインストールしたら、次にプロジェクト内で使用できるように設定を行います。ここでは、Composerを用いてPHPプロジェクトに依存パッケージを追加する方法を解説します。

ステップ1: `composer.json`ファイルの作成

まず、プロジェクトのルートディレクトリに移動し、以下のコマンドでcomposer.jsonファイルを作成します。このファイルは、プロジェクトの依存関係や設定を管理するために使用されます。

composer init

コマンドを実行すると、プロジェクト名や説明、パッケージのバージョンなどの設定を対話形式で入力する画面が表示されます。これに従って設定を進め、composer.jsonファイルを生成します。

ステップ2: パッケージのインストール

依存パッケージをプロジェクトに追加するには、以下のコマンドを使用します。例えば、PHPユニットテストフレームワークであるPHPUnitを追加する場合は、次のようにコマンドを実行します。

composer require phpunit/phpunit

このコマンドを実行すると、composer.jsonに依存パッケージが追加され、vendorディレクトリ内にパッケージがインストールされます。

ステップ3: オートロード設定の確認

パッケージをインストールすると、Composerは自動的にオートロード設定を更新し、vendor/autoload.phpファイルが生成されます。このファイルをrequireすることで、インストールされたパッケージのクラスを自動的に読み込むことが可能です。

require 'vendor/autoload.php';

これにより、Composerを使用した依存関係の管理が可能になり、プロジェクトの効率的な開発環境が整います。

PSR-4オートロードの設定

PSR-4に基づくオートロードを設定することで、プロジェクトのクラスファイルを自動的に読み込めるようになります。このセクションでは、composer.jsonファイルにPSR-4準拠のオートロード設定を追加する方法を解説します。

ステップ1: `composer.json`ファイルの編集

プロジェクトのルートにあるcomposer.jsonファイルを開き、autoloadセクションを追加します。以下は、PSR-4規約に従った基本的な設定例です。

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

この設定では、Appという名前空間がsrcディレクトリにマッピングされます。つまり、App\\で始まるクラスはsrcディレクトリ内で探されます。

ステップ2: ディレクトリ構造の整備

composer.jsonで設定した名前空間に対応するディレクトリ構造を整えます。例えば、App\\名前空間を使う場合は、プロジェクトのルートディレクトリにsrcフォルダを作成し、その中にクラスファイルを配置します。

project-root/
│
├── src/
│   ├── ExampleClass.php
├── composer.json
└── vendor/

この構造に従うと、src/ExampleClass.phpファイルに定義されたApp\ExampleClassクラスを自動的にオートロードできます。

ステップ3: Composerオートロードの再生成

composer.jsonを編集した後は、以下のコマンドを実行してオートロード設定を再生成する必要があります。

composer dump-autoload

このコマンドを実行することで、Composerがオートロードファイルを更新し、PSR-4規約に基づいたクラスローディングが有効になります。

ステップ4: クラスの使用方法

オートロード設定が完了したら、vendor/autoload.phpをプロジェクトにインクルードすることで、設定された名前空間のクラスを使用できます。

require 'vendor/autoload.php';

use App\ExampleClass;

$example = new ExampleClass();

これで、PSR-4オートロードによるクラスローディングが正しく動作するようになります。

フォルダ構成と名前空間の設計

PSR-4に対応したオートロードを適切に活用するためには、プロジェクトのフォルダ構成と名前空間の設計が重要です。ここでは、PSR-4規約に従ったプロジェクト構造の設計方法を解説します。

PSR-4におけるフォルダ構成の基本

PSR-4では、名前空間とディレクトリの対応関係を明確にすることが求められます。名前空間のルートとディレクトリのパスが一致するように設定することで、クラスファイルを自動的に見つけて読み込むことが可能です。

例えば、以下のようなcomposer.json設定を行った場合：

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}

Appという名前空間のクラスはすべてsrc/ディレクトリ内に配置する必要があります。

フォルダの階層設計

プロジェクトの規模やアーキテクチャに応じて、ディレクトリの階層構造を設計します。一般的なフォルダ構成の例を以下に示します。

project-root/
│
├── src/
│   ├── Controllers/
│   │   └── UserController.php
│   ├── Models/
│   │   └── User.php
│   ├── Services/
│       └── UserService.php
├── tests/
│   └── UserTest.php
├── composer.json
└── vendor/

この例では、App\Controllers、App\Models、およびApp\Servicesなどの名前空間に対応するクラスがそれぞれのディレクトリに配置されています。

名前空間の設計方針

名前空間はプロジェクトの論理的な区分を反映するように設計するのが理想です。以下の点を考慮して設計すると、コードの可読性が高まります。

  1. 機能ごとに分類する：クラスが持つ役割に応じて、Controllers、Models、Servicesなどの名前空間で整理します。
  2. 階層的に分ける：サブディレクトリを活用し、プロジェクトの規模が大きくなっても管理しやすいように設計します。
  3. プロジェクトのアーキテクチャに沿う：MVCアーキテクチャの場合、ControllersやViews、Modelsなどの命名を使います。

例: 名前空間とクラスの定義

App\Models名前空間にUserクラスを配置する場合、クラスファイルはsrc/Models/User.phpに配置され、クラスの定義は次のようになります。

<?php

namespace App\Models;

class User
{
    public function __construct()
    {
        echo "User class loaded!";
    }
}

このようにすることで、PSR-4に従ったクラスローディングが自動的に行われ、コードのメンテナンス性が向上します。

実際にクラスをオートロードする

設定が完了したPSR-4オートロードを使用して、プロジェクト内でクラスを実際に読み込む手順を解説します。このセクションでは、Composerのオートロードを活用してクラスをロードし、プロジェクトで使用する方法を紹介します。

ステップ1: `vendor/autoload.php`を読み込む

Composerでオートロードを設定すると、vendorディレクトリ内にautoload.phpが自動生成されます。このファイルをプロジェクトで読み込むことで、オートロード機能が有効になります。以下のように、スクリプトの最初でautoload.phpをrequireします。

require 'vendor/autoload.php';

これにより、composer.jsonで設定されたPSR-4に基づくクラスローディングが自動的に機能します。

ステップ2: 名前空間に基づいたクラスの使用

次に、設定した名前空間を使用してクラスを呼び出します。例えば、App\Models名前空間に配置されたUserクラスを使う場合、次のように名前空間を指定してクラスをインポートします。

use App\Models\User;

$user = new User();

このコードにより、src/Models/User.phpに定義されたUserクラスが自動的に読み込まれ、インスタンス化されます。手動でクラスファイルをインクルードする必要がなくなり、コードの管理が簡単になります。

ステップ3: サンプルプロジェクトの動作確認

オートロードが正しく動作しているか確認するために、簡単なPHPスクリプトを作成して実行します。以下のように、index.phpファイルをプロジェクトのルートディレクトリに作成します。

<?php
require 'vendor/autoload.php';

use App\Models\User;

$user = new User();

このスクリプトをブラウザやコマンドラインから実行し、設定したUserクラスが正しくロードされていることを確認してください。Userクラスのコンストラクタでメッセージを表示するように設定しておけば、画面に表示されるメッセージでクラスローディングの成功を確認できます。

クラスの追加とオートロードの自動反映

新たなクラスを追加した場合でも、composer dump-autoloadコマンドを実行することでオートロード設定が再生成され、変更が反映されます。このコマンドは、追加や削除されたクラスをComposerに再認識させるために必要です。

composer dump-autoload

これで、新しく追加されたクラスもオートロードの対象になり、プロジェクト内で簡単に利用できるようになります。

オートロード設定の検証とトラブルシューティング

PSR-4オートロードの設定が正しく機能しているかを確認し、よくある問題とその解決方法について説明します。Composerオートロードのトラブルシューティングに役立つヒントも紹介します。

オートロード設定の検証

オートロードが正しく動作しているかを確認するためには、以下の手順を実行します。

  1. クラスの呼び出しをテストする
    クラスが正しくオートロードされるか、簡単なスクリプトを作成してテストします。以下は、クラスのインスタンス化によってオートロードを確認する例です。
   <?php
   require 'vendor/autoload.php';

   use App\Models\User;

   $user = new User();

クラスのインスタンス化に成功すれば、オートロードが正しく設定されていると判断できます。

  1. composer dump-autoloadを実行する
    composer.jsonに変更を加えた場合や、新たにクラスを追加した場合には、オートロードの設定を再生成する必要があります。
   composer dump-autoload

これにより、Composerが最新のクラス情報を認識し、オートロード設定が更新されます。

よくある問題と解決策

オートロードが正しく動作しない場合、以下のような原因が考えられます。それぞれの問題と対処法を確認しましょう。

1. クラスが見つからないエラー

Class 'App\Models\User' not foundというエラーメッセージが表示される場合、以下の点を確認します。

  • 名前空間の設定が正しいか
    composer.jsonで指定した名前空間とディレクトリの対応関係が正しいか確認してください。
  • クラスファイルの場所が正しいか
    名前空間に対応するディレクトリに、クラスファイルが存在しているか確認します。

2. `composer.json`の構文エラー

composer.jsonファイルに構文エラーがあると、Composerが正常に動作しません。ファイルを編集した際にJSON構文が正しいかをチェックしましょう。

  • オンラインJSONバリデーターを使用して、composer.jsonファイルの構文を検証するのも有効です。

3. オートロード設定が反映されない

新しくクラスを追加したのにオートロードが反映されない場合、composer dump-autoloadを実行することで解決することが多いです。このコマンドは、オートロード設定を再生成します。

デバッグのための追加ツール

トラブルシューティングの際に役立つ追加ツールやコマンドも活用できます。

  • composer diagnose
    このコマンドを実行すると、Composerの設定に問題がないか診断できます。
  composer diagnose
  • composer updateやcomposer install
    パッケージの再インストールや更新によって、問題が解決する場合があります。特に依存関係が原因でエラーが発生している場合は試してみてください。
  composer install

ロギングによる問題解決

オートロードがうまくいかない場合、エラーメッセージを確認し、問題の原因を特定することが重要です。PHPのエラーログを有効にすることで、より詳しい情報を得られます。

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

この設定をスクリプトの冒頭に追加すると、エラーメッセージが画面に表示され、問題の特定が容易になります。

これらの手順を通じて、Composerのオートロード設定を正しく検証し、問題が発生した際に迅速に対処できるようになります。

Composerオートロードの応用例

Composerのオートロード機能を活用すれば、プロジェクトの規模に応じた柔軟なクラスローディングが可能です。このセクションでは、複数の名前空間やディレクトリを設定する方法や、オートロード機能の応用例を紹介します。

応用例1: 複数の名前空間を設定する

大規模なプロジェクトや複数のモジュールを持つプロジェクトでは、複数の名前空間を設定することが有効です。composer.jsonに複数の名前空間を追加することで、異なるディレクトリにあるクラスを管理できます。

以下の例は、AppとLibraryという2つの名前空間を設定する方法です。

{
    "autoload": {
        "psr-4": {
            "App\\": "src/",
            "Library\\": "lib/"
        }
    }
}

この設定により、App名前空間のクラスはsrcディレクトリで、Library名前空間のクラスはlibディレクトリで探されます。複数の名前空間を使うことで、異なるモジュールやサードパーティのコードを効果的に分離することが可能です。

応用例2: サブ名前空間を使った階層的な構造

名前空間をサブディレクトリにマッピングすることで、階層的な構造を持たせることができます。例えば、App\ControllersとApp\Modelsという名前空間を設定し、それぞれsrc/Controllersとsrc/Modelsディレクトリに対応させることができます。

{
    "autoload": {
        "psr-4": {
            "App\\Controllers\\": "src/Controllers/",
            "App\\Models\\": "src/Models/"
        }
    }
}

このように設定すると、各クラスを整理する際に論理的なグループに分けることができ、コードベースの管理が容易になります。

応用例3: サードパーティライブラリのカスタムオートロード

サードパーティライブラリをプロジェクトに導入する場合でも、PSR-4規約に基づいて独自のオートロード設定を追加できます。例えば、外部ライブラリをlib/vendorディレクトリにインストールし、その名前空間をVendorとする設定を行うことが可能です。

{
    "autoload": {
        "psr-4": {
            "Vendor\\": "lib/vendor/"
        }
    }
}

これにより、プロジェクト内でVendor名前空間のクラスを簡単に利用できるようになります。

応用例4: クラスマップを使用したオートロード

PSR-4に加えて、特定のクラスファイルを直接マッピングするクラスマップを利用することもできます。クラスマップでは、特定のクラスを指定のファイルパスに直接対応させることで、柔軟なクラスローディングが可能です。

{
    "autoload": {
        "classmap": [
            "src/CustomClass.php",
            "lib/LegacyClass.php"
        ]
    }
}

この設定は、特定のクラスファイルがPSR-4規約に従っていない場合や、レガシーコードとの互換性を保つ必要がある場合に役立ちます。

応用例5: 開発環境専用のオートロード設定

開発環境用のツールやテストクラスをオートロードに含めるために、autoload-devセクションを使用することができます。これは本番環境には影響しない設定です。

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    }
}

この設定により、開発中にテスト用クラスを自動的にロードしつつ、本番環境では不要なファイルをロードしないようにできます。

オートロード設定の再生成

composer.jsonに変更を加えたら、オートロード設定を再生成するために以下のコマンドを実行してください。

composer dump-autoload

これで、Composerオートロードの応用的な設定が反映され、柔軟で効率的なクラスローディングが実現します。プロジェクトのニーズに応じて設定を調整し、最適な環境を構築しましょう。

PSR-4以外のオートロード方式との比較

Composerのオートロードには、PSR-4の他にもいくつかの方式が存在します。このセクションでは、PSR-4と他のオートロード方式（PSR-0やクラスマップなど）の違いを説明し、それぞれの利点と欠点を比較します。

PSR-4とPSR-0の違い

PSR-0はPSR-4が登場する前の標準的なオートロード規約であり、クラス名とディレクトリ構造の対応に厳密なルールがありました。主な違いは以下の通りです：

  1. ディレクトリ構造の厳密さ
  • PSR-0では、名前空間の各要素がディレクトリに対応し、クラス名のアンダースコア（_）もディレクトリとして扱われます。例えば、Namespace_SubNamespace_ClassNameというクラスはNamespace/SubNamespace/ClassName.phpというパスである必要がありました。
  • PSR-4では、名前空間のルートを任意のディレクトリにマッピングでき、ディレクトリ構造が柔軟になります。PSR-0に比べて設定がシンプルで管理が容易です。
  1. 柔軟性
  • PSR-4は、名前空間の一部をディレクトリのルートにマッピングできるため、ディレクトリ構造をシンプルに保つことができます。プロジェクトの規模が大きくなるにつれて、PSR-4の柔軟性は特に有利になります。
  • PSR-0はディレクトリの深さが増す傾向にあり、大規模プロジェクトでは管理が煩雑になることがあります。

クラスマップによるオートロード

クラスマップは、PSR-4やPSR-0とは異なり、すべてのクラスファイルを手動で指定する方式です。特定のクラスとファイルパスを直接マッピングするため、オートロードのパフォーマンスを向上させることができますが、管理には手間がかかります。

  1. 利点
  • クラスファイルの検索を完全に回避するため、オートロードの速度が最も速くなります。
  • PSR-4やPSR-0に従っていないレガシーコードや特殊なプロジェクト構成でも対応可能です。
  1. 欠点
  • 新しいクラスを追加したり、ファイル名を変更した場合に手動でマップを更新する必要があり、メンテナンスが煩雑になります。
  • 自動的にクラスファイルを探すわけではないため、PSR-4のような柔軟性はありません。

クラスマップは以下のように設定します：

{
    "autoload": {
        "classmap": [
            "src/CustomClass.php",
            "lib/LegacyClass.php"
        ]
    }
}

ファイルベースのオートロード

ファイルベースのオートロードでは、特定のファイルを明示的に読み込むように設定します。これは、単一のファイルに複数の関数やクラスが含まれる場合や、初期化処理が必要なスクリプトをロードする際に有効です。

  1. 利点
  • 特定の初期化スクリプトやユーティリティ関数ファイルなど、明示的に読み込む必要がある場合に便利です。
  • シンプルなプロジェクトや、オートロードの設定が不要な場合に適しています。
  1. 欠点
  • オートロードの柔軟性が低く、大規模プロジェクトには向きません。
  • クラスが増えると手動管理が煩雑になるため、オートロードのメリットが薄れてしまいます。

ファイルベースのオートロードは以下のように設定します：

{
    "autoload": {
        "files": [
            "src/functions.php"
        ]
    }
}

各方式の比較まとめ

オートロード方式特徴利点欠点
PSR-4名前空間とディレクトリの柔軟なマッピング柔軟で管理が容易、大規模プロジェクトに最適なし
PSR-0厳密なディレクトリ構造規約に従った明確な構造、レガシーコードに対応ディレクトリの深さが増し、管理が煩雑
クラスマップクラスとファイルを手動でマッピング最も高速、PSRに従わないコードにも対応メンテナンスが煩雑、手動更新が必要
ファイルベース特定ファイルを明示的に読み込む初期化スクリプトや小規模プロジェクトに便利柔軟性が低く、大規模プロジェクトには不向き

PSR-4が標準的で推奨される方式ですが、プロジェクトの要件に応じて他の方式も適宜使い分けることが重要です。

Composerオートロードの利便性を最大化するヒント

Composerのオートロード機能をさらに活用するためのテクニックやベストプラクティスを紹介します。これらのヒントを取り入れることで、プロジェクトの開発効率とコードの品質を向上させることができます。

ヒント1: 名前空間とディレクトリ構造の一貫性を保つ

名前空間とディレクトリ構造が一致していると、クラスの管理が簡単になり、他の開発者がプロジェクトに参加した際にも理解しやすくなります。PSR-4の柔軟なマッピング機能を活用し、プロジェクトの論理的な構造に合わせてディレクトリを設計しましょう。

  • 例: App\Controllers\UserControllerクラスをsrc/Controllers/UserController.phpに配置する。
  • サブ名前空間を活用して、機能ごとにディレクトリを分けると、より一貫性のあるプロジェクト構造が実現します。

ヒント2: 自動テストでオートロードを検証する

プロジェクトの変更がオートロードに影響を与えることがあるため、PHPUnitや他のテストフレームワークを用いてオートロードの動作を自動的に確認するテストを導入します。例えば、クラスが正しくインスタンス化できるかをテストすることで、設定ミスを早期に検出できます。

use PHPUnit\Framework\TestCase;
use App\Models\User;

class AutoloadTest extends TestCase
{
    public function testUserClassAutoloading()
    {
        $user = new User();
        $this->assertInstanceOf(User::class, $user);
    }
}

ヒント3: Composerスクリプトを活用する

Composerのスクリプト機能を利用して、composer.jsonにカスタムコマンドを追加できます。これにより、オートロード設定の再生成やテストの実行を簡略化できます。

{
    "scripts": {
        "post-autoload-dump": [
            "phpunit"
        ],
        "test": "phpunit"
    }
}

上記の設定例では、オートロード設定が変更された後に自動的にPHPUnitのテストを実行するようになります。

ヒント4: クラスマップの最適化を行う

オートロードのパフォーマンスを向上させるために、クラスマップの最適化を行います。クラスマップを最適化すると、オートロードの際にクラスを検索するコストが低減されます。

composer dump-autoload --optimize

このコマンドは、本番環境でのパフォーマンスを向上させるために推奨されます。

ヒント5: 開発環境と本番環境で異なる設定を使い分ける

開発環境では、エラーの特定やデバッグがしやすいように詳細なオートロード設定を使用し、本番環境ではパフォーマンス重視の最適化設定を適用します。autoload-devセクションを利用して、開発専用のオートロード設定を追加しましょう。

{
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    }
}

本番環境ではcomposer install --no-devオプションを使用して、不要な開発パッケージを除外できます。

ヒント6: Composerプラグインを活用する

Composerにはさまざまなプラグインが存在し、オートロードの機能を拡張できます。例えば、composer-require-checkerプラグインを使うと、オートロード設定や依存関係が正しいかどうかを検証できます。

composer require --dev maglnet/composer-require-checker

このツールを活用することで、設定ミスや不要な依存関係を早期に発見できます。

ヒント7: PSR規約に準拠するための静的解析ツールを導入する

PHP CodeSnifferやPHPStanなどの静的解析ツールを使って、PSR規約に準拠したコードスタイルを維持することができます。これにより、クラス名や名前空間のミスを防ぎ、オートロードの正確性を確保できます。

composer require --dev squizlabs/php_codesniffer

静的解析ツールをプロジェクトに導入することで、オートロードの設定に影響する可能性のあるエラーを未然に防ぐことができます。

以上のヒントを取り入れることで、Composerオートロードの利便性を最大化し、効率的で安定した開発環境を整えることができます。

まとめ


本記事では、Composerを使用したPSR-4規約に基づくオートロード設定について解説しました。PSR-4を利用することで、PHPプロジェクトでのクラスローディングが自動化され、コードの管理が容易になります。また、名前空間とディレクトリ構造を一致させることで、プロジェクトの拡張性や保守性が向上します。

さらに、複数の名前空間の設定やクラスマップの使用など、オートロードの応用例も紹介しました。これらの設定やテクニックを活用し、Composerオートロードの利便性を最大限に引き出すことで、効率的な開発環境を構築しましょう。

PHP
PHP PSR-4 オートロード Composer

コメント

コメントする

目次