php-conference-japan-2022

Transcript

1. 　　　　　　 © Chatwork PHP Conference Japan 2022. September 24, 2022. 2022年09月24日　PHP部　山下 祐 Chatwork株式会社 リリースして11年経過した PHPアプリケーションにPHPStanを導入した
2. 自己紹介 2 • 山下 祐 (Yamashita Tasuku) • PHPエンジニア ◦ 2019年12月~ Chatwork • SNS ◦ GitHub ▪ tasuku43 ◦ Twitter ▪ task2021 ◦ Zenn ▪ https://zenn.dev/tasteck
3. 事業概要 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株式会社にて選 定。
4. 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回 新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」より ビジネスチャットの市場環境
5. 詳細な情報はSpeakerDeckを御覧ください ！ https://speakerdeck.com/chatwork_hr/chatwork
6. 1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ
7. 1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ
8. 8 何度か本番環境でエラーが 起きたから
9. 実際に発生したことのあるエラー 9 • nullに参照してエラー • ライブラリアップデートしたら型が厳しめになっててエラー a. メソッドの引数にタイプヒントが追加されていた • 存在しないメソッドを呼び出してエラー a. ブランチAで削除したメソッドがブランチBで利用されていた b. ブランチをマージしたタイミングで発生 • etc…
10. 実際に発生したことのあるエラー 10 • nullに参照してエラー • ライブラリアップデートしたら型が厳しめになっててエラー a. メソッドの引数にタイプヒントが追加されていた • 存在しないメソッドを呼び出してエラー a. ブランチAで削除したメソッドがブランチBで利用されていた b. ブランチをマージしたタイミングで発生 • etc…
11. 11 静的解析ツールを使えば、 こういう問題の発生を事前に防げるらしい
12. PHPStanとは 12 • PHPコードを実行する前に静的に解析し、実行時エラーになる ような問題のあるコードを検出・警告してくれるツール ◦ メソッドや関数に渡される引数の型チェック ◦ 未定義変数・メソッドへの参照 ◦ nullになる可能性がある変数へのメソッド呼び出し
13. PHPStanとは 13 • PHPコードを実行する前に静的に解析し、実行時エラーになる ような問題のあるコードを検出・警告してくれるツール ◦ メソッドや関数に渡される引数の型チェック ◦ 未定義変数・メソッドへの参照 ◦ nullになる可能性がある変数へのメソッド呼び出し • バグが発生する可能性のあるコードに、リリースする前に気づ くことができるようになる
14. 14 コード修正を より安心してリリース できるようになる
15. 導入した結果得られた事 15 • 問題のあるコードがリリース前に気づけるようになった • 思い切ったリファクタが気軽にできるようになった • レビューコストの削減 • ライブラリアップデートが安心して行えるようになった
16. 1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ
17. 導入していく道のり 17 • 解析レベルを決定する • baselineを作成し、既存のエラーは検知対象外にする • CIでPHPStanを実行する • PHPStanの警告への対応について相談できる場を作る
18. 解析レベルについて • PHPStanでは0~9までの解析レベルの設定が可能 • 各レベルでどんなチェックがなされるかは以下のドキュメントに記載がありま す。 ◦ https://phpstan.org/user-guide/rule-levels
19. 解析レベルについて • また、自分達がチェックしたい問題はどのレベルで検知できるのかは Playground | PHPStanを使って一つづつ見ていくと確実だと思います。
20. 解析レベルを決定する 20 検知したい問題を明らかにする どの解析レベルでその問題が発見できるかを確認する
21. 解析レベルを決定する 21 検知したい問題を明らかにする どの解析レベルでその問題が発見できるかを確認する (1) 未定義メソッド・未定義変数・未定義クラスへの参照 (2) 型エラーの検知
22. 解析レベルを決定する 22 レベル4だと(2)が検知されない
23. 解析レベルを決定する 23 レベル5だとどちらも検知された！
24. 解析レベルを決定する 24 検知したい問題を明らかにする レベル5に決定 (1) 未定義メソッド・未定義変数・未定義クラスへの参照 (2) 型エラーの検知
25. 25 よし、レベルは決まった！ 早速実行だ！
26. 26 「二万件くらいエラーでた...」
27. baselineを作成し、既存のエラーは検知対象外にする 27 • 数万件単位のエラーを今から対処していくのは現実的ではない • 「本番環境でエラーなく動いているから問題ない」という前提にたち、 一旦警告を除外対象にしてしまう • 警告に対応しなくても導入を進める事ができる
28. baselineを作成し、既存のエラーは検知対象外にする 28 • baselineとは ◦ 特定のエラーをあらかじめ除外対象に指定しておく事で、PHPStanの解 析時に無視してくれるようになる機能 ◦ ひとつひとつのエラーを指定する必要はなく、コマンド一発でbaseline ファイルを作成できる
29. CIでPHPStanを実行する 29 • mainブランチにマージされるコードの品質が保たれる • PHPStanは実行時にキャッシュを残すので、それをCIの機能で保存 しておけば、commit毎の解析は非常に早く終わる ◦ ただし、キャッシュを使った結果と0から解析した結果は微妙に 異なる事があるので注意が必要 • reviewdogを使えば、どこで警告が受けたかをPRにコメントしてく れるようにもできる
30. PHPStanの警告への対応について相談できる場を作る 30 • 導入当初は今まで特に気にしていなかったコードもPHPStanに怒られるよ うになる ◦ 慣れるまでは「何に怒られてるの...??」とパッとわからない事もある • 困った時に「どうすればいいの！」って言える部屋を作り、なるべく PHPStanが開発のストレスにならないようにしました 開設してから半年以上た ち、今ではたまにしか投稿さ れません
31. 1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ
32. 何を得られたか 32 • 問題のあるコードがリリース前に気づけるようになった • 思い切ったリファクタが気軽にできるようになった • レビューコストの削減 • ライブラリアップデートが安心して行えるようになった
33. 何を得られたか 33 • 問題のあるコードがリリース前に気づけるようになった • 思い切ったリファクタが気軽にできるようになった • レビューコストの削減 • ライブラリアップデートが安心して行えるようになった
34. 思い切ったリファクタが気軽にできるようになった 34 • あるメソッドの引数・返り値のタイプヒントを変更する • 巨大なメソッド・クラスを分解して、削除した • 大規模なnamespaceの変更・パッケージ構成のリファクタ • 型エラーや未定義のメソッド・クラスへの参照が残っていた場合は PHPStanが教えてくれるので、「ええいままよ！」と実行する事がで きる
35. 思い切ったリファクタが気軽にできるようになった 35 影響範囲ちゃんと調べてないけど、 どれくらいエラー出るか一旦pushしてみよ という選択が取れるようになった
36. 何を得られたか 36 • 問題のあるコードがリリース前に気づけるようになった • 思い切ったリファクタが気軽にできるようになった • レビューコストの削減 • ライブラリアップデートが安心して行えるようになった
37. レビューコストの削減 37 • 型エラーなどはPHPStanが保証してくれるので、レビュアーは「設 計」や「仕様」に集中してレビューが可能になる ◦ むしろ静的な部分はPHPStanの方がしっかり警告してくれる • レビュイーも、型エラーなどは事前にPHPStanが警告してくれるの で、静的解析をクリアした状態でレビュー依頼できる
38. レビューコストの削減（余談） 38 • 先ほど「設計」に集中できる、と書きましたが、そこも静的解析ツー ルで負荷を軽減できる可能性があります ◦ PHPStan ▪ 「カスタムルール」で独自のルールを定義が可能 ▪ 「あるライブラリを継承してはいけない」など ◦ deptrac ▪ 依存関係チェックツール ▪ 「依存関係がアーキテクチャのルールに乗っ取っているか」を 解析する事が可能
39. 何を得られたか 39 • 問題のあるコードがリリース前に気づけるようになった • 思い切ったリファクタが気軽にできるようになった • レビューコストの削減 • ライブラリアップデートが安心して行えるようになった
40. ライブラリアップデートが安心して行えるようになった 40 • メジャーバージョンアップなどでは、インターフェイスの破壊的な変更 がある事が予想される • 「引数のタイプヒントが追加された」などの変更も、PHPStanが見つけ てくれる
41. 1. なぜPHPStanを導入したか 2. 導入していく道のり 3. 何を得られたか 4. まとめ AGENDA アジェンダ
42. まとめ 42 • PHPStanの導入は低コストで非常に恩恵が高い ◦ baselineを使ったら、導入コストも下がる • 導入ハードルは超えやすいが、開発メンバーができるだ けスムーズに慣れるような運用体制は必要