Rails のプロジェクトを PHPer のメンバのみでメンテ →他のメンバもわかる PHP にリプレースを検討 サーバレス サーバ・インフラの管理が不要 アプリケーションコードの知識だけで保守可能 ゼロベースで作れる案件が (Railsの件とは別に) あるため、そちらで試験的に導入? AWSの学習 AWS のドキュメント DevelopersIO AWS Lambda のカスタムランタイムで PHP を動かす サーバのセットアップや維持管理を気にしなくて良い サーバーレスで PHP を動かすツールがすでにある サーバーレス構築はすんなり 今は Laravel がルーティングしている Laravel Livewire を Lambda に載せられないか？ デプロイ方法は？ バッチ処理は？ (Lambda は 15分の制限) Lambda でコンテナイメージがサポートされるように 抽象化されたもの「だけ」しか知らないよりも具象の理解は助けになる

大規模サイト (100万ページ以上) Google の基準 クロールバジェットを意識したSEO 大規模サイトでコンテンツが中頻度 (1回/週) で更新 OR 中規模サイト (10,000以上) でコンテンツが目まぐるしく変更される これを満たさないなら、クロールバジェットを考えなくてもいい サーチコンソール 「カバレッジ」の「除外」 多すぎるのは問題→クロールバジェットを浪費している クエリの順番を決める 空の値のルールを決めておく リダイレクトすればインデックスはうまくいく リンクが存在する限りクロールはされる リニューアル前のURL インデックスは移行される リンクのURLが存在する限り、別のURLとしてクロールされる リダイレクトされるとはいえ、リニューアル前のURLは移行した方が良い リニューアルで無視されるようになったパラメータも注意 robotes.txt で拒否しているのにクロールされる 一時的に拒否を外して 404 や 301 を読ませる 内部リンクを確認する JS でのリンクに書き換え クエリパラメータからURLのパスに /tokyo?area=HOGE → /tokyo/HOGE URL 設計だいじ

知覚可能 操作可能 理解可能 堅牢 ちゃんとしたHTMLを書く (閉じタグ・入れ子構造など) 標準の HTML を適切に使う WAI-ARIA キーボードフレンドリー マシンフレンドリー SEOフレンドリー button タグ →キーボード h1 タグ →スクリーンリーダー・クローラ a タグ WAI-ARIA HTML では表現できないセマンティクスを追加する ロール 何をするのか？ ユーザーアクションによって変化しない プロパティ 関連づけられたデータ ステート 現在の状態 まずは標準の HTML 要素で解決する 何でもかんでも WAI-ARIA を使えばいいというものではない マウスホバーでツールチップが出てくるが、キーボード操作では出てこない VoiceOver 全ての属性を使う必要はない あくまでアクセシビリティを上げるための方法の一つにすぎない

VFS (virtual filesystem) vs 具体的なファイルシステム 最適な実装方法は状況により異なる アプリケーションに見せるAPIは変えずに実装を隠蔽する→VFS カーネルのプログラムを作るのは難しい * 権限がデカすぎる * システム全体がクラッシュ * セキュリティリスク * 開発サイクルを回しづらい * ネイティブコードにコンパイルされる言語である必要がある Filesystem in USEr space (FUSE) 特定の C の関数を呼ぶことで filesystem が作れる FFI を持つ言語なら FUSE が使える SSHFS / s3fs / Docker Desktop Linux 以外でも使える dokany (on Windows) osxfuse VFS: システムコールが呼ばれると、ファイルシステムによってコール FUSE: カーネル空間からユーザ空間へ通信 高レベルなラッパで型をつける PHP 以外では Wordpress を FUSE にマウントする実装がある (C, Python など) grep できる sed できる 編集できる

ユーザーストーリー ユニットテスト CI/CD ユーザストーリーの受け入れ条件が曖昧になりがち デグレチェックがユニットレベルでは収まらない場合、手動で同じシナリオをテストしている Q2の強化 アジャイルテストの4象限 技術面/ビジネス面 開発チーム支援(コーディング前・コーディング中)/製品批評(コーディング後) Q1: 技術面 & チーム支援 TDD ユニットテストなど Q2: ビジネス面 & チーム支援 ATDD ビジネス面の受け入れテストで駆動する Agile Alliance ユーザストーリーのスキルレベルを高める テストピラミッド UI Tests Service Tests Unit Tests 異なる粒度のテストを書く 高レベルになるほど、持つべきテストは少なくなる ピラミッド型になる 高レベルテストが多すぎる→アイスクリームコーン　アンチパターン ATDD (Acceptance TDD) API経由・UI経由での高レベルテスト E2E test ストーリ受け入れテスト 入れ子のフィードバックループ ATDD(外側) と TDD(内側) 外部品質・内部品質 バーティカルスライスのデリバリー cucumber gauge behat ユビキタス言語 手動テストもspecに書く 自動化は可能だがコスパが悪い 失敗することがわかっているテスト(レッドテスト)はCIから外す 失敗時の原因究明が難しい 饒舌なエラーメッセージ 状況のスナップショット Continuous Testing

PHPStan Phan Psalm autoload も認識できる bootstrapFiles 編集箇所と利用箇所を CI でチェック ルールレベルを徐々に引き上げていく 警告が多すぎると見落としてしまう・無視されやすくなる 型がついていないことによるエラーが多い 型よりも詳細な検査 Util_Assert::min SQL を静的解析 placeholder の型付け 警告レベルを低いレベルから導入 タイプヒントを積極的に書いていく PHPStan の拡張を追加する

開発開始までのオーバーヘッド 新規にチームにジョイン 担当範囲外の機能を理解 オンボーディングのコスト PHPerKaigi 2020 で発表あり 継続的にシステムの理解を助けるドキュメント 継続的ドキュメンテーション システムとドキュメントの乖離 書いてあることが間違っている・足りない * 徐々にずれていく * システムの更新タイミングとドキュメントの更新タイミングに差がある システムとドキュメントは対応関係がある * 間違ったドキュメント * 存在しないドキュメント システムとドキュメントの乖離を定量化する 継続的に システムの更新に近いタイミングで ドキュメントを更新し続ける Documentation as Code コードと同じツールでドキュメントを書く * issue tracker * vcs * plain text markup * automation 開発者 システム ドキュメント 構造化データ ソフトウェア システムから構造化データを抽出する PHPDoc OpenAPI ビュー 関心ごとに合わせてアーキテクチャを一つ以上の側面(断面)で説明する ビューの単位でドキュメントに スタックトレースからのドキュメント生成

エラー PHPエンジンがエラーを通知する 例外 プログラムが投げる PHP7-8とエラー PHPエンジンのエラーの一部が に変換されるようになった → try-catch で捕捉できる は例外とは異なる PHP8 でエラーレベルの引き上げ 捕捉すべきもの recoverable 捕捉すべきでないもの unrecoverable 開発時に対処できるもの 例外 * 捕捉して事後処理 * 捕捉せず(or 捕捉した上で)さらに上に是非を問う 開発段階で例外を把握し、ハンドリングを考えておく と はキャッチすべきでない 本番で起きてはいけない 本番で起きてはいけない →生じないのだから捕捉もしない 起こるかもしれないので本番環境でも考慮する 捕捉して対応するのではなく、未然に防ぐ 独自例外を使う を投げてしまうと、 catch ()せざるを得ない →catch 範囲が広すぎる SPL の例外を使う 例外翻訳 上位のレイヤが下位のレイヤの例外を捕捉し、上位レイヤのAPIに「翻訳」する 下位レイヤの知識に依存させない @throws 捕捉してほしい例外を書き連ねておく 呼び出しもとに負わせたい責任

Unary RPCs Server streaming RPCs Client streaming RPCs Bidirectional streaming RPCs Protobuf 実装とAPIが乖離しにくい 自動生成 複数言語でも相互に使える マイクロサービスのサービス通信 スマホアプリ ゲームサーバ PHP では？ PHP ではストリーミングが難しい リクエストごとにプロセスが使い捨て PHP ではgRPCのクライアントしか対応していない gRPC-Web ブラウザで扱うためのJSライブラリ+プロトコル HTTP/1.1 でも使える Unary RPC と Server streaming RPC のみ Envoy Nginx などで相互に gRPC と gRPC-Web で変換 Amp イベント駆動な並行処理のフレームワーク HTTP/2 対応 C#のgRPC-Webが楽

Independent Core Layer Pattern 開発初期のアーキテクチャが崩れる アーキテクチャ観点のコードレビューができない どこにクラスを置けばよいか？ ドキュメントがない アーキテクチャ設計に関する知識が属人化・暗黙知化 ガイドライン * 最初にルールを決めるのは簡単 * ルール通り作り始めるのも簡単 * →維持するのが難しい、人が決めたものゆえ壊れやすい PHP の特性 * クラスは public * 可視性の制御が public / protected / private のみ * 依存関係の制御が困難 アーキテクチャテスト クラスの依存関係や実装ルールをコードとして表現し、自動テスト化する deptrac phpat Independent Core Layer Pattern アーキテクチャテストの失敗 * 実装誤り * or アーキテクチャが適切でない * 開発の過程でフィードバックしていく モジュラーモノリス→マイクロサービスへ