php-conference-japan-2022

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 2 ● 山下祐 (Yamashita Tasuku) ● PHPエンジニア ○ 2019年12月~ Chatwork ● SNS ○ GitHub ■ tasuku43 ○ Twitter ■ task2021 ○ Zenn ■ https://zenn.dev/tasteck

Slide 3

Slide 3 text

事業概要 3 ● 国内最大級のビジネスチャット「Chatwork」を中心に、複数の周辺サービスを展開*1 ● ビジネスチャットのパイオニアであり国内利用者数No.1*2、導入社数は36.5万社*3を突破 ● 電話やメールから効率的なチャットへ、ビジネスコミュニケーションの変化を加速させ、プラットフォーム化を目指しています *2 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。

Slide 4

Slide 4 text

4 普及率は24.6％ほどで、非常にポテンシャルが大きいマーケットコロナ禍やDX推進の流れを受けテレワークが急激に普及*3 未だ低水準に止まるビジネスチャット国内普及率*2 全業種に展開可能な潜在市場規模(TAM*1) 東京23区全国テレワーク率の変化国内労働人口 6,724万人 Chatwork 料金単価 6,455億円ビジネスチャットツールを利用している 2019年12月 2020年12月単位：% *1 実現可能な最大の市場規模（Total Addressable Market）。外部統計資料や公表資料、当社保有のデータを元に当社が想定する市場を推察した市場規模であり、客観的な市場規模を示すものではありません。 *2 当社依頼による第三者機関調べ、2022年3月調査、n＝30,000 *3 内閣府「第2回新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」よりビジネスチャットの市場環境

Slide 5

Slide 5 text

詳細な情報はSpeakerDeckを御覧ください！ https://speakerdeck.com/chatwork_hr/chatwork

Slide 6

Slide 6 text

1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ

Slide 7

Slide 7 text

1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ

Slide 8

Slide 8 text

8 何度か本番環境でエラーが起きたから

Slide 9

Slide 9 text

実際に発生したことのあるエラー 9 ● nullに参照してエラー ● ライブラリアップデートしたら型が厳しめになっててエラー a. メソッドの引数にタイプヒントが追加されていた ● 存在しないメソッドを呼び出してエラー a. ブランチAで削除したメソッドがブランチBで利用されていた b. ブランチをマージしたタイミングで発生 ● etc…

Slide 10

Slide 10 text

実際に発生したことのあるエラー 10 ● nullに参照してエラー ● ライブラリアップデートしたら型が厳しめになっててエラー a. メソッドの引数にタイプヒントが追加されていた ● 存在しないメソッドを呼び出してエラー a. ブランチAで削除したメソッドがブランチBで利用されていた b. ブランチをマージしたタイミングで発生 ● etc…

Slide 11

Slide 11 text

11 静的解析ツールを使えば、こういう問題の発生を事前に防げるらしい

Slide 12

Slide 12 text

PHPStanとは 12 ● PHPコードを実行する前に静的に解析し、実行時エラーになるような問題のあるコードを検出・警告してくれるツール ○ メソッドや関数に渡される引数の型チェック ○ 未定義変数・メソッドへの参照 ○ nullになる可能性がある変数へのメソッド呼び出し

Slide 13

Slide 13 text

PHPStanとは 13 ● PHPコードを実行する前に静的に解析し、実行時エラーになるような問題のあるコードを検出・警告してくれるツール ○ メソッドや関数に渡される引数の型チェック ○ 未定義変数・メソッドへの参照 ○ nullになる可能性がある変数へのメソッド呼び出し ● バグが発生する可能性のあるコードに、リリースする前に気づくことができるようになる

Slide 14

Slide 14 text

14 コード修正をより安心してリリースできるようになる

Slide 15

Slide 15 text

導入した結果得られた事 15 ● 問題のあるコードがリリース前に気づけるようになった ● 思い切ったリファクタが気軽にできるようになった ● レビューコストの削減 ● ライブラリアップデートが安心して行えるようになった

Slide 16

Slide 16 text

1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ

Slide 17

Slide 17 text

導入していく道のり 17 ● 解析レベルを決定する ● baselineを作成し、既存のエラーは検知対象外にする ● CIでPHPStanを実行する ● PHPStanの警告への対応について相談できる場を作る

Slide 18

Slide 18 text

解析レベルについて ● PHPStanでは0~9までの解析レベルの設定が可能 ● 各レベルでどんなチェックがなされるかは以下のドキュメントに記載があります。 ○ https://phpstan.org/user-guide/rule-levels

Slide 19

Slide 19 text

解析レベルについて ● また、自分達がチェックしたい問題はどのレベルで検知できるのかは Playground | PHPStanを使って一つづつ見ていくと確実だと思います。

Slide 20

Slide 20 text

解析レベルを決定する 20 検知したい問題を明らかにするどの解析レベルでその問題が発見できるかを確認する

Slide 21

Slide 21 text

解析レベルを決定する 21 検知したい問題を明らかにするどの解析レベルでその問題が発見できるかを確認する (1) 未定義メソッド・未定義変数・未定義クラスへの参照 (2) 型エラーの検知

Slide 22

Slide 22 text

解析レベルを決定する 22 レベル4だと(2)が検知されない

Slide 23

Slide 23 text

解析レベルを決定する 23 レベル5だとどちらも検知された！

Slide 24

Slide 24 text

解析レベルを決定する 24 検知したい問題を明らかにするレベル5に決定 (1) 未定義メソッド・未定義変数・未定義クラスへの参照 (2) 型エラーの検知

Slide 25

Slide 25 text

25 よし、レベルは決まった！早速実行だ！

Slide 26

Slide 26 text

26 「二万件くらいエラーでた...」

Slide 27

Slide 27 text

baselineを作成し、既存のエラーは検知対象外にする 27 ● 数万件単位のエラーを今から対処していくのは現実的ではない ● 「本番環境でエラーなく動いているから問題ない」という前提にたち、一旦警告を除外対象にしてしまう ● 警告に対応しなくても導入を進める事ができる

Slide 28

Slide 28 text

baselineを作成し、既存のエラーは検知対象外にする 28 ● baselineとは ○ 特定のエラーをあらかじめ除外対象に指定しておく事で、PHPStanの解析時に無視してくれるようになる機能 ○ ひとつひとつのエラーを指定する必要はなく、コマンド一発でbaseline ファイルを作成できる

Slide 29

Slide 29 text

CIでPHPStanを実行する 29 ● mainブランチにマージされるコードの品質が保たれる ● PHPStanは実行時にキャッシュを残すので、それをCIの機能で保存しておけば、commit毎の解析は非常に早く終わる ○ ただし、キャッシュを使った結果と0から解析した結果は微妙に異なる事があるので注意が必要 ● reviewdogを使えば、どこで警告が受けたかをPRにコメントしてくれるようにもできる

Slide 30

Slide 30 text

PHPStanの警告への対応について相談できる場を作る 30 ● 導入当初は今まで特に気にしていなかったコードもPHPStanに怒られるようになる ○ 慣れるまでは「何に怒られてるの...??」とパッとわからない事もある ● 困った時に「どうすればいいの！」って言える部屋を作り、なるべく PHPStanが開発のストレスにならないようにしました開設してから半年以上たち、今ではたまにしか投稿されません

Slide 31

Slide 31 text

1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ

Slide 32

Slide 32 text

何を得られたか 32 ● 問題のあるコードがリリース前に気づけるようになった ● 思い切ったリファクタが気軽にできるようになった ● レビューコストの削減 ● ライブラリアップデートが安心して行えるようになった

Slide 33

Slide 33 text

何を得られたか 33 ● 問題のあるコードがリリース前に気づけるようになった ● 思い切ったリファクタが気軽にできるようになった ● レビューコストの削減 ● ライブラリアップデートが安心して行えるようになった

Slide 34

Slide 34 text

思い切ったリファクタが気軽にできるようになった 34 ● あるメソッドの引数・返り値のタイプヒントを変更する ● 巨大なメソッド・クラスを分解して、削除した ● 大規模なnamespaceの変更・パッケージ構成のリファクタ ● 型エラーや未定義のメソッド・クラスへの参照が残っていた場合は PHPStanが教えてくれるので、「ええいままよ！」と実行する事ができる

Slide 35

Slide 35 text

思い切ったリファクタが気軽にできるようになった 35 影響範囲ちゃんと調べてないけど、どれくらいエラー出るか一旦pushしてみよという選択が取れるようになった

Slide 36

Slide 36 text

何を得られたか 36 ● 問題のあるコードがリリース前に気づけるようになった ● 思い切ったリファクタが気軽にできるようになった ● レビューコストの削減 ● ライブラリアップデートが安心して行えるようになった

Slide 37

Slide 37 text

レビューコストの削減 37 ● 型エラーなどはPHPStanが保証してくれるので、レビュアーは「設計」や「仕様」に集中してレビューが可能になる ○ むしろ静的な部分はPHPStanの方がしっかり警告してくれる ● レビュイーも、型エラーなどは事前にPHPStanが警告してくれるので、静的解析をクリアした状態でレビュー依頼できる

Slide 38

Slide 38 text

レビューコストの削減（余談） 38 ● 先ほど「設計」に集中できる、と書きましたが、そこも静的解析ツールで負荷を軽減できる可能性があります ○ PHPStan ■ 「カスタムルール」で独自のルールを定義が可能 ■ 「あるライブラリを継承してはいけない」など ○ deptrac ■ 依存関係チェックツール ■ 「依存関係がアーキテクチャのルールに乗っ取っているか」を解析する事が可能

Slide 39

Slide 39 text

何を得られたか 39 ● 問題のあるコードがリリース前に気づけるようになった ● 思い切ったリファクタが気軽にできるようになった ● レビューコストの削減 ● ライブラリアップデートが安心して行えるようになった

Slide 40

Slide 40 text

ライブラリアップデートが安心して行えるようになった 40 ● メジャーバージョンアップなどでは、インターフェイスの破壊的な変更がある事が予想される ● 「引数のタイプヒントが追加された」などの変更も、PHPStanが見つけてくれる

Slide 41

Slide 41 text

1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ

Slide 42

Slide 42 text

まとめ 42 ● PHPStanの導入は低コストで非常に恩恵が高い ○ baselineを使ったら、導入コストも下がる ● 導入ハードルは超えやすいが、開発メンバーができるだけスムーズに慣れるような運用体制は必要