プロポーザル

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を予定していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩: Agent Skills という光
• まとめ

弊社サービスの検索機能は、検索基盤にAWS OpenSearch Service を利用しており、数百万件規模のデータに対して毎分数千件の検索リクエストが発生します。
現行バージョンのEOL見込みにより移行が必要でしたが、サービス停止時の影響が大きく、アプリケーション側の修正も伴うため低リスクで進める必要がありました。

このトークでは、新クラスターの並走や段階的リリースを活用して安全に切り替え、異常時には即時ロールバックを可能にする手法を解説します。
加えて、 移行する中で顕在化した切替点が分散した設計を、Factory Patternや静的解析などを利用して改善した事例についても紹介します。

Goal

• 本番環境にある検索基盤を低リスクに切り替える
• 切替点を集約し、次回の移行を楽にする設計の型を持ち帰る

  Non-Goal

• OpenSearchの機能深掘り

Vitestでコンポーネントなどに対してテストを書く際に初学者が躓きやすいAPI通信のモックについて、主要なパターンを3つ紹介します。各パターンのメリット、デメリットを考察し、リファクタリング耐性などの観点についても話します。
また、現在私がVitestにPull Requestを出しているVitest標準のAPIモック機能について、どのような仕組みで実装したのかなどを紹介し、将来デファクトになるかもしれない未来について思いを馳せたいと思います。

再利用性の高いコードを書きたいと考えた結果、
いつの間にか責務が肥大化した「神クラス」を作ってしまった経験はないでしょうか。

多くの場合、その背景には「さまざまなケースに対応できる1つのコード」を作ろうとする考え方があります。
しかし、世の中で再利用されているモノほど小さな目的に特化して作られているという特徴があります。

本セッションでは、
具体的な実装手法や設計パターンを紹介するのではなく、
世の中で再利用されているモノと「神クラス」の違いに着目しながら
「再利用性とは何か」を考え直すことを目的としたセッションです

テストコードを書いていれば安心、そう思っていませんか？
プロダクトコードに明らかなバグがあるにもかかわらず、テストが成功を表示し続けることがあります。
これらは開発体験のお邪魔虫に違いないのですが...意図せずこれらを生み出しているかもしれません。
そう、わたしのように...。

このセッションでは「実際の失敗例」を通じてなぜそれが生まれるのか、そしてどうやったらそれが生まれないのかを話します。
昨今ではAIを使ってテストコードを生成することもあるため、生成させるときにどのような点を気に掛ければ良いかについても触れていきます。

テストを書きやすく、かつ壊れやすく（＝正しく失敗するように）するための「テストコードの設計」を追求しましょう!!

話すこと

• わたしの失敗例たち＆どうすればよかったか
• 偽陽性・偽陰性を防ぐテストコード設計
• 良いテストコードを書いてもらうためのAI活用法

ajthinking/archetype というライブラリがあります。
何を持たらすのか？というと、「プログラミングでソースコードを書く」体験です。

PHPのフルスタックFWには、「ボイラープレートベースで、よく使うモジュールのコードを書く」仕組みが備わっている物もあります。
一方、archtypeは、より柔軟かつ詳細な「ソースコードを自動で生み出す」パワーをもらたします。

その裏側にあるのは、「ASTを使い、ソースコードを抽象に扱い生成する」というコンセプト。
単なるテキストベースの雛形を超え、「プログラミングの意味(文法)的に正しい」コード生成をもたらします。

このトークは、「ASTって何？」というメインターゲットを想定し、
「それがどんな物で何を実現するのか」を体感できる15分間にします。