©tete marche CO., LTD. 安全にPHPでWebアプリ開発 するために実践していること 2023/10/8 PHPカンファレンス2023 テテマーチ株式会社 篠⽥

©tete marche CO., LTD. 2 ✔ テテマーチ株式会社 SINIS for Twitter テックリード 篠⽥ 北⽃ (@pinkumohikan) ✔ 社内ブランディング「定期的に髪⾊ が変わるやべーやつ」 ✔ バックエンド寄りの技術が好き ISUCON毎年参戦中! (今年も出ます) ⾃⼰紹介

©tete marche CO., LTD. 3 このセッションの概要 PHPでWebアプリを作るとき、仕様変更や リファクタリングを安⼼安全に⾏うためにどういう⼯夫をしているか このセッションで得られるもの ・リリース前に不具合に気づける仕組みの作りかた ・不具合をリリースしてしまってもすぐに気づける仕組みの作りかた

©tete marche CO., LTD. Index ⽬次 4 1. 年々型安全になりつつあるPHPの⾔語仕様 2. テストを更に堅牢にするテスト戦略 3. 静的解析で、テストされていない部分の不安を減らす 4. MTTRを縮めるエラートラッキングツールの活⽤ 5. エラーの⾒落としを防ぐ週次エラー確認イベント

©tete marche CO., LTD. 年々型安全になりつつあるPHPの⾔語仕様 01. 5

©tete marche CO., LTD. 6 PHPはインターネット黎明期から存在するプログラミング⾔語 ● 後⽅互換性 重視 ● 「ゆるいWeb」で使いやすい設計 ○ フォーム ( "" == null、"1" == bool(true)、"1000" == int(1000) ) ○ ゆえのempty関数、抽象等価演算⼦ ● 近頃は「ゆるさ」よりも「堅牢さ」が求められるように ○ Webの進化によりシステムで取り扱うデータの重要性、求められる信頼性が上がってきた ● それに応える形でPHP⾔語仕様も進化し続けている ○ 感謝 01. 年々型安全になりつつあるPHPの⾔語仕様

©tete marche CO., LTD. 7 型に関連するアップデート → 型機能をしっかり使うことで、PHPでも堅牢なコードを書けるように 01. 年々型安全になりつつあるPHPの⾔語仕様 PHP 7 PHP 5 PHP 8 ・strict mode ・タイプヒンティング ・返り値宣⾔ ・クラスのプロパティ ・nullable ・readonly property/class ・DNF型 ・動的プロパティ⾮推奨

©tete marche CO., LTD. テストを更に堅牢にするテスト戦略 02. 8

©tete marche CO., LTD. 9 ⾃動テストとCIによるテスト⾃動化はもはや当たり前 ● 2023年現在、 テストを全く書かない開発はありえない ○ 有名な「テストがないコードはレガシーコードだ！」 02. テストを更に堅牢にするテスト戦略 出典: https://www.amazon.co.jp/dp/4798116831

©tete marche CO., LTD. 10 テスト戦略 ● テストピラミッド ○ Unit Test、Integration Test、E2E Test ○ テスト速度と信頼性のバランスを取れる ● 式年遷宮 ○ Googleは数年おきに丸っとコードベースを書き直している ○ レガシーや複雑さの軽減、知識と所有権の引き継ぎ ○ ⾔語やFWへの依存を抑え、E2E Testのカバレッジを広く 取ることで書き直しやすくする ● 「不具合に テストを書いて ⽴ち向かう」 ○ from プログラマが知るべき97のこと by t-wada ○ 「不具合があること」「この変更によって直ったこと」が 明確になる 02. テストを更に堅牢にするテスト戦略 出典: https://semaphoreci.com/blog/testing-pyramid

©tete marche CO., LTD. 静的解析で、テストされていない部分の不安を減らす 03. 11

©tete marche CO., LTD. 12 03. 静的解析で、テストされていない部分の不安を減らす テストカバレッジの隙間を静的解析でカバーする ● 静的解析 ○ コードを 実⾏せずに 検査 ○ イメージとしては「脳内コンパイラ」 ○ 書かれているコードが理論的に正しいか (ルールに従っているか) を検査できる ○ テストコードが書かれていない部分もカバー可能 ● 静的解析ができる状態 = IDEフレンドリー ○ IDEフレンドリー = IDEが型や依存関係を理解していて、IDEの加護 (補完、ジャンプ、etc…) を最⼤限享受出来る状態 ○ 開発⽣産性を上げるうえで超重要

©tete marche CO., LTD. 13 PHP⽤の静的解析ツール 03. 静的解析で、テストされていない部分の不安を減らす これらはCIで動かして、passしなければmerge出来ないよう強制するべし syntax check系 ● PHPStan (Larastan) ● Psalm ● Phan code quality系 ● PHPMD その他 ● PHP Insights

©tete marche CO., LTD. 14 PHPStanの指摘例 03. 静的解析で、テストされていない部分の不安を減らす 出典: https://phpstan.org/

©tete marche CO., LTD. MTTRを縮めるエラートラッキングツールの活⽤ 04. 15

©tete marche CO., LTD. 16 04. MTTRを縮めるエラートラッキングツールの活⽤ 不具合を未然に防ぎきることの限界 ● Webシステムは年々複雑化 ○ サードパーティ製APIの利⽤、データ量や負荷具合、インフラ構成の複雑化、etc… ○ 「開発環境で動作確認しておけば絶対安全」とは⾔えない ● MTBF重視からMTTR重視へ ○ 未然に防げるものは未然に防ぐのは⾔わずもがな ○ 「未然に防ぐ」から「壊れたら早く直す」へ → 不具合に早く気づくためにエラートラッキングツールを使う

©tete marche CO., LTD. 17 04. MTTRを縮めるエラートラッキングツールの活⽤ エラートラッキングツールを使う ● Sentry ○ SaaS、SINIS for Twitterで採⽤、無料〜 ○ Slack通知するコードをException Handlerに 仕込むとかからでもOK！ ● チャットツールとの連携は必ず ○ 通知のリアルタイム性に意味がある ○ オオカミ少年問題には強い意志で戦う (トリアージ済み不具合、確率問題はガンガンmute) ● 業務時間外に来た通知への向き合い⽅ ○ チームや会社と相談して、明確に握っておく

©tete marche CO., LTD. 18 04. MTTRを縮めるエラートラッキングツールの活⽤ 不具合は学びの機会 ● 「そこだけ直して終わり」ではもったいない ○ 同じ失敗を2度しないのが⼤事 ● なぜ起きてしまったか（どうあれば起きていなかったか）、再発を仕組 みで防げないかを毎回振り返る ○ やりたくても今は出来ないこと、たらればでも案を出す ○ 回を重ねる度に成熟させる ● とはいえ… ○ やりすぎると続かない ○ 続けられる範囲でがんばる https://speakerdeck.com/yamaz/notoraburusisutemuhenodao

©tete marche CO., LTD. エラーの⾒落としを防ぐ週次エラー確認イベント 05. 19

©tete marche CO., LTD. 20 05. エラーの⾒落としを防ぐ週次エラー確認イベント リアルタイムの通知は必ず⾒落とされる ● エラー確認会を定期的にやるのがオススメ ○ SINIS for Twitter開発チームでは... 週⼀ エンジニア全員で集まり、検知されたエラーと対応状況の確認、対応⽅針の相談 ○ 内容によってドメイン知識が必要だったり、複数選択肢が考えられたり、腕の⾒せどころ

©tete marche CO., LTD. まとめ 21

©tete marche CO., LTD. 22 まとめ 1. PHPは頑張っている ○ みんなで応援しましょう 2. テストを⼤事にしよう ○ テストを書き、CIで検査を⾃動化する 3. 静的解析は万病に効く ○ テスト漏れの不安を軽減でき、IDEの加護を受けやすくなる 4. エラートラッキングツールを使おう ○ 「未然に防ぐ」から「壊れたら早く直す」へ 5. 起きたエラーを定期的に確認しよう ○ リアルタイムの通知は必ず⾒落とされる前提に⽴つ

©tete marche CO., LTD. 23 参考⽂献 ● PHPの歴史 - PHP ○ https://www.php.net/manual/ja/history.php.php ● PHPの今とこれから2022 - Rui Hirokawa ○ https://www.slideshare.net/hirokawa/php2022 ● 事例で学ぶテストピラミッドを使ったテスト戦略 - Think IT ○ https://thinkit.co.jp/article/13346 ● Googleのソフトウェアエンジニアリング⽂化 - InfoQ ○ https://www.infoq.com/jp/news/2019/11/google-software-engineering/ ● 不具合にテストを書いて⽴ち向かう - t-wadaのブログ ○ https://t-wada.hatenablog.jp/entry/debugging-tests ● プログラマが知るべき97のこと - 和⽥卓⼈ ○ https://www.amazon.co.jp/dp/4873114799 ● ノートラブルシステムへの道 - Daisuke Yamazaki ○ https://speakerdeck.com/yamaz/notoraburusisutemuhenodao ● Test Sizes - Google Testing Blog ○ https://testing.googleblog.com/2010/12/test-sizes.html ● The Twelve-Factor App ○ https://12factor.net/ja/

No content

©tete marche CO., LTD. 25

©tete marche CO., LTD. Q&A 26

©tete marche CO., LTD. 27 Q&A 想定質問 ● SRE活動以外に堅牢性・信頼性のためにやっていることは？ ● どのぐらい最新に追従している？ ● やりたいことがあるが認めてもらえない (キレ気味) ● AIってどのぐらい活⽤してます？ ● 情報収集ってどうやってます？ ● 結構コストかけているけどそこまでやる？ ● 属⼈性問題どうしてる？ ● テスト時間が⻑くてキツイ ● やりたいことがあるが⾃信がない

©tete marche CO., LTD. 28 ● SRE活動 ○ 週次でサーバ負荷、リソース使⽤状況の確認 ○ バックエンド、フロントエンドのエラー確認、エスカレーション ○ ライブラリバージョンアップ ● 最新への追従 ○ PHP 8.2 ○ セキュリティアップデートには基本即⽇対応 (Dependabot活⽤) ○ ライブラリも随時バージョンアップ ■ バージョンアップ過程でChangeLogを読むとトレンドが知れる ○ ⾃動テストと静的解析 (あとコンテナ環境) があるからこそ出来ている Q: 安⼼安全のために他にやっていること

©tete marche CO., LTD. 29 ● 相談 ○ 正攻法 ○ ⽇頃から「こいつは（技術的に）変なこと⾔わない」という安⼼感、チーム・会社の理解が 必要なので難しいこともある ● 勝⼿にやる ○ スキマ時間での活動成果には基本⽂句⾔われない ● プライベートでやる ○ プライベートな時間での活動成果には基本⽂句⾔われない ○ 短期的にはボランティアになるけど、⽣産性に寄与する活動は⻑期的に必ず評価される ● 脅す ○ 「えっ！こんな当たり前なことやらないんですか？？？？？」 ○ 「市場価値上がらないので、ずっとこのままだったら転職考えちゃうかもです」 ○ 「俺は良いけど、採⽤候補者が⾒たらどう思うかな？」 ○ 「n年後、保守コスト激⾼でまともに新規開発できなくなりますよ」 Q: やりたいことがあるが認めてもらえない

©tete marche CO., LTD. 30 ● AI活⽤ ○ GitHub Copilotは全社予算で導⼊済み ○ 個⼈的にはChatGPTにも課⾦中 ○ プロダクトでもAI活⽤したいな〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ● 情報収集 ○ SNS、技術イベント、社内のエンジニアチャンネル ● 安⼼安全のために頑張っている理由 ○ 楽をしたい (気をつけるを辞めたい) ■ 仕組みは⼀度作ってしまえば維持はそれほど⼤変じゃない ○ 導⼊直後はコストが⽬につくが、変更しやすさが段違いなので⻑期では必ずペイする (テスト と同じ) Q: その他

©tete marche CO., LTD. 31 ● 属⼈性問題 ○ 属⼈性排除は強く意識している ○ アクション例: CI等のメンテを他の⼈とやる、任せる (あえて⾃分でやらない)、連休を取る ● テスト時間が⻑くてキツイ ○ お⾦で殴る (マシンスペックを上げる、配列数を上げる) ○ 遅いテストを⾒つけ、チューニングする (phpunit-speedtrap等) ○ Test Sizesの概念を取り⼊れる ■ ⼿元で実⾏するものとCIで実⾏するものを分ける、早いもの → 遅いものの多段にする ● やりたいことがあるが⾃信がない ○ その⼿のテーマで登壇している⼈に助けを求める ○ 副業・業務委託でやってくれる⼈を探す (持続的にするために、能⼒には対価を払う) Q: その他