VueからReactへの移行の理由づけと技術選定の考え方

paizaではかつてVueをベースにリアクティブなページを構成していましたが、2022年2月頃Reactにすべて移行しました。
すでに語るべき適切な時期を逃しているわけですが、このような話は意思決定をどのように行ったかの1つの事例になります。
これは技術選定に関する回顧録と、不確実性との向き合い方についての1つの記録です。

Vue2と格闘する

私がpaizaに入社したタイミングで、いくつかの主要ページがVue2で実装されていました。
実装者はすでに退職していたらしく、逆にVueのことを自分で調査しながら改修、機能拡張を進められました。
その時の課題感として以下のようなものがありました。

• Vueではやってはいけないとされていること(たとえばオブジェクトのプロパティへの直接代入)をやっても、動いてしまう
• v-model
  • modelがオブジェクトの場合、どう書くべきか
  • DOMのタイプによって対応するイベントリスナが変わる
• v-html
  • XSSを引き起こせる機能にしては名前が軽い
  • これを安易に使ってはいけないと言って回る必要がある
• watchという機能
  • 宣言的データフローという概念を根本から無視しても実装できてしまう
  • watchが使われた実装を宣言的に書き直すのはかなり難しい
• 当時TypeScriptをまだ利用していなかった
  • 複数ページで利用されるコンポーネントのインタフェースをどのように表現すべきかがわからなかった
    • storeパターンを独自に解釈した方法で実装自体はできたがいつ負債化してもおかしくなかった

しばらくして複雑な実装も書けるようになりましたがそれでも「こうすべきなのか、こうしてよいのか」といったことが頭によぎっていました。
プラクティスを言語化しようにも難しく、逆にしてはいけないことをいちいち言って回ることに私は億劫でした。

Composition APIでの再実装

しばらくするとVue3が話題となり、Vue2でもComposition APIが利用可能になりました。
Composition APIについては、Option APIよりもコンポーネント抽象化の文脈において優れているのではないかと感じていました。
ただrefとreactiveというリアクティブ変数を定義するAPIが2つあり、どちらを使うべきなのかが新たな課題として出てきました。 とりあえずrefだけで実装を完結できると確認できたので、それでよいと結論づけました。
一方でscriptタグ内では.valueが必要なのにtemplateタグ内では.valueが不要になるなどの振る舞いが逆にネックだと感じていました。
そして最も課題感が強かったのは周辺ライブラリのAPIがVue3対応にともない大きく変動したことです。
これがReactへの移行判断をする上でのほぼ決め手でした。移行コストというエネルギーがなければ、paizaはVue3を現在使用していたでしょう。

React Hooksのテスト

Composition APIへの書き換えを進めると同時に、個人的にReact Hooksを試験しはじめました。
関数型プログラミングにシンパシーを感じていた私としては、こちらのほうが簡潔に動作原理を説明可能であると理解しました。
適切なコンポーネントレイヤでリアクティブ変数を宣言し、変数やsetterあるいはコールバックをただpropsとして渡せばとりあえず実装として成立する。
その単純な原理だけを記憶しておけば、リファクタリングを進めることも複雑なインタラクションを構成することにも集中できます。
またJavaScriptの意味論を深く理解することがReact実装にも有益であり、それにフォーカスできる方がメンバーの長期的利益にもかなうと感じていました。

React Hooksに移行した

開発リソースに余力ができたタイミングをはかり、テックリードやVPoEの理解のもと、チームで移行作業を進めました。
React Hooksに移行したほうが、paizaのチーム開発の文脈においては適切だと判断したということです。
似て非なるライブラリを入れ替えるのは難しかったですが、一方でReact実装の知見をチームに共有する良い機会にもなりました。

技術選定の難しさ

ライブラリ間の移行作業というのは、手間とコストでしかないのでやらずに済むなら明らかにそれがよいでしょう。
一方で(サンクコスト)バイアスにとらわれると、中長期的に難しい問題を抱えることもあります。
トレンドやベストプラクティスも自分たちの文脈で翻訳する必要があり、それを怠ればあまりにも簡単に技術的負債を抱えることになります。

間違えにくい技術選定

技術選定について客観的な方法はないと筆者は考えています。
何を目的とするかは、個人や組織によって多種多様でどのような尺度で何を調達するかは基本的に自由だからです。
ヒトは誤るものだとすれば、技術選定に失敗しても軌道修正すればOKと考えたほうが健全でしょう。ただ誤りからどれだけ学習できるかも属人的で、左に傾いた柱を次は右に傾かせることはあまりにも簡単です。
役に立つかはわかりませんが、誤りがおよそ認められない世界で働いていたときに私が学んだことは以下のようなことです。

• それを選択する利益とそれに内在する不確実性を検討し、端的に言語化する
  • 「この案を選ぶと強度は満足するが、意匠が不格好だ」
  • 「この案を選ぶと強度は大きく向上するか、工程が複雑化する」
• 複数案を比較検討する
  • VueだけでなくReactも試してみる
  • RubyだけでなくRustも試してみる
  • 2つの差が極端であるほど両方の限界特性を深く理解できる
    • 英語を学ぶことではじめて日本語を客観的、相対的に捉えられるようになるのと同じです
    • prosとconsを明確に言語化する上で役に立ちます
• 意思決定上の優先順位を明確に言語化する
  • 「強度を稼がないといけないのだから、工程の複雑化は受容する」
• 直観(仮説)と論理の両面からの説明を試みる
  • とりあえずこう考えておけばうまくいくという端的な説明を対外的にしつつ
  • それがなぜ、どこまでうまくいくのかの裏を押さえにいく

間違えにくい技術選定を教科書的に書くとこのようなことが言えそうです。
一方でこれをやらなくてもうまく行く人はいるので、あくまでいち意見として捉えていただけると幸いです。
(実際うまく意思決定できる人は、このような意見を話半分で受け止められる人だと考えられます。)

まとめ

• paizaではReactに一本化されました
  • 「こちらではVue、あちらではReact」みたいな状況にしなくて済みました
  • 引き続きプラクティスを固めながら機能開発を進めています
• トレンドやベストプラクティスは自分たちの文脈で読み替え、その価値を問いただす必要があります
  • ただトレンドに乗っただけでは、開発がいずれスタックします
• 筆者が技術選定にあたり意識していることを言語化しました
  • 話半分で受け止めていただけると幸いです
  • どちらかというとリスク最小化や合理的判断を選好しています
  • もう少しリスクテイクしたほうが良い気もしますが、それは個人的にやることにしています

paizaではさまざまな職種のエンジニアを募集しております。MVV(ミッション・ビジョン・バリュー)に共感できる方、paizaの取り組みに興味、関心がある方からの応募をお待ちしております。

https://paiza.jp/recruiters/9