自分たちのコードを Composer パッケージに分割して開発する

PHP カンファレンス沖縄 2021

1. 自分たちのコードを
 Composer パッケージに
 分割して開発する
 2021/05/29 PHP カンファレンス沖縄 2021
 @okashoi

2. 岡田 正平／おかしょい
 Twitter: @okashoi
 GitHub: @okashoi
 所属：株式会社ウィルゲート
 
 登壇：
 
 
 
 
 寄稿：

3. 目次
 • 導入（問題提起、提案）
 • ローカルのディレクトリを Composer パッケージとして扱う方法
 • パッケージを分割する際の考え方
 • こぼれ話

4. 目次
 • 導入（問題提起、提案）
 • ローカルのディレクトリを Composer パッケージとして扱う方法
 • パッケージを分割する際の考え方
 • こぼれ話

5. 開発についてまわる問題
 何も意識せずにフレームワークを使って開発していると
 巨大なひとつの構造物となっていく
 
 結果、次のような状態を引き起こしやすい
 • Controller に書き下される一連の詳細な処理
 • 責任の境界が曖昧なクラス
 • あちらこちらに出てくる同じような手順
 • フレームワークの機能に過度に依存したコード
 
 → 可読性や再利用性の低下、バグの原因

6. ソフトウェア設計の領域において古くから存在する
 「モジュール化」というアプローチ
 
 →しかし PHP は言語機能としてモジュールに相当するものを備えていない
 
 ※「モジュール」という語彙自体は「拡張モジュール」で使われるが別物
 モジュール化

7. PHP における依存関係管理ツール
 
 
 依存関係を「パッケージ（※）」単位で扱う
 
 ※Composer におけるパッケージとは
 　composer.json が存在するディレクトリ
 Composer

8. PHP における依存関係管理ツール
 
 
 依存関係を「パッケージ（※）」単位で扱う
 
 ※Composer におけるパッケージとは
 　composer.json が存在するディレクトリ
 Composer
 本発表で紹介する方法 Composer パッケージを「モジュール」に近い概念として扱う
 

9. 目次
 • 導入（問題提起、提案）
 • ローカルのディレクトリを Composer パッケージとして扱う方法
 • パッケージを分割する際の考え方
 • こぼれ話

10. Packagist

11. Packagist からパッケージを持ってくることだけが選択肢ではない
 
 Composer には「リポジトリ」という概念があり、
 GitHub のリポジトリやローカルに存在するディレクトリを
 composer install や composer require の対象にできる
 Composer におけるリポジトリ

12. Packagist からパッケージを持ってくることだけが選択肢ではない
 
 Composer には「リポジトリ」という概念があり、
 GitHub のリポジトリやローカルに存在するディレクトリを
 composer install や composer require の対象にできる
 Composer におけるリポジトリ
 今回はこっち

13. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ...
14. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ...
15. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ...
16. ローカルのディレクトリを Composer パッケージとして扱う
 { ... "repositories": [ { "type": "path", "url": "../../packages/my-package" } ], ... } ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ...
17. ローカルのディレクトリを Composer パッケージとして扱う
 { ... "repositories": [ { "type": "path", "url": "../../packages/my-package" } ], ... } ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ...
18. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ... $ composer require "my/package:*@dev"
19. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ... $ composer require "my/package:*@dev" "name": "my/package"
20. ローカルのディレクトリを Composer パッケージとして扱う
 ... ├── apps │ └── my-app │ └── composer.json ├── packages │ └── my-package │ └── composer.json ... apps/my-app/vendor/my/package から 
 packages/my-package へとシンボリックリンクが張られる 
 
 → Composer の autoload 機能を経由して 
 　 my-app から my-package を利用できるようになる 

21. Laravel におけるディレクトリ構造の例
 ├── app │ ├── ... ... ├── composer.json ... ├── app │ ├── ... ... ├── packages │ └── my-package │ └── composer.json ... ├── composer.json ... ※ “my-package” はあくまで例なので、 
 　適切な名前をつけてあげてください。 

22. 
 
 
 
 
 
 
 
 
 
 後藤知宏, “Laravel Package Development”, Laravel JP Conference 2019, https://speakerdeck.com/mikakane/laravel-package-development
 
 参考資料

23. 目次
 • 導入（問題提起、提案）
 • ローカルのディレクトリを Composer パッケージとして扱う方法
 • パッケージを分割する際の考え方
 • こぼれ話

24. パッケージに切り出す（モジュール化する）こと
 = インターフェースをデザインすること
 
 ポイントは
 • （特にフレームワークとの）依存関係
 • 凝集度と結合度
 どうやって分割していくか？

25. フレームワークに依存している状態
 = 「フレームワークのその場所」から動かすのが困難な状態
 
 • コードの再利用性が下がっている
 • フレームワークのバージョンアップに追従しにくくなる
 • 長期運用するアプリケーションではフレームワークを乗り換えることも
 ◦ 過度に依存しているとほぼ書き直しになる
 「フレームワークに依存させないこと」の動機

26. Laravel の例を挙げれば
 • Illuminate に依存しない（use したり、完全修飾名で利用しない）
 ◦ extends、implements、引数、戻り値に出てこない
 • グローバルヘルパ関数や Class Alias（\Log とか）を使わない
 
 これらを取り除いて残るのは、自ずと「自分たち」固有のコードになるはず
 
 ※ここでいう「自分たち」とはサービスやビジネス
 フレームワークに依存していない状態

27. 自分たち固有のコードとは？
 • 見積もりの計算ロジックかもしれない
 • マッチングのアルゴリズムかもしれない
 • データのアクセス権限に関する条件式かもしれない
 • 税金の計算かもしれない
 
 これら正しく抽出するには開発する対象領域への深い理解が必要
 →この過程こそがモデリング
 「自分たちのコード」

28. 
 
 
 
 
 
 
 
 
 
 @77web, “そのコード、フレームワークの外でも動きますか？”, PHPerKaigi20201, https://speakerdeck.com/77web/sofalsekodo-huremuwakufalsewai-demodong-kimasuka 
 
 参考資料

29. モジュールの設計において古くから用いられている尺度
 
 凝集度：責任範囲が明確でそこに集中しているかどうか。高い方が良い。
 結合度：モジュール間でのデータの共有度合い。低いほうが良い。
 凝集度と結合度

30. 
 
 
 
 
 
 
 
 
 
 @sonatard, “オブジェクト指向その前に凝集度と結合度”, Object Oriented Conference 2020, https://speakerdeck.com/sonatard/coheision-coupling
 
 参考資料

31. 型情報の上でフレームワークに依存しなくなっても
 「見えない依存関係」が存在しているケースがある
 • 型宣言がない箇所で、フレームワーク固有のクラスを想定している
 • 関数の呼び出しに暗黙の前提条件が存在している
 • 型は int や string だが、その値の意味がフレームワークに特化している
 ◦ 例）フレームワークで使われるクラス名の文字列
 
 このような実装は「結合度が高い」と言える
 →そのクラスや関数を使うのに、型から得られる情報以上の知識が
 　必要になってないかを意識する
 見えない依存関係

32. パッケージに切り出す（モジュール化する）こと
 = インターフェースをデザインすること
 
 ポイントは
 • （特にフレームワークとの）依存関係
 • 凝集度と結合度
 どうやって分割していくか？（再掲）

33. パッケージに切り出す（モジュール化する）こと
 = インターフェースをデザインすること
 
 ポイントは
 • （特にフレームワークとの）依存関係
 • 凝集度と結合度
 
 →いきなり「自分たちのコード」を網羅的に切り出すのは難しい
 　まず、1 つの関数だけでいいので切り出してみよう
 どうやって分割していくか？（再掲）

34. 「自分たちのコード」を
 依存の束縛から解き放とう

35. 目次
 • 導入（問題提起、提案）
 • ローカルのディレクトリを Composer パッケージとして扱う方法
 • パッケージを分割する際の考え方
 • こぼれ話

36. 「同一パッケージ内からのみアクセスできるクラス」は定義できない
 
 パッケージの詳細を（仕組みとして）隠蔽できないため、運用でカバーする必要があ る
 PHP のクラスは全て public

37. ルートパッケージの vendor ディレクトリ内に全ての依存関係が
 フラットに集約されるため、例えば次のような場合もエラーにならない
 依存関係を厳密にチェックできるわけではない
 ルートパッケージ パッケージ A パッケージ B ルートパッケージ パッケージ A パッケージ B ▪ composer.json に定義した依存関係
 ▪本来依存していないパッケージにアクセスできてしまう
 パッケージ B からパッケージ A のコードを利用

38. 私はやったことはないが、想定できるのは
 🙆 分離することで CI のサイクルが早くなる
 🙆 共通のコードを複数のプロジェクトから使える
 🙅 運用やデプロイ（ローカル開発環境含む）が複雑になる
 🙅 インターフェースの決定や変更について取り決めが必要になる
 
 相当の規模の開発でないか、運用上のノウハウが無い限り
 デメリットの方が大きい気がする（経験・知見のある方の意見求ム）
 パッケージごとに Git リポジトリを別にすべきか？

39. 「フレームワークにどこまで依存するのか？」は必ずどこかで線引きが必要
 
 フレームワークに依存しないコードは
 • フレームワーク側から適切に呼び出すために、
 フレームワークの一歩踏み込んだ理解が必要になる
 • コードの量が増える傾向にある
 
 あるいは Carbon や Guzzle 等のライブラリへの依存も同様
 最終的にどこまでやるかは「さじ加減」