また技術キャッチアップ用のプロジェクト作りました。今回使いたかったのは以下の4つ:
- spring-boot v2.0（リリース前）
- spring-webflux v5.0（リリース前）
- selenide v4.5
- checker framework v2.2
Springは5.0リリース前にマイルストーン版を使って感覚を見たかったため、特にreactorとRxJavaの違いを確認したかったため。 selenideはユースケースを見たことが無かったのでなんの役に立つのか肌感覚を持つため。 checker frameworkは公式ドキュメントに色々不明点がある*1ので、（今までやってきたライブラリやCLIツールではなく）自走するウェブアプリで色々確かめたかったためです。
以下所感をまとめておきます。
reactorによるウェブアプリ実装について
vert.xでも感じたことですが、reactive-streamsを使ってのウェブアプリ実装は十分に可能なものの、どの程度ペイするのかよく分からないというのが実情です。 外部サーバとのI/Oが処理のほとんどとなりやすいウェブアプリにおいて非同期I/Oを短く簡潔に扱えるというのは利点ですが、リアクティブに処理を書く必要性・Backpressureの利点をきちんと享受したいケースがどの程度あるかというと疑問という感じでしょうか。 これについてはそれなりの負荷がかかるサービスで比較検証する必要がありそうです。ab等を使った負荷検証をしてみます。
また静的解析ツールの支援を受けられないのはなかなかつらいなと思いました。
subscribe()時に正常系のconsumerだけ設定したためにエラーに気づけなかったケースとか、Mono.create()とMono.from()の違いを知らずonNext signalを掴み損ねたケースとか、習熟すればすぐに見つけられるがそうじゃないとかなり厳しい「書き方の問題」が多数ありました。年月が解決する問題ではありますが、現時点では業務用途はだいぶきつい印象です。
selenideでできることはコード短縮だけでないという話
Selenideを使ってみて「あれこれって大してコード量減らないのでは……？」と思ったのでつぶやいた結果、公式アカウントに突っ込まれました。
Less code is better. BUT Selenide not only saves your code, it also saves your time - because it solves most of timing issues automatically.
— selenide (@jselenide) July 10, 2017
ブラウザのレンダリングを待つようなコードをいちいち埋めないでいいというのは、確かに大きな利点です。特にSeleniumを使ったテストの経験が浅い開発者は、気軽に Thread.sleep(long) してしまいテストを遅くする傾向にあります。コードレビューで指摘し育てるのも手ですが、Selenideのようなソリューションで統一的に解決してしまうのは手でしょう。
ただリダイレクト周りの検証とか、いまいち書き方がわからずWebDriverを直接叩くケースはまだまだありそうな感じでした。これだけ知っていればSeleniumについて気にしないで良い、というモノでは無さそうです。
checker framework
ちょっとまだfalse-positiveや価値の低い解析結果が多い印象です。Java標準APIはデータベースが整ってきているようですが、ライブラリ側（今回で言えばreactor含むSpring Framework）のデータベースが無いため、Nullableを許容するAPIでも「ここはNonnullだから！null渡さないで！」とコンパイルエラーになることが多いです。結局SuppressWarningをつけて回避しています。
彼らが配布するQualifierの認知度が上がり利用されるようにならないと、まだ積極的な導入は難しそうという印象を持ちました。
*1:サンプルプロジェクトがcompileOnlyではなくcompileでchecker frameworkに依存してるのはなぜ？等
