php-conference-japan-2022

Transcript

1. 　　　　　　
   © Chatwork
   PHP Conference Japan 2022. September 24, 2022.
   2022年09月24日　PHP部　山下 祐
   Chatwork株式会社
   リリースして11年経過した
   PHPアプリケーションにPHPStanを導入した
   

   View Slide

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

   View Slide

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株式会社にて選
   定。
   

   View Slide

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回 新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」より
   ビジネスチャットの市場環境
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

43. View Slide

44. View Slide