©tete marche CO., LTD. 安全にPHPでWebアプリ開発 するために実践していること 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/479811 6831

©tete marche CO., LTD. 10 自動テストとCIによるテスト自動化はもはや当たり前 ● 2023年現在、 テストを全く書かない開発はありえない ○ 有名な「テストがないコードはレガシーコードだ！」 02. テストを更に堅牢にするテスト戦略 出典: https://www.amazon.co.jp/dp/479811 6831 出典: https://alu.jp/series/%E6%9D%B1%E4%BA%AC%E5%8D%8D%E3%83%AA%E3%83%99 %E3%83%B3%E3%82%B8%E3%83%A3%E3%83%BC%E3%82%BA/crop/W8LJCePySOaA

©tete marche CO., LTD. 11 テスト戦略 ● テストピラミッド ○ 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. 12

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

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

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

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

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

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

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

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

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

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

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

©tete marche CO., LTD. 24 参考文献 ● 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. 26

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

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

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

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

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

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