予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント @t_wada
待ちわびていたセッションだった。
何年か前に PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 の動画に出会い自分の中のPHPの世界観が大きく変わった。この動画や資料は今でも思い出したように見返すし、後輩の指導などでも高頻度で利用させて頂いている。
CfPを見てこのセッションを思い出しとても楽しみにしていたのだが、ほぼ同じ導入でセッションが開始されたのを見てモニタの前で大はしゃぎしてしまった。
ところが中盤から大きく様子が変わる。
そう言えば以前のセッションでは自作のenumクラスでドメインを表現していた。php8.1からはそんな必要はなくなった。型を絞り込んだところでパラメータ順序は説明が必要だったがphp8.0では名前付き引数で事足りる。アサーションを駆使して存在し得ないオブジェクトを排除しようにもオブジェクトが可変であった時点でその前提は崩れる、が、php8.1からはreadonlyプロパティによりそれすら禁止できる。
6年前のセッションはパラダイムの紹介、今回のセッションはその実践編、そう自分は消化したのだが実質的には「実践 php-8.1」とも言える内容だった。6年間のphpの進化をダイジェストで見られたと同時に、t_wadaさん、生粋のPHPerというわけでもないはずなのに的確に新機能の使い所を的確にキャッチアップしており、この人は何者なんだろうと改めて感じてしまった。
大規模サービスのCakePHP2をCakePHP4にジャンプアップさせた話 @katsukii
CakePHPに限らずリプレイス全般で役立つ話だった。各フェーズで使われた技術面のテクニックも大いに参考になったが、それより以前の課題を把握し定量化していくプロセスが見事だった。
- 初期の検討時は、CakePHP以外のFWやそもそも別言語であるRailsも選択肢に入れ検討した。
- 本格開始の前にPoCを実施した。PoC終了までは本格開始の見積もりは実施しない。
- KPI設定しPoCを通じ計測、それに基づくリプレイスの見積もり。
- 試験的に実際のリプレイスを行ってみる。
- その際のステップ数や所要時間などを基に各所のパフォーマンスを測定。
- その結果に基づき本格開始の見積もりを作成。
マイグレーションはオフショアチームに委託しつつその間にも発生する旧システム上での運用や機能追加は国内のチームが担当、ハンドリングを誤ると混沌が訪れそうな進行だが、事前のPoCでのパフォーマンス測定に基づいて作られた計画に沿って進める前提であればむしろ効果的なやりかただと思う。参考にしたい。
計画の綿密さは本作業の開始後も徹底して行き届いていた。
- マイグレーション時に発生した問題点や知見は本開発のチームにも共有
- マイグレーション済箇所への機能追加や修正は本開発のチームが行うことになるため
- マイグレーション前のUnitTestはスプリント毎に全て移植する
リプレイス系のプロジェクトでよくあるジレンマとして、リプレイスそれ自体はビジネス的には（少なくとも直接の）価値を生まないため内部品質確保のための取り組みは二の次にされてしまうことが多い、というものがある。それらにもきちんと向き合った上でのプロジェクト、是非とも同じようなハンドリングを近い将来行ってみたい。
チームの仕事はまわっていたけど、メンバーはそれぞれモヤモヤを抱えていた話─40名の大規模開発チームで1on1ログを公開してみた @vaccho
エンジニアからキャリアパスをスタートし現在は組織マネジメントに尽力しているという方のセッション。
冒頭で 自分のことを話すよりも人の話を聞くほうが得意です と話されていた。セッション中の語り口や資料の表現など終始穏やかで、こんな上司の方に巡り会えた人は仕事がやりやすいんだろうなあ、と感じた。
穏やかな語り口とは裏腹に実際にやられたことはかなり凄まじい。
- 担当するチームは100名規模、1on1の相手は40名、1ヶ月かけて全員と1on1を実施。
- その後も継続的に、2回目、3回目、と1on1を繰り返していく。
- 議事録は画面共有を使いその場で書く。公開を望まない箇所や表現を変えて欲しい箇所はその場でフィードバックをもらう。
- そして1on1終了後1分を待たずに議事録を公開。
聞き役と言っても相手から話を引き出すにはそれなりのスキルが必要、それを駆使しながら上のようなことも行いそれを1ヶ月以上継続、なかなか出来ないと思う。実施にあたって本来は組織運営チームに所属しているが自ら担当チームにjoinしたとのことだ。頭が下がる。
前提のミッションとして、個別最適型だった組織を全体最適に切り替えるべく編成を変更というものがあったとのこと。各チームメンバーが自分の担当範囲だけでなく前工程や後工程を担う担当者がどのように作業しているかある程度把握することが前提だが、極めて自然な形でメンバーのモヤモヤ解決と同時に行ってしまうという魔法のような話だった。
メルカリ、巨大モノリスにおける複雑性をリリース9年目にしてどう解決するか @uadachi
実装よりも設計に回る機会が多い最近の自分にとって今まさに聞いておくべき内容ばかりだった。
まず「メルカリ」と「モノリス」という言葉の並びが意外だ。単なる先入観なのだが、メルカリと言えば考えに考え抜かれた設計でそれぞれの責務がきれいにマイクロサービス化された美しいシステムを想像してしまう。phpというイメージもあまりない。
セッションの冒頭で理由が語られたのだが、今回ターゲットとなっている「取引」ドメインは創業当初より使われているコードベースが未だ引き継がれており配送や決済など他のドメインとの連携箇所も非常に多く、それらが「境界のないモノリス」としてそびえ立っているとのこと。それらを2021年10月（半年前）に発足したチームが解体していく、気が遠くなりそうだ。
「エンドポイント輪読会」という試み（発想、名付け、双方の観点で巧いと感じた）によりドメイン知識をチーム内に集積。そこで至った方法論が モジュラモノリス だったとのことだが、それを選んだ理由を簡単に説明してくださった。
- 最も解決したい課題は、システムそのもののスケーラビリティ、ではない。
- 開発のスケーラビリティとコードベースのメンテナンス性が解決したい課題である。
なるほど非常に妥当な選択肢だと思う。
レガシーシステムは向き合えば向き合うほど隣の芝が青く見えてしまったり、それ故に巷で紹介されている何らかのパターンを銀の弾丸と勘違いし導入（そして失敗）してしまったり、そんなケースが非常に多いのだが、パターンを採用した理由をこれほど端的に説明できるこのチームは絶対にそんな失敗はしないのだろう。見習いたい。
続けて採られた方法論として、定義された境界が守られているかどうかを静的解析で可視化した点が紹介された。いくつかのOSSを組み合わせてツールを自作したとのこと。資料中 【完了】 依存関係の分析 / 定量化 の文字に重みと説得性が感じられる。
品質を向上させていく取り組みにおいてその進捗を可視化する重要性は特にテストの文脈などで多く語られる。これまで見てきた中で自分が印象に残っているリソースは次の2つだ。
- 1日10万枚の画像を検証するためにやったこと - Qiita @quramy
逆に、自分がPRを作る側になったときも、「テストコードを書く」という行為と「ビジュアルを確認する」という行為が密に連動するため、テストを書くことに対する心理的な障壁が格段に下がったと思っています。画面を用意しているうちにテストコードになっていた、的な感覚です(後述)。
- Testable Lambda: Working Effectively with Legacy Lambda @t_wada
現状確認のためのカバレッジ測定
テストという比較的低い粒度でよく聞いていた考え方だが、モノリス解体、リアーキテクチャ、こういった文脈においても有用なのだと感じた。
PHPで「時間がかかる処理」を並列でブン回す @kiridaruma
「時間がかかる」「ブン回す」とは一体どういうことだろう、と興味を抱きながら見始めた。
通常phpでの並列処理と言えば外部APIへのリクエストを並列化してレスポンスタイムを短縮する等のコンパクトなテクニックが一般的だ。「ブン回す」というイメージではない。聞き始めてみると答は簡単で、普段はスピーカーの方は普段インフラやDBを担当しているとのこと、なるほどバッチ処理や大規模データ処理の話だった。
この領域に入ってくるとWebアプリケーションの知識はあまり通用しなくなってくる。プロセスとスレッドの違い、プロセス間通信、シグナルとシグナルハンドラ、ある程度のOS知識が前提となる話題が多く個人的にとても面白かった。（Webアプリのみを本業としているPHPerの方には少しむずかしいかもしれない、とも思った）
並列化の話ではないしphpですらないのだが、以前WebSocketによるリアルタイム通信対戦サーバを実装したことがある。実装するところまでは簡単だが、いざ運用に入ってから大変苦労した。常時接続が前提のため新バージョンをデプロイしようにも、稼働中サーバは瞬断すら許されない。サービスを公開した後になってGraceful Restartの重要性を痛感したものの、既に立ち上がっているサーバにはそんな機能は実装されていないので netstat コマンドを連打して接続数がゼロになった瞬間を狙って別コンソールから再起動、などという運用をしばらくやっていた。Graceful Restartを実装できた時は便利さに涙した。
あれを実装する前にこのセッションと出会えていたとしたら、などということを考えてしまったが、過去に痛い思いをしたからこそセッションの内容が自分に刺さったという側面もあるかもしれない。何れにせよ、当時の苦労を通じ漠然としたイメージ認識していたベストプラクティスの数々が、網羅的かつ体系的にまとまっており、頭を整理できたセッションだった。
PHP流 quicktypeとの付き合いかた @yosatak
自分にとって馴染み深い話だった。似た実装を過去にやったことがある。同じ問題を解決するにも細かな実装のアプローチは人それぞれなのだなあ、という辺りも面白かった。
JSON SchemaやSwaggerでAPIを一括管理し実装に使う型情報は自動生成、これは今も昔も鉄板のようだ。同じく未だに解決していない問題として、バリデーションはなんとでもなるがphpだとエディタでの型補完がどうにもならない。少なくとも公式のやりかたは存在しない。
今回のセッションはPHPStanの型情報を生成するやり方。これでパラメータ名のtypoなどは根絶できるだろう。だが型補完はまだ効かない。そもそも公式のやり方が存在しないのだから当然なのだが、この分野にphp本体が何らか対応するタイミングこそ、phpの次のパラダイムシフトだと思っている。この分野は引き続きウォッチしたい。
