PHPer Kaigi 2025 に参加してきました

Last updated at 2025-03-25Posted at 2025-03-23

今年も福岡からPHPer kaigi 2025(https://phperkaigi.jp/2025/)
に参加しています。

会社から今年は私含め４人、参加することができました。
福岡からの旅費を出してくれた会社には感謝です。
朝5時起きしてせっかく来たからには何か吸収して帰らねばと思っています。

特に印象に残った発表について感想を書きます。

安全に倒し切るリリースをするために：15年来レガシーシステムのフルリプレイス挑戦記

システムの達成要件があり、
それに対して過去のいろいろな事例を調べてテスト手法を編み出し、
その実践的アプローチによって無事に障害無しでシステムリプレイスしたお話でした。

「ペンギンテスト」と名付けられたテスト手法によって、
本番稼働しながら、同時にリプレイスしたロジックも検証し、
発生しうる様々なパターンに新ロジックが対応できているかを検証する方法を発表されていました。

ペンギンテストはシャドーテストの一種とのことですが、
このような手法があるのを初めて知りました。

本番のコードの中の分岐によって新ロジックを実行
新ロジックの実行結果と旧ロジックの実行結果を比較
比較結果をログ出力
比較結果をアラート
新ロジックへの分岐の流し込み率の制御
- 徐々に割合を増やす
  - はじめは割合を抑える
- 時間帯で制御
  - すぐに対応できる時間帯にしか分岐を機能させない

このような現場の実践的なテスト方法が聞けるのは大変ありがたいことだなと感じましたし、
その貴重な経験を聞くことができて勉強になりました。

PHPでお金を扱う時、終わりのない謎の1円調査の旅にでなくて済む方法

大変わかりやすく、かつすぐに現場で活用できる発表でした。
お金の計算、小数点のある数値の計算をどのようにすべきか、
そして、それぞれの重要な値自体をどのように安全に取り扱うべきか、
というお話でした。

小数点を含む計算は、算術演算子を使うな、BCMath(任意精度演算)を使え
floatは使うな、PHPで小数点を扱う際はstringで保存
小数点がありえないものはintにしてしまう
php8.4からBCMath\Numberが使えるので使う
型で制約を掛けて間違いがないように

ここからさらに発展し、ValueObjectの話がありました。

ドメイン固有の型を作る
- ValueObjectを作る
振る舞いのカプセル化を行う
- 例：消費税計算メソッドは最終の値のValueObjectにし書かない、など

数値の扱いについては、こうやるべきだ、というセオリーを聞けました。
認識が曖昧だった部分についてはっきりと理解することができ、大変勉強になりました。

特にValueObjectの話は、
聞いていて早く自分のプロジェクトでも試したいとワクワクしました。
すぐに他のプロジェクトでも取り入れます。
ValueObject化について、どこまでやるのか？の塩梅にも言及されていて
聞いていて、心の中で「なるほど」を連発した発表でした。

PHPでアクターモデルを利用したSageパターンの実践法

レベルが高い話でした。
1週間ぐらい弟子入りしてずっと話を聞いていたいと思いました。

sagaパターンを初めて知りました。
サーガパターンと読みます。

一つにまとまったトランザクションのように扱うための分散トランザクションのお話でした。

他言語ではAkkaなどが有名らしいです。

基本的な概念は、「アクター」と呼ばれるオブジェクトがそれぞれステートフルに
自分自身の情報を持ち、なにかあると自分自身を再生成して元も状態に戻るようにする。
それを親子関係のある親オブジェクトや、他の監視オブジェクトが管理する。

みたいな感じでした。
全然深く理解していません　笑

ただ、こういった概念がある、ということと
それほど難しいことである、ということが実際にSagaパターンのことを聞きながら
体感できました。
マイクロサービスで整合性を保つにはやはり、ここまでしないといけないのか、
と感じました。

事実をイベントとして残す（スナップショットをとる）
コンシステートハッシュを使わないと分散システムでは使えない
- 例：銀行送金系の実践
  - 口座がリモートサービスとして動作する場合に起こり得る状態をすべて設計する
PHPはコレオグラフィー (次あなたやってください => 相手に対しての命令のみ実施）
- PHPはステートレス(DBなどに保存するしかない)
- どこまでやったか自分はわからない(DBなどに聞くしか無い)
- 難易度が高い => 複雑化する
  - アクターを使えばシンプルな概念として管理できる
オーケストレーションのsagaはプロセス監視をつける
- アクターはなにかおかしいことがあったら自身をダウンさせる
- 親がダウンすると子もすべてダウンする
- 元あった状態で再生成
PHPではPhluxor(フラクサー）を使う
- phluxor: https://phluxor.github.io/
- ytakeさんが作ったサンプル(https://github.com/ytake/phluxor-saga-example/)

大変勉強になりました。
https://phluxor.github.io/ja/guide/
こちらのページに詳しく説明が書いてあったので読みふけります。
勉強のため、というより、こういうあたらしい概念（知恵）は本当に刺激的です。
楽しいです。

レガシーシステムのリプレイスを安全に完了させ、高い生産性とモダン環境を獲得するまで

仕様書が残っていない10年以上たったシステムのリプレイスの話でした。
すべてをまず仕様として記述し、「正解」を定義するという話。
正解を作る作業は、途中でたとえリプレイスの話が無くなったとしても無駄にはならない、
というリスクヘッジはなるほどと思いました。
正解を作る過程自体が、システム自体の再理解に繋がりリプレイス作業もスムーズに進みそうと思いました。

範囲を減らしリスクを減らす
- マイクロサービスとして切り出せる部分は先に切り出す
- DBを変更しない
先に旧システムでマジックナンバーを定数に置き換える
- 新システムで同じ名前のEnumに変更する => 同じ意味合いをもたせる
技術の選定
- Inertia.js => js側の記述を減らす
- Lefthook
長く続けられるシステムにする
-　共通化を減らすことで捨てやすくしている
DBを変えていないので、新システム・旧システム両方が使える。
- 機能によっては旧版を使ってもらうことも可能
設計書を作るときはReactのcomponentも設計してしまう

こちらも大変勉強になりました。
リプレイス、リニューアルする場合はいかに範囲を減らしてリスクを抑えるか、
という観点、旧版の設計書を作りそれを新システム制作に活かすというところは特に
納得しました。

移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略

こちらもシステムリプレイスの話。
旧システムを「葬る」ために、どのようなムーブをすべきか、
どのような戦略を立てて、どのようにまずは旧システムを調べるかの話でした。

旧システムで仕様がわからないときはOpenTelemetryを使う
- URLと、どういうSQLが発行されているか
- ログからDBのinsertなど主要なイベントを見ることで旧システムの仕様を理解する
OpenTelemetryをJAEGERに流す
スケジュールを立てることが何より大事
仕様書(WBS)を作り、それを元に進捗報告する
仕様がわからないものに関しては過去のチャットなどを機能名などで検索してキーマンを特定する

OpenTelemetryを使い旧システムの機能の根幹を特定したり、
旧システムの機能を把握するために、チャットでキーマンを探すなど、
知恵を使うことが大事だなと聞いてて思いました。
大変勉強になりました。

まとめ

PHPer kaigi 2025、単純に楽しかったです！
ここに書いていない発表に関しても学びが多く、自分である程度わかっている、ということでも
改めて発表を聞いて気付かされることが多々ありました。

うちの会社のメンバーもそれぞれ、私とは別の発表を聞いて感銘をうけたようなので、
聞けていない発表に関して追って勉強しようと思いました。

旅費を出してくれた会社、一緒に来てくれた仲間、貴重な発表をしてくださった発表者の方々、
PHPer kaigiを開催してくれた方々みんなに感謝します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

PHPer Kaigi 2025 に 参加してきました