この記事は「ひとりでカンファレンスふりかえりo0h Advent Calendar 2021」のday-14です。
ひとりでカンファレンスふりかえりo0h Advent Calendar 2021 - Adventar
今日振り返るのは、「Composerの実装に見る「複雑な問題の解き方」」です。 PHP Conference Japan 2021のCfPに応募しました。Regular session (25 mins)の枠になります。
昨年・一昨年とphpconではComposerを題材にしたコードリーディング的な話をしていたのですが、実際に自分で読みながら＆他人に説明できるように構成をしている中で、もっと「メタ」な部分もテーマになるだろうな、という感覚がありました。
「パッケージのバージョンを管理する」と言った場合に、その中には複雑な問題が内包されていると思います。 要求されているパッケージをどう表現するか？それらのバージョンの解決は？依存関係はどうだろう？それらを解決する仕組みは？インストール済みのパッケージは？ こうした「問題」や「取り扱うべき概念」がとても多いはずなのです。
説明されれば「確かに、それも必要そうだよね」と感じる登場人物が多いと思います。では、それらは「詳細」「具体的なコード」として記述されるまで存在しないものなのでしょうか。 全くそんなことはなくて、その前に「問題をどうやって概念化して扱うか」という思考工程が挟まるはずです。
このトークでは、「Composerという具体的な存在や機能について、その中身を解く」という前回・前々回の話よりも一般化して、「複雑な問題をどうモデル化して扱うか」という問題ありきで「例えばComposerだとどうなんだろう？」といった向きで考えてみたいな、と思っていました。
これまで「設計」「モデリング」といった課題に注力して取り組んできた経験が少なく、自分の中で強化したいポイントとなっています。つまり勉強したいし、練習問題を問いたりしながら経験値を積みたい。
って考えた時に、「あぁそうだComposerならおもしろそうじゃない？」と思いました。 実際に、過去に内部を読んだ時に「リモートリポジトリにあるパッケージとバージョンのリスト」も「インストールされてローカルにある具体的なバージョンを伴うパッケージのリスト」も等しくRepositoryという概念として表現されており、あるいは「特定のライブラリへの依存」も「実行環境におけるPHPの拡張」も等しくPackageという概念として表現されており・・・というのを知って、非常に感銘を受けたのです。
どうやって問題をシンプルに扱えるようにするんだろう？というのは、まさに(枝葉を切り落として本質を炙り出す)モデリング活動の本義だと感じます。自分はそれがやれるようになりたいな、と。
やってみたいこと・面白そうなことは大抵「きっと他の人にとっても面白いはずだぞ！！」と思っているので、自分自身が学びを深めながら外部発信も出来たら素敵そうだなぁと思った次第