最初にいくつかの背景
私たちの会社は、開発者が 4 人しかいない小さなスタートアップですが、開発プロセスを簡素化し、生産性を向上させるために、製品を再利用可能なモジュールにリファクタリングし始めています。その過程で、必要に応じて単体テストを導入したいと考えています。
小規模なスタートアップではよくあることですが、あまりにも多くの開発時間を無駄にする余裕はありませんが、中長期的にビジネスを成功させるためには、これが非常に重要であることがわかります。
現在、2 つのエンドユーザー製品があります。どちらも、主に Web サービス、安らかな API、巨大なデータベースで構成される、独自の内部ビジネス層の上に構築された Laravel (PHP) アプリケーションです。
このビジネス レイヤーは、これらの製品のほとんどのデータを提供しますが、それぞれがまったく異なる用途で使用します。完成間近の 2 つの製品を維持および改善する以外に、近い将来に他の製品を構築する予定です。
そのために、これらの (および将来の) 製品の共通ロジックを再利用可能で分離されたモジュールに抽象化する予定です。Composer についての知識はほとんどありませんが、明らかな選択は Composer のようです。
さて、本当の質問に
テスト駆動型の方法で内部パッケージを開発する方法について、他の意見をお聞きしたいと思います。各モジュールは、独自の単体テストとその依存関係を必要とするコンポーザー パッケージにする必要がありますか?それとも、各モジュールの名前空間を使用して単一のパッケージを構築する必要がありますか?
少し明確にするために、たとえば CurlWrapper モジュールが必要であり、これは InternalWebserviceAPI モジュール (およびその他のいくつか) で必要になります。
個人的には、モジュールごとに完全に個別のパッケージを用意し、composer.json で依存関係を宣言するというアイデアが好きです。これにより、精神的に分離が強制され、いつかそれらのパッケージの一部をオープンソースとして公開できるようになります。また、更新が必要な依存モジュールのバージョンを凍結できるため、これらのモジュールの重大な変更を簡素化することもできます。
ただし、この分離により複雑さが増し、保守とテストが難しくなる可能性があると思います。これは、各モジュールが独自のプロジェクトである必要があり、非常に多くのモジュールを追跡するための人員が不足しているためです。小さなプロジェクト。
Composer は本当に私たちの問題に対する理想的なソリューションでしょうか? もしそうなら、どちらが推奨されますか: 単一のパッケージまたは複数のパッケージ?
編集1：
これらのモジュールのほとんどが次のようになることを指摘したいと思います。
- ライブラリ (つまり、YouTube の URL から ID を取得するか、日付を「x 秒前」に変換する)
- ラッパー (連鎖可能な CURL ラッパーのようなもの)
- Facades (当社の複数の Web サービスのうち、残りの 2 種類が必要です)