JJUG CCC 2024 Fallに参加してきました。最初の10時からの枠で登壇し、そこから懇親会までフル参加してきました。フル参加は初めてでした。学びが深かったので記録を残しておきます。
登壇は2回目でした。前回の登壇についてはこちらに書いています。
Javaエンジニアのための低コストKotlin入門
私のセッションです。もともとは45分枠でCfPを出していてもうちょっと深いところまで立ち入るつもりだったのですが、20分枠にすることを条件とした採択となり、内容を大幅に削って今回のような形に落ち着きました。本当にこの内容でいいのか迷って発表前日にちょっと大きめの変更を加えたりしていましたが、最終的にはそれっぽくまとまった（たぶん）ので良かったです。
ざっと見た感じ、20名ほどの方に聴いていただきました。本当にありがとうございます。
SpringBoot x Mybatis x TestContainerでSQLテストを行う
NewSQLという言葉を知りませんでした。勉強不足です。
TestContainerというのが気になってこのセッションを聴いたのですが、このTestContainerは他の複数のセッションでも登場した頻出ワードでした。ぜひ試してみたいところ。
オニオンアーキテクチャで実現した本質課題を解決するインフラ移行の実例
パフォーマンス悪化に対処するための大きな改修について、もともとオニオンアーキテクチャを採用していたおかげで非本質の改修にかかる時間を最小化できたという事例の話ですね。
お恥ずかしながらオニオンアーキテクチャについて十分に理解していなかったので勉強になったのと、実際にそれで成功したという事例を知ることでオニオンアーキテクチャの重要性を再確認できたのもよかったです。
本当に解決したい課題に時間をかけるために非本質の改修の時間を最小限にしたい、という考え方は重要ですね。
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
前のセッションは株式会社ログラスの方のセッションだったのですが、こちらも同じ会社の方のセッションでした。
開発プロジェクトへの新規参入者のキャッチアップにかかる時間を短くすることについて、かなりの部分で組織が支援することができるという内容と理解しました。
リファクタリング当たり前の文化、保守対応を溜めずに対応していく組織文化、良い設計やコードやドキュメントを維持することを良しとする組織文化…
非常に強い組織文化が醸成されていたことで非常にうまく回っている成功事例の話だったと思います。既に混沌としてしまっている組織に対してどうやって同様の組織文化を醸成したらいいのだろうと考えてしまうところですが、極めて理想的な事例だとどうなるのかを知れたのは非常に大きな学びでした。
お昼休み
ランチセッションを聞こうかとも思ったのですが、弁当がなくなっていたので泣く泣く撤退。午後に備えてラーメンを啜りました。
テストが正しいかテストする？Mutation Testing入門！
ミューテーションテストという概念自体を知らなかったので、また一つ知見を得られました。テストが失敗するのか確認するのは手動ではやることが多いですが、自動的にやってくれるフレームワークもあるのですね。
Pitestのためのコードを書くわけではなく、既存のテストに対してやってくれるのであれば導入の敷居も低くてよさそう。ただ、セッションでも触れられていた通りでただ導入するだけではレポートが無視されるだけなので、運用面での難しさはありそうです。Pitestでの実行はそんなに遅くはないとのことですがそれでもそこそこ時間はかかると思ったので、実行時間増に見合うだけの成果を得られるのかは要検証というところですね。
（余談ですが、ミュータント・タートルズは知ってます）
プロダクトが変われば、テストも変わる。テストピラミッドの再構築
単体テストの考え方/使い方という本に沿ったテストコード改善の話でした。単体テストの考え方/使い方は本当に名著ですよね。
全レイヤーを通過する統合テストをメインにしていたのでテストに時間がかかるなどの課題を抱えていた、というところから始まるのですが私が関わっているプロジェクトでもそんな感じなのでとてもわかりみが深いです…
印象に残ったのはまず輪読会を行なってチーム内で共通認識を作ったという話ですね。私は個人的に単体テストの考え方/使い方を読んで自分なりにあれこれやろうと思ったのですが、これは自分だけ思っても意味ないなと感じました。考えてみたらそりゃそうだという話かもしれませんが。
それと、レイヤーごとにテストサイズそ考えて対応していったという話ですが、これは適切なレイヤー分割は既になされていたので比較的スムーズに対処できたという話でもあると思いました。やっぱりレイヤー分けは重要…
Java 21とSpring Boot 3.2を採用して新規事業を開発した話
掲題通りの内容で、こういう実例を知れるのはカンファレンスの醍醐味ですね。専門家が作った巨大な保険のシミュレーションシートをそのままモデル化して実装とか、保険の用語が難しすぎたので一旦日本語のまま表現してコミットしたみたいな話が、なんというか生々しくて良いなと思いました。
map関数の内部実装から探るJVM言語のコレクション: Scala, Kotlin, Clojureコレクションの基本的な設計を理解しよう
言語ごとに比較する余地があるほど違いがあるのかな？と気になって聴いてみることに。
私は普段Kotlinを使っているのでKotlinでの内部実装については概ね知っていましたが、ScalaやClojureではまた全然違う実装となっているようで少し驚きました。まあKotlinがそれだけJavaに寄り添っているということなんでしょうね。
あとは、Scalaはかなり関数型っぽさがありますが内部的にはゴリゴリに手続き型で実装されているというのはなかなか興味深い話です。関数型というのは理論的な要素が大きくて、性能も考慮した現実的な実装としてはそうならざるを得ないのかなあ。
個人的には、昔はbetter JavaとしてScalaを学ぼうとしていた事がありましたが、思ったより関数型っぽさが強くて挫折したことがあったことを思い出しました。Kotlinは非常に気にっているのですが、それは私の関数型プログラミングについて全然理解していないからでもあるのかなあ。これは余談ですが。
Clojureも試したいですが、今試しても即挫折する気がする…
最近のSpring Bootの便利機能を復習！
Spring Bootはサポート期間の関係上バージョンアップはしているのですが、新たに入った機能を活用といったことは全然していないので気になりました。
主に3つの機能が紹介されていました。Service Connection、CDSはぜひ試したいですね。業務で今のプロジェクトだとDBはDocker Composeでやっていますが、プライベートなどで別途試す時などはService Connectionを使ったほうが楽そう。
CDSで起動が早くなれば、SpringBootTestでテストを動かすのもかなり速くなったりしないだろうか。いやまあそもそもSpringBootTestを使わないテストの割合を増やせというまた別の話にはなりますが。
懇親会
現状コミュニティ内に知り合いがほぼいない状態なので孤立すると思ったのですが、数名の方と話せて事なきを得ました。ありがとうございます。
感想
とても濃厚でよかったのですが、一番の感想は「もっと知り合いを増やしたい」でした。今後もできれば登壇して、懇親会ではもっと頑張って話しかけていきたいところです。コミュニケーション能力を研くぞ。
あとはDDDであったり、レイヤードアーキテクチャであったり、オニオンアーキテクチャであったり、そういうところは間違いなくちゃんと勉強すべきだと思いました。テストの書き方にも影響するし、大きな改修をする際にも大きな影響があります。開発プロジェクトは持続可能でなければならないのに、そのための努力が自分には足りないなあと。
自分で勉強しつつ、人との交流も増やしつつ、もっと頑張ります。
