プロポーザル

基本的な情報

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

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

お品書き

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

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

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

Goal

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

  Non-Goal

• OpenSearchの機能深掘り

現代のソフトウェア開発者で「技術的負債」という言葉を知らない方はほとんどいないでしょう。一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くありません。相手が非エンジニアであればなおさらです。

技術的負債についての理解が不十分なことから「技術的負債＝悪」というイメージを持ち、無謀なリファクタリングを行う例や、逆に放置しすぎてビジネス面でのリスクが顕在化してしまう例は今なお後を絶ちません。

PHPはその長い歴史から、フロントエンドは流行の移り変わりの速さから技術的負債とは切っても切れない関係にあります。本トークでは「技術的負債とは何か」を言語化した上で、バックエンド・フロントエンドの両方に深く関わってきた経験、さらにAIによって大きく変わりつつある現代の開発環境を踏まえつつ、双方に共通する技術的負債との向き合い方や付き合い方をお伝えします。

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

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

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

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

ifを減らしたい、複雑さを抑えたい、オープン・クローズドの原則に沿った変更に強いコードを書きたい。
しかし「どう設計すれば良いか分からない」と感じたことはないでしょうか。
本セッションはそんなエンジニアに向けた内容です。

分岐が多く保守が辛いコードの多くは、
複雑なロジックを「使う」側で分岐させていることが原因だと考えています。
この設計では機能追加や変更のたびにifが増え、
可読性が低く、テストが辛い、変更に弱いコードになってしまいます。

本セッションでは、
複雑なロジックを「使う」側で分岐するとなぜ辛くなるのか、
「どう使うか」ではなく「どう作るか」で分岐すると、設計がどう変わるのかを整理して解説します。

その上で、「作る」と「使う」を分けることで複雑さを適切な場所に閉じ込め、
オープン・クローズドの原則に沿った変更に強いコードにつながる理由を実践的な題材を通して説明します。

TypeScriptなどを用いた開発の中で、「美しく、保守性の高いコードとは何か」を模索している方は多いのではないでしょうか。
私は業務で先輩エンジニアからコードレビューを受ける中で、その「美しさ」の源泉が関数型プログラミングの考え方に深く根ざしているかもしれない、というお話を聴く機会がありました。「なぜイミュータブルであることが重要なのか」「なぜ関数を最小化すべきなのか」を、概念としてだけでなく「言語仕様レベルで強制される環境」で肌感覚として理解したいと考え、 F#の学習を始めました。
本セッションでは、F#を学ぶことで意識するようになった「所作」や、関数型の思考がなぜ多言語の品質向上に結びつくのかについて吟味し、「綺麗なコードを書きたいけれど、何から学べばいいかわからない」という悩みに対する一つの指針として「他言語学習」の価値と、そこから得られる視点の変化をお伝えできればと思います。

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

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

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

話すこと

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

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

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

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

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

必ず盛り上げます！！！よろしくお願いします！！！