Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

PHP カンファレンス沖縄 2021

Shohei Okada

May 29, 2021
Tweet

More Decks by Shohei Okada

Other Decks in Programming

Transcript

  1. 自分たちのコードを

    Composer パッケージに

    分割して開発する

    2021/05/29 PHP カンファレンス沖縄 2021

    @okashoi


    View Slide

  2. 岡田 正平/おかしょい

    Twitter: @okashoi

    GitHub: @okashoi

    所属:株式会社ウィルゲート


    登壇:





    寄稿:


    View Slide

  3. 目次

    • 導入(問題提起、提案)

    • ローカルのディレクトリを Composer パッケージとして扱う方法

    • パッケージを分割する際の考え方

    • こぼれ話


    View Slide

  4. 目次

    • 導入(問題提起、提案)

    • ローカルのディレクトリを Composer パッケージとして扱う方法

    • パッケージを分割する際の考え方

    • こぼれ話


    View Slide

  5. 開発についてまわる問題

    何も意識せずにフレームワークを使って開発していると

    巨大なひとつの構造物となっていく


    結果、次のような状態を引き起こしやすい

    ● Controller に書き下される一連の詳細な処理

    ● 責任の境界が曖昧なクラス

    ● あちらこちらに出てくる同じような手順

    ● フレームワークの機能に過度に依存したコード


    → 可読性や再利用性の低下、バグの原因


    View Slide

  6. ソフトウェア設計の領域において古くから存在する

    「モジュール化」というアプローチ


    →しかし PHP は言語機能としてモジュールに相当するものを備えていない


    ※「モジュール」という語彙自体は「拡張モジュール」で使われるが別物

    モジュール化


    View Slide

  7. PHP における依存関係管理ツール



    依存関係を「パッケージ(※)」単位で扱う


    ※Composer におけるパッケージとは

     composer.json が存在するディレクトリ

    Composer


    View Slide

  8. PHP における依存関係管理ツール



    依存関係を「パッケージ(※)」単位で扱う


    ※Composer におけるパッケージとは

     composer.json が存在するディレクトリ

    Composer

    本発表で紹介する方法
    Composer パッケージを「モジュール」に近い概念として扱う


    View Slide

  9. 目次

    • 導入(問題提起、提案)

    • ローカルのディレクトリを Composer パッケージとして扱う方法

    • パッケージを分割する際の考え方

    • こぼれ話


    View Slide

  10. Packagist


    View Slide

  11. Packagist からパッケージを持ってくることだけが選択肢ではない


    Composer には「リポジトリ」という概念があり、

    GitHub のリポジトリやローカルに存在するディレクトリを

    composer install や composer require の対象にできる

    Composer におけるリポジトリ


    View Slide

  12. Packagist からパッケージを持ってくることだけが選択肢ではない


    Composer には「リポジトリ」という概念があり、

    GitHub のリポジトリやローカルに存在するディレクトリを

    composer install や composer require の対象にできる

    Composer におけるリポジトリ

    今回はこっち


    View Slide

  13. ローカルのディレクトリを Composer パッケージとして扱う

    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...

    View Slide

  14. ローカルのディレクトリを Composer パッケージとして扱う

    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...

    View Slide

  15. ローカルのディレクトリを Composer パッケージとして扱う

    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...

    View Slide

  16. ローカルのディレクトリを Composer パッケージとして扱う

    {
    ...
    "repositories": [
    {
    "type": "path",
    "url": "../../packages/my-package"
    }
    ],
    ...
    }
    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...

    View Slide

  17. ローカルのディレクトリを Composer パッケージとして扱う

    {
    ...
    "repositories": [
    {
    "type": "path",
    "url": "../../packages/my-package"
    }
    ],
    ...
    }
    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...

    View Slide

  18. ローカルのディレクトリを Composer パッケージとして扱う

    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...
    $ composer require "my/package:*@dev"

    View Slide

  19. ローカルのディレクトリを Composer パッケージとして扱う

    ...
    ├── apps
    │ └── my-app
    │ └── composer.json
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...
    $ composer require "my/package:*@dev"
    "name": "my/package"

    View Slide

  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 を利用できるようになる 


    View Slide

  21. Laravel におけるディレクトリ構造の例

    ├── app
    │ ├── ...
    ...
    ├── composer.json
    ...
    ├── app
    │ ├── ...
    ...
    ├── packages
    │ └── my-package
    │ └── composer.json
    ...
    ├── composer.json
    ...
    ※ “my-package” はあくまで例なので、 

     適切な名前をつけてあげてください。 


    View Slide











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


    参考資料


    View Slide

  23. 目次

    • 導入(問題提起、提案)

    • ローカルのディレクトリを Composer パッケージとして扱う方法

    • パッケージを分割する際の考え方

    • こぼれ話


    View Slide

  24. パッケージに切り出す(モジュール化する)こと

    = インターフェースをデザインすること


    ポイントは

    ● (特にフレームワークとの)依存関係

    ● 凝集度と結合度

    どうやって分割していくか?


    View Slide

  25. フレームワークに依存している状態

    = 「フレームワークのその場所」から動かすのが困難な状態


    ● コードの再利用性が下がっている

    ● フレームワークのバージョンアップに追従しにくくなる

    ● 長期運用するアプリケーションではフレームワークを乗り換えることも

    ○ 過度に依存しているとほぼ書き直しになる

    「フレームワークに依存させないこと」の動機


    View Slide

  26. Laravel の例を挙げれば

    ● Illuminate に依存しない(use したり、完全修飾名で利用しない)

    ○ extends、implements、引数、戻り値に出てこない

    ● グローバルヘルパ関数や Class Alias(\Log とか)を使わない


    これらを取り除いて残るのは、自ずと「自分たち」固有のコードになるはず


    ※ここでいう「自分たち」とはサービスやビジネス

    フレームワークに依存していない状態


    View Slide

  27. 自分たち固有のコードとは?

    • 見積もりの計算ロジックかもしれない

    • マッチングのアルゴリズムかもしれない

    • データのアクセス権限に関する条件式かもしれない

    • 税金の計算かもしれない


    これら正しく抽出するには開発する対象領域への深い理解が必要

    →この過程こそがモデリング

    「自分たちのコード」


    View Slide











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


    参考資料


    View Slide

  29. モジュールの設計において古くから用いられている尺度


    凝集度:責任範囲が明確でそこに集中しているかどうか。高い方が良い。

    結合度:モジュール間でのデータの共有度合い。低いほうが良い。

    凝集度と結合度


    View Slide











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


    参考資料


    View Slide

  31. 型情報の上でフレームワークに依存しなくなっても

    「見えない依存関係」が存在しているケースがある

    ● 型宣言がない箇所で、フレームワーク固有のクラスを想定している

    ● 関数の呼び出しに暗黙の前提条件が存在している

    ● 型は int や string だが、その値の意味がフレームワークに特化している

    ○ 例)フレームワークで使われるクラス名の文字列


    このような実装は「結合度が高い」と言える

    →そのクラスや関数を使うのに、型から得られる情報以上の知識が

     必要になってないかを意識する

    見えない依存関係


    View Slide

  32. パッケージに切り出す(モジュール化する)こと

    = インターフェースをデザインすること


    ポイントは

    ● (特にフレームワークとの)依存関係

    ● 凝集度と結合度

    どうやって分割していくか?(再掲)


    View Slide

  33. パッケージに切り出す(モジュール化する)こと

    = インターフェースをデザインすること


    ポイントは

    ● (特にフレームワークとの)依存関係

    ● 凝集度と結合度


    →いきなり「自分たちのコード」を網羅的に切り出すのは難しい

     まず、1 つの関数だけでいいので切り出してみよう

    どうやって分割していくか?(再掲)


    View Slide

  34. 「自分たちのコード」を

    依存の束縛から解き放とう


    View Slide

  35. 目次

    • 導入(問題提起、提案)

    • ローカルのディレクトリを Composer パッケージとして扱う方法

    • パッケージを分割する際の考え方

    • こぼれ話


    View Slide

  36. 「同一パッケージ内からのみアクセスできるクラス」は定義できない


    パッケージの詳細を(仕組みとして)隠蔽できないため、運用でカバーする必要があ
    る

    PHP のクラスは全て public


    View Slide

  37. ルートパッケージの vendor ディレクトリ内に全ての依存関係が

    フラットに集約されるため、例えば次のような場合もエラーにならない

    依存関係を厳密にチェックできるわけではない

    ルートパッケージ
    パッケージ A パッケージ B
    ルートパッケージ
    パッケージ A パッケージ B
    ■ composer.json に定義した依存関係
 ■本来依存していないパッケージにアクセスできてしまう

    パッケージ B からパッケージ A のコードを利用


    View Slide

  38. 私はやったことはないが、想定できるのは

    🙆 分離することで CI のサイクルが早くなる

    🙆 共通のコードを複数のプロジェクトから使える

    🙅 運用やデプロイ(ローカル開発環境含む)が複雑になる

    🙅 インターフェースの決定や変更について取り決めが必要になる


    相当の規模の開発でないか、運用上のノウハウが無い限り

    デメリットの方が大きい気がする(経験・知見のある方の意見求ム)

    パッケージごとに Git リポジトリを別にすべきか?


    View Slide

  39. 「フレームワークにどこまで依存するのか?」は必ずどこかで線引きが必要


    フレームワークに依存しないコードは

    • フレームワーク側から適切に呼び出すために、

    フレームワークの一歩踏み込んだ理解が必要になる

    • コードの量が増える傾向にある


    あるいは Carbon や Guzzle 等のライブラリへの依存も同様

    最終的にどこまでやるかは「さじ加減」


    View Slide