ここでは主に聴講した内容について書きたいと思います。自分の登壇については、別途お仕事のブログで記事にする予定です。追々聞いてくださった方々が気になっているであろう内容も投稿できればと考えています。順次記事ができ次第 X で共有します。
全体を通して
具体と抽象の話や SOLID 原則の話が多く、偶然にも自分の今の興味関心とほぼほぼ一致していました。そのため、聞いていて非常に面白い話が多く、ask the speaker で色々お話したいと思ったものの、初カンファレンスなので、みなさんがどんなふうに発表するか雰囲気を味わう方を優先しました。気になった点はここに残しつつ、あとでスライドを見ながらふりかえってみようと思います。
人見知りマンなので、アンチボッチランチは非常に助かりました。地元メンバーが集まっているグループに入れていただいて、名古屋の Web 開発事情やら週休4日の話やら面白い話を聞くことができて楽しいひとときでした。
懇親会の大勢の人に驚くとともに、PHPer の熱を覚えました。勝手にカンファレンスは学会のようなものかと思っていたのですが、全く違いました笑 今後自分もこのコミュニティの輪の中に入っていきたいと感じたので、積極的にカンファレンスに関わっていければと思います。
運営の皆様、大変お疲れ様でした。さまざまな場面で気配り・心配りが感じられ温かいカンファレンスでした。とても楽しませていただき、感謝しております。ありがとうございました！名古屋は美味しいご飯が多過ぎて、まだまだ食べたいものが食べ切れていないので、次回の開催を期待しております。
聴講したセッションについて
抽象化をするということ - 具体と抽象の往復を身につける
細谷 功さんの『「具体⇄抽象」トレーニング』をベースに、我々の仕事と切っても切り離せない具体化と抽象化を鍛えましょうというお話。今回のカンファレンスはつながっている話題が多く、「これ進研ゼミでやったところだ！」現象を感じた方は多いはず。そんな中、偶然にも前日の飛行機内で『「具体⇄抽象」トレーニング』を読んでおり、ちょうど『上司の指示と部下の期待の4つのパターン』部分に目を通していたため、最初のセッションから「これ進研ゼミでやったところだ！」現象が発生したのはレアな存在だったのではないでしょうか。読んでいた内容をふりかえりつつ、ソフトウェア開発への展開の一考も聞けて非常に有意義でした。本誌で出てきたときから推していた、ワートリ28巻のヒュース先生の努力の話が発表準備で聞けなかったのが悔やまれるところです。
ふりかえりで作る 目標達成への道しるべ
目標達成に向けたふりかえり手法の話。目標管理に苦手意識があるのでセッションを聞いてみました。記憶の多重貯蔵モデルが出てきて、忘却曲線のタイミングでふりかえりを行うということや、ふりかえりに日記が効果的で、日記を思い出す作業を毎週行うというのが印象的でした。学習では忘却曲線を意識したことはありましたが、ふりかえりでは全く意識したことがなかったので新鮮でした。GPS（Goal、Path、Shift）のオリジナルふりかえり手法も目的の達成までを的確に捉えた手法で良さそうに思いました。ふりかえりをより有効活用できる可能性を感じたセッションでした。
責務と認知負荷を整える!抽象レベルを意識した関心の分離
抽象の具体的なコードのお話。コードの抽象レベルが低いことによる意訳コスト・脳のメモリ圧迫はめちゃくちゃ共感できました。これらが原因でコードリーディングが進まないと感じることが多いかもしれません。コードの抽象レベルを整える3つのアプローチとして、クラス化・関数化・コメント追加が上げられていました。これを書きながら、「あと説明変数化もあるかも…」と、ふと思いました。いずれにせよまずは抽象的に表し、その先で具体的に実装するのが良いという理解です。意識していかないと、書くのが楽な方に流れてしまいがちなので気をつけたいです。
『テスト書いた方が開発が早いじゃん』を解き明かす
「テスト書く時間がないです」vs「テスト書いたほうが早いじゃん」のお話。個人的には埋まらない溝かなーと思っていたところで、ギャップを解き明かすとのことでどんな要素が出てくるかワクワクしていました。テストで機械が得意な部分を有効活用し、人間の不得意な部分を補うことで追加工数以上の効率が得られることが「テスト書いたほうが早い」の背景というのが納得でした。発表でスキップされていた assert によるテストや素朴なテスト、学習用テストなどは活用できそうなので、今後取り入れていきたいです。
設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何？いつどう向き合ったらいいの？を考えてみる
Clean Architecture もつい最近読み終わったばかりだったので、読んで理解した内容があっているか答え合わせしつつ、次に向けたヒントを得ようと聴講しました。原則やアーキテクチャパターン、アーキテクチャスタイルの理解は大体あっていそうという感覚を掴みつつ、次に学んだ内容を「どう扱うか」というところで、考え方のヒントをもらえた気がします。まずは設計原則を日常の業務内で活用し、中長期的な目線でアーキテクチャパターン・アーキテクチャスタイルについても考えていければと思います。「はじめての PHP エンジニア入門編」読んでみます！
クリーンアーキテクチャから見る依存の向きの大切さ
こちらも Clean Architecture を読んだ後ということで興味深く聴講させていただきました。Clean Architecture で必ずしも4層である必要はないと書かれているところから、エンジニアドーナツ（初めて聞いた）がシステムの柔軟性と保守性の向上につながるというのは理解がしっかりあっていて安心しました。
依存の向きについて、Clean Architecture を読んでいて疑問に思ったのが、
変わるものは外側に置く
フレームワークは一番外側
というところでした。
破壊的変更を行う PHP は、それ自体が「変わるもの」になりえるのではないか
Laravel のようなフレームワークを一番外側に置くにはどうしたらいいだろうか
という疑問があり、話を伺ってみたいと思ったのですが聴講を優先してしまったので、またの機会にぜひお話させていただきたいです。
もう一度やり直せるならこうする：テックリードの経験から学んだ設計の教訓
実際のご自身の経験を元にやり直せるならどうするか、ドキュメント設計・テスト戦略・移行戦略の点でふりかえったお話。経験を元にしたお話なので、一つ一つの言葉が重く、大変有益なセッションでした。ドキュメント設計で出てきた ADR については、弊社でも導入しており、最近書く機会も増えてきているので引き続き取り組んでいこうと改めて感じました。テスト設計については、カバレッジの部分が興味深く、カバレッジの値は役に立つ場面もあるが定量的な値としては信頼度が低いと感じていたところがありました。しかし、Google の Code Coverage Best Practices で理想的な数値は無いとしつつ、一定のレベルを提示していたことを知り、このような表現であれば参考値としてうまく運用していける気がしました。最後のストラングラーパターンについては残念ながら時間切れとなってしまいましたが、最後までお伺いしたかったです。パターンそのものは知ってはいるものの、具体的にどのように進めればいいのかの事例をしっかりと理解しておきたかったです。追ってスライドを見てイメージを膨らませたいと思います。
仕様変更に耐えるための"今の"DRY原則を考える
「DRY や単一責任の原則って難しいよな…」と感じることが多くなってきている今日このごろ。具体的な DRY にすべきかどうかというケーススタディで考えさせられました。自社でコントロールできない部分を切り離すというのは自分も一つの方針として持っているものだったので、同じ考えが聞けて安心しました。『この世で変わらないのは、「変わり続ける」ということだけ』という言葉もあるので、「変化に耐える・耐えない」から更に一歩踏み込んで「変化に対応しやすい・対応しにくい」を考えると、より幸せになれそうな気がしました。DRY・単一責任の原則は本当に難しい。
PHPのバージョンアップ時にも役立ったAST
AST が変わっていないことを根拠に、バージョンアップ対応が安全に行われていることを保障するというお話。「AST が変わらなければ挙動が変わらない」ということをバージョンアップに活用できるよね？ということは聞いたことはあったものの「バージョンアップ対応って挙動が変わるから対応しないといけないのでは…？」と思っていました。今回のセッションを聞くことで「あっ、こういうケースで活用できるのか！」と気付かされました。Phan と php-ast の使い分けのところが理解できておらず気になっているので、スライドでふりかえってみたいと思います。
PHP 製 OSS のメモリ問題を辻斬りしていく
話が上手でめっちゃ面白かったです！自分が出会った OOM は ini_set でいつの間にかメモリ上限が書き換えられているというものだったのですが、記憶が蘇りました。自作ツールを各種 OSS で試し切りしていくという試みがおもしろく、なにか作ったらやってみようと思いました。20GB のメモリ使用を32 MB まで落としたのすごい笑
RemoveだらけのPHPUnit 12に備えよう
大変だろうな…と思っていた PHPUnit のバージョンアップの話。設計を見直す必要があるものまであるとは驚きでした。基本的にはPHP標準関数を使うか、決められたものに倣うで事足りそうな気がするのですが、来たるべきときにこの資料を進めるヒントにできればと思います。感謝！
プロダクトコードの複雑さを計測せよ〜5分ではじめるPhpMetrics活用リファクタリング〜
PhpMetrics を使ってリファクタリング対象を設定して実際にリファクタリングした話。コマンド2回打つだけで結構な情報量のレポートを作ってくれることに驚きました。メトリクスの計算式の立て方とか興味があるのでドキュメント読んでみたいと思います（難しそう…）。対象を決めるのも、効果を見るのも定量的に確認できるのは嬉しいですね。試しに使ってみます！
MAKE "PHPer REACHABLE COMMUNITY" GREAT NOW
地方で勉強会を継続開催するためのお話。秋田で勉強会を探してみたものの見つからなかった気がします。会場をおさえる、0人開催でもやめない、コミュニティとは根気がモノを言う世界なのだなぁと感心しました。『よい「場」の10条件』は勉強会に限った話ではないと思うので、いつか活かせるよう覚えておきたいと思います。
消したはずのファイルが生き残っている！？PHPのファイル操作の落とし穴
消したはずのファイルが参照されて本番でアラートが発生したお話。蓋を開けてみると realpath がキャッシュしていたとのこと。元々ディレクトリトラバーサルのための realpath だったらしく、今回は file_exists を使っていれば問題なかったようで「これもひとつの DRY や単一責任の原則だろうか…」とか考えてしまいました。ただ、file_exists にも別のキャッシュがあるとのことで、PHP がキャッシュするものをリストアップしてみたいと思いました。
5分で理解する SOLID 原則
SOLID 原則を正しい理解と間違った理解を両方並べて説明してくれているお話。個人的には正しい理解だけを並べられても理解が追いついていなかった部分があったので、今回の LT を聞いて理解を深めることができました。「さいごに」の最後の一文が心に残っていて判断をするために理解が大事はまさしくそうで、まだまだ理解するために調べたり考えたりしないといけないと感じました。他のセッションのふりかえりで書いているように、まだ悩む部分も多いので…
「何か」を求めて参加したカンファレンスから持ち帰ってきた「熱」を維持して、活用するために
カンファレンスで得たものをどうするかというお話。トラブルに見舞われながらも最後までやり抜く熱に感化されました。次に向けてどうするか、早速帰ったら熱冷めぬうちに考えてみたいと思います。ひとまず、結構な空腹に襲われているのですが、熱を維持するためにこの記事を書き切ります。
まとめ
こうやってふりかえってみると、改めて得るものが多いカンファレンス初参加だったと感じています。懇親会の LT でも要求モデリングや帰納法・演繹法といった興味あるワードが聞けたり、最初から最後まで本当に充実した会でした。
また別のカンファレンスにも参加できればと思うので、どこかでお会いしたときはよろしくお願いいたします！
重ねてになりますが、運営の皆様ありがとうございました！！