PHP でもアーキテクチャテストしたい！ / #phperkaigi / PHPerKaigi 2021

PHPerKaigi 2021 ( https://phperkaigi.jp/2021/ ) の登壇資料

プロポーザル
https://fortee.jp/phperkaigi-2021/proposal/4658ce92-3c45-43f3-a14c-76787e923725

当日のタイムライン
https://twitter.com/search?q=%23phperkaigi%20%23a%20since%3A2021-03-27_16%3A50%3A00_JST%20until%3A2021-03-27_17%3A20%3A00_JST&src=typed_query&f=live

Transcript

1. PHP でもアーキテクチャテスト したい！ PHPerKaigi 2021 @kawanamiyuu
2. 自己紹介 • かわなみゆう • @kawanamiyuu • 株式会社ラクス / Lead Engineer • 人事・労務業務を楽にする SaaS の開発 • Spring Boot / Doma / Vue.js / Puppeteer / GitLab CI • Java のほうから来ました。PHP がすきです。 2
3. 今日話すこと 1. アーキテクチャ設計という営みの課題 2. アーキテクチャの正体とその問題点 3. アーキテクチャテストの紹介 4. アーキテクチャテストのその先 3
4. 話さないこと • PHP の各 Web アプリケーションフレームワークごとのアーキ テクチャ設計のプラクティス • 各アーキテクチャパターンの良し悪し • 各アーキテクチャテストツールのより詳細な使い方 4
5. はじめに 5
6. Layered Architecture （依存関係を逆転したレイヤードアーキテクチャ） 6 （一般的なレイヤードアーキテクチャ）
7. Clean Architecture 7
8. Independent Core Layer Pattern 8 https://blog.shin1x1.com/entry/independent-core-layer-pattern
9. Independent Core Layer Pattern 9 https://blog.shin1x1.com/entry/independent-core-layer-pattern このあと アーキテクチャテストの サンプルがでてきます
10. アーキテクチャ設計という営みの課題 10
11. こんな悩みありませんか？ 11
12. アーキテクトの悩み • 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ メンバー増員により、いつのまにか泥団子に • 開発プロセスとしてコードレビューは機能しているが、アーキテ クチャの観点ではレビューされない • 開発メンバーに設計力を上げてもらうためにチャレンジさせた いけど、丸投げするのはちょっと不安 12
13. アーキテクトの悩み • 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ メンバー増員により、いつのまにか泥団子に • 開発プロセスとしてコードレビューは機能しているが、アーキテ クチャの観点ではレビューされない • 開発メンバーに設計力を上げてもらうためにチャレンジさせた いけど、丸投げするのはちょっと不安 13
14. アーキテクトの悩み • 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ メンバー増員により、いつのまにか泥団子に • 開発プロセスとしてコードレビューは機能しているが、アーキテ クチャの観点ではレビューされない • 開発メンバーに設計力を上げてもらうためにチャレンジさせた いけど、丸投げするのはちょっと不安 14
15. アーキテクトの悩み • 開発初期に頑張って検討した設計方針が、納期優先・相次ぐ メンバー増員により、いつのまにか泥団子に • 開発プロセスとしてコードレビューは機能しているが、アーキテ クチャの観点ではレビューされない • 開発メンバーに設計力を上げてもらうためにチャレンジさせた いけど、丸投げするのはちょっと不安 15
16. 開発メンバーの悩み • 新しくクラスを作るときにどこに置くべきか毎回迷う • コードレビューで指摘されたけど、そんなルール聞いていな し、ドキュメントもないので知りようがない • ドメイン駆動設計？Clean Architecture？難しそうだし、ソー スコードがどうあればそれらが適用されたアーキテクチャとい えるのかイメージできない 16
17. 開発メンバーの悩み • 新しくクラスを作るときにどこに置くべきか毎回迷う • コードレビューで指摘されたけど、そんなルール聞いていな し、ドキュメントもないので知りようがない • ドメイン駆動設計？Clean Architecture？難しそうだし、ソー スコードがどうあればそれらが適用されたアーキテクチャとい えるのかイメージできない 17
18. 開発メンバーの悩み • 新しくクラスを作るときにどこに置くべきか毎回迷う • コードレビューで指摘されたけど、そんなルール聞いていな し、ドキュメントもないので知りようがない • ドメイン駆動設計？Clean Architecture？難しそうだし、ソー スコードがどうあればそれらが適用されたアーキテクチャとい えるのかイメージできない 18
19. 開発メンバーの悩み • 新しくクラスを作るときにどこに置くべきか毎回迷う • コードレビューで指摘されたけど、そんなルール聞いていな し、ドキュメントもないので知りようがない • ドメイン駆動設計？Clean Architecture？難しそうだし、ソー スコードがどうあればそれらが適用されたアーキテクチャとい えるのかイメージできない 19
20. 悩みの原因 • アーキテクチャ設計に関する知識が属人化している • アーキテクチャ設計に関する知識が暗黙知化している • 知っている人が人力でチェックするしかない • 知らなければ当然、チェックされることなくすり抜けてしまう 20
21. 悩みの原因 • アーキテクチャ設計に関する知識が属人化している • アーキテクチャ設計に関する知識が暗黙知化している • 知っている人が人力でチェックするしかない • 知らなければ当然、チェックされることなくすり抜けてしまう 21
22. 悩みの原因 • アーキテクチャ設計に関する知識が属人化している • アーキテクチャ設計に関する知識が暗黙知化している • 知っている人が人力でチェックするしかない • 知らなければ当然、チェックされることなくすり抜けてしまう 22 ソースコードの品質担保以上に、アーキテクチャの品質担保は難しい
23. 「アーキテクチャ」の正体 23
24. Layered Architecture （依存関係を逆転したレイヤードアーキテクチャ） 24 （一般的なレイヤードアーキテクチャ）
25. Layered Architecture （〇〇〇〇を逆転したレイヤードアーキテクチャ） 25 （一般的なレイヤードアーキテクチャ）
26. Clean Architecture 26
27. Clean Architecture 27
28. 依存関係 28
29. アーキテクチャとは 「依存関係」のガイドライン 29
30. アーキテクチャの正体 • アーキテクチャとはソフトウェアの構造についての取り決めで あり、 • 解像度を上げていくと、ソフトウェアを構成する責務や関心事 の「依存関係」についての取り決め • （乱暴に言うと）Layered Architecture も Clean Architecture も 、DDD のような設計論も、依存関係を適切 に設計したいだけ 30
31. 「アーキテクチャ」の問題点 31
32. 「ガイドライン」というものの性質 • ガイドラインとは「指針」「ルール」「マナー」 • 人が決めて、守る（守らせる） • 最初にルールをつくるのは、簡単 • ルール通りつくり始めるのも、簡単 32
33. 「ガイドライン」というものの性質 • ガイドラインとは「指針」「ルール」「マナー」 • 人が決めて、守る（守らせる） • 最初にルールをつくるのは、簡単 • ルール通りつくり始めるのも、簡単 　なにが難しいのか？ 33
34. 「ガイドライン」というものの性質 • ガイドラインとは「指針」「ルール」「マナー」 • 人が決めて、守る（守らせる） • 最初にルールをつくるのは、簡単 • ルール通りつくり始めるのも、簡単 　なにが難しいのか？ 34 アーキテクチャの維持が難しい。 人が決めたものであるがゆえ、壊れやすい。
35. PHP ならではの問題 • クラスはすべて公開（public） • クラスのメソッドも公開（public）か非公開（protected, private）のみ • 言語仕様レベルで依存関係をコントロールできない 35
36. 他のプログラミング言語では • 例えば Java ではクラスやメソッドの可視性をパッケージプライ ベートにできる ◦ PHP 風に言うと、可視性を名前空間内に限定できる • 言語仕様レベルである程度、依存関係をコントロールできる • が、やはり十分ではない 36
37. どうすればよいか？ 37
38. 38 アーキテクチャをテストしたい
39. アーキテクチャテストの紹介 39
40. アーキテクチャテスト を一言でいうと • アプリケーションを構成するクラスの依存関係や、アプリケー ション固有の実装ルールをコードとして表現し、自動テストする こと • コード化により、設計に関する暗黙知が形式知化される • 自動化により、一定の強制力をもってアーキテクチャの設計品 質を担保し続けることができる 40
41. アーキテクチャテスト を一言でいうと • アプリケーションを構成するクラスの依存関係や、アプリケー ション固有の実装ルールをコードとして表現し、自動テストする こと • コード化により、設計に関する暗黙知が形式知化される • 自動化により、一定の強制力をもってアーキテクチャの設計品 質を担保し続けることができる 41
42. アーキテクチャテスト を一言でいうと • アプリケーションを構成するクラスの依存関係や、アプリケー ション固有の実装ルールをコードとして表現し、自動テストする こと • コード化により、設計に関する暗黙知が形式知化される • 自動化により、一定の強制力をもってアーキテクチャの設計品 質を担保し続けることができる 42
43. アーキテクチャテスト を一言でいうと • アプリケーションを構成するクラスの依存関係や、アプリケー ション固有の実装ルールをコードとして表現し、自動テストする こと • コード化により、設計に関する暗黙知が形式知化される • 自動化により、一定の強制力をもってアーキテクチャの設計品 質を担保し続けることができる 43
44. アーキテクチャテスト・フレームワーク • sensiolabs-de/deptrac（PHP） • carlosas/phpat（PHP） • nazonohito51/dependency-analyzer（PHP） • TNG/ArchUnit（Java） • TNG/ArchUnitNET（C#） • MaibornWolff/ts-arch（TypeScript） 44
45. アーキテクチャテスト・フレームワーク • sensiolabs-de/deptrac（PHP） • carlosas/phpat（PHP） • nazonohito51/dependency-analyzer（PHP） • TNG/ArchUnit（Java） • TNG/ArchUnitNET（C#） • MaibornWolff/ts-arch（TypeScript） 45 この 2 つのテストフレーム ワークを紹介します。
46. 46 （本日のお題） 独立したコアレイヤーパターン のアーキテクチャテスト
47. アーキテクチャテストの　 サンプルコード 47 https://github.com/kawanamiyuu/independent-core-layer-architecture-test
48. deptrac でのアーキテクチャテスト 48
49. deptrac の特徴 • 名前空間やディレクトリを layer と捉えて、layer に含まれるの クラスの依存関係をテストできる • YAML ファイルに layer の依存関係の rule を定義する • 依存を「許可する」意味のテストがしやすい 49
50. Demo (1) 50
51. phpat でのアーキテクチャテスト 51
52. phpat の特徴 • メソッドチェーンを利用した DSL（fluent interface）によりアー キテクチャテストをコードとして実装する • 単純な依存関係だけでなく、クラスが期待するインターフェイス を implements しているか、というような実装ルールもチェッ クできる • 依存を「禁止する」意味のテストがしやすい 52
53. Demo (2) 53
54. アーキテクチャテストのその先 54
55. アーキテクチャテストの失敗は悪か？ • アーキテクチャテストはあるべき依存関係を表現したもの • アーキテクチャテストは失敗しないはずのテスト • アーキテクチャテストが失敗するとき ◦ 実装誤り ◦ 　 ◦ 55
56. アーキテクチャテストの失敗は悪か？ • アーキテクチャテストはあるべき依存関係を表現したもの • アーキテクチャテストは失敗しないはずのテスト • アーキテクチャテストが失敗するとき ◦ 実装誤り ◦ アーキテクチャに対する発見のサイン ◦ アーキテクチャについて議論する始点 56
57. アーキテクチャを育てる • ドメイン駆動設計が設計⇔実装のフィードバックループを重視 するのと同じく • アーキテクチャも一度決めて終わりではない • ソフトウェアの成長の過程で、アーキテクチャに対してもフィー ドバックを得て、適切な依存関係を発見していく必要がある 57
58. アーキテクチャを育てる • ドメイン駆動設計が設計⇔実装のフィードバックループを重視 するのと同じく • アーキテクチャも一度決めて終わりではない • ソフトウェアの成長の過程で、アーキテクチャに対してもフィー ドバックを得て、適切な依存関係を発見していく必要がある 58
59. アーキテクチャの進化を支える • 境界づけられたコンテキストやドメインのあるべき依存関係に 向き合い続ける • モジュラーモノリスの実現 • マイクロサービスアーキテクチャへ発展可能性 59
60. アーキテクチャの進化を支える • 境界づけられたコンテキストやドメインのあるべき依存関係に 向き合い続ける • モジュラーモノリスの実現 • マイクロサービスアーキテクチャへ発展可能性 60
61. 今日話したこと 1. アーキテクチャ設計という営みの課題 ◦ アーキテクチャ設計品質の担保の難しさ 2. アーキテクチャの正体とその問題点 ◦ アーキテクチャは「依存関係のガイドライン」 3. アーキテクチャテストの紹介 4. アーキテクチャテストのその先 ◦ アーキテクチャテストが、アーキテクチャを育て、発展させる 61
62. 今日話したこと 1. アーキテクチャ設計という営みの課題 ◦ アーキテクチャ設計品質の担保の難しさ 2. アーキテクチャの正体とその問題点 ◦ アーキテクチャは「依存関係のガイドライン」 3. アーキテクチャテストの紹介 4. アーキテクチャテストのその先 ◦ アーキテクチャテストが、アーキテクチャを育て、発展させる 62
63. PHP でも アーキテクチャテスト、 やっていきましょう！ 63
64. （Appendix）アーキテクチャテストに関する過去の登壇資料など • ArchUnit で Java アプリケーションのアーキテクチャを CI する / JJUG CCC 2019 Spring ◦ https://speakerdeck.com/kawanamiyuu/jjug-ccc-2019-spring • ドメイン駆動設計を支えるアーキテクチャテスト / Object-Oriented Conference 2020 ◦ https://speakerdeck.com/kawanamiyuu/object-oriented-conference-2020 • マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト / JJUG CCC 2020 Fall ◦ https://speakerdeck.com/kawanamiyuu/jjug-ccc-2020-fall • アーキテクチャテスト Advent Calendar 2020 ◦ https://qiita.com/advent-calendar/2020/architecture-test 64