みんな、プログラミングしてる？
Rxがまた賑やかだなって時代なので実際UniRxを使った運用経験があるのでちょっとそのことについて書く。
UniRx？なにそれ？って方は以下の記事参考にしてください。
Qiita記事: UniRx入門
2020/03/10 追記
自分が思った以上にコメントが寄せられて、いろいろ思うことがあったので。
この記事はあくまでUniRxを使ってどう思ったのか、こうすべきだと思ったよという感想の記事を主体にしています。
その上で正しい実装サンプルを綺麗に書こうとは考えてないです。(当然読んだ人も思うところあると思います)
コメント側にも記載しましたが反響次第では記事の削除をします。
個人の感想
地獄そのものでした。
自身がLとして開発入る時は二度と採用することはないです。
UniRx自体はとても素晴らしいものですが、使うものによっては神にでも悪魔にでもなれるマジンガーZみたいな存在です。
この記事はUniRxを貶しているわけではなく、UniRxを使いこなす自信がない場合は採用を考えたほうが良いという記事です。
UniRxの良いところ
- シンプルにかける
- 可読性が上がる
- 制御実装が楽になる
よく見かけるのはこのあたり。
実際デザインパターンがしっかり考慮された実装になっていて素晴らしい完成度を誇っています。
UniRxの悪いところ
- 学習コストが高い
- 実装難易度が高い
- 運用においてめちゃくちゃ邪魔になってくる(ここ重要)
- 人を選ぶ
- 大規模プロジェクトでは必ず地雷を踏むはめになる
- テストが書きづらい
UniRxはシンプルに見えて難易度はめちゃくちゃ高いです。
おまけに学習コストもべらぼうに高いので運用プロジェクトにはとてもじゃないですが向いてないです。
運用して見えた問題点
- ラムダ式の多用
- 運用時の不具合調査でスタックトレースで追うことが事実上不可能になる。
- 調査のためのログ仕込みという不毛な実装をしなければならなくなる。
- 参照漏れ
- AddTo忘れ。
- 多重のイベント登録
- シーンが切り替わる毎に積まれるイベント
- 学習の責任問題
- プロジェクトでUniRxを手取り足取り教えるなんてフローは基本的にないものと見たほうがいい。
- また難易度の高さも踏まえて基本的には個人の裁量になる。結果、破綻する。
問題点への対策
PRレビューで使い方の指摘を徹底する
ラムダ式の多用、学習の責任問題、参照漏れ、多重のイベント登録はこれである程度の回避はできる。
レビューするものがしっかりとすべての問題点について指摘し、実装者の能力を底上げしていくという仕組み。
そう、たったこれだけで解決ができる。
コメントをしっかり残す
機能に対してコメントをしっかり残す。それにより後続のメンバーがより理解できる体制を整える。
そういった配慮だけでもだいぶ変わってくる。
自己の研鑽を怠らない
プロジェクトで新しい技術が必要になれば当然学習も必要。
UniRxとはどういうものか、またプロジェクトではどういう使われ方をしているかをしっかり把握する。
極端な話、PRの指摘だけでプロジェクト全体の問題は解決できそうだなって思います。
そもそもみんな気をつければ悲劇なんて起きないんですよ！
しかし……
問題点への対策の問題点
PRレビューの徹底は不可能
PRレビューの徹底はスケジュールにゆとりがある、経験豊富なリードエンジニアがいる、実装者の精神的余裕と能力の高さが必要になります。この中で現実的に可能なのは経験豊富なリードエンジニアだけであり、他の2つについてはほぼ実現不可能と思ったほうが良い。
つまりこの対策はほぼ実現不可能ということになる。
自己の研鑽を怠らない
プログラマなら勉強するよね、そんなことを思っていた時が俺にもありました。
仕事の時間以外では勉強しない人は本当にしないのでこの当たりは宛てにできない事情がどこかで発生します。
そもそもの話
UniRxをただの便利ライブラリだと勘違いしている人が多い
- UniRxは別に便利ライブラリでもなんでもない。
- ご存知の通りだけどObserverパターンを元に設計された非同期処理用のライブラリがUniRxです。
- Observerパターンは最低限理解してほしい。
- 「UniRx使ってる俺凄いんだぜ(意訳)」ってマジで言ってるエンジニアもいるぐらいには結構やばいと思ってる。
他人の実装をそのまま参考に実装してしまう人が多い
- Qiitaの記事の機能そのままで実装してるケースも結構ある。
- 問題が起きた時にこのあたり実装者が責任が持てないケースが発生していた
- この手の問題が起きた時はだいたい作り直しが余儀なくされる(その場限りの回避が危険なケース)
それでもUniRx使いたい人向けへのアドバイス
それでもUniRxは素晴らしいから使いたい、という人向けの話です。
PRレビューの徹底
前述もしましたがこの徹底は必ずやるようにしよう。
githubだったらPRテンプレートにUniRxの実装時に注意するチェックリストを設けるなどをして徹底する。
アンチパターンの定義
ラムダ式は全面禁止にしましょう、実装の幅が狭くなる、関数が増えてしまう、ということはあるかもしれません。
しかし運用後に絶対に地獄を見ることになってしまうのでラムダ式は全面禁止をしていいと思います。
UniRxでトラブルを起こしやすいのは運用を意識できないエンジニアに多いので運用を意識した実装をさせることも重要だと思います。
またラムダ式はテストを書く際に必ず苦労することになるのでかかせないためのテストファーストという選択肢もあります。
テストファーストの実施
前述しましたがテストファーストで対応すればここまでに記載した問題点は全体的にカバーができる可能性があります。
しかし、これをやりきるのは結構難しいものがあるのでそのあたり踏まえていけるのか、という問題点は残ります。
最後に
UniRxは凄い、今のトレンドだ、って話は結構長いこと見かけています。
私が運用に関わったのは2017年頃の話でこの頃もUniRxがトレンドだ、という話題はありました。
勉強会など参加してみて話を聞いてみると「これからの時代はUniRxだから勉強する」って話は結構見かけます。
一方ですでにUniRxは導入済みだが運用案件で使ってみると損ばかりだったという話も結構聞きます。
ではUniRxが悪いのか、という話かでいうとそうではありません。
個人的なポイントとしてはUniRxの考え方に関する記事がそこまで作られていない、あるいは読まれていないのではと思っています。
制御系の実装が簡単にできる、という説明をしているエンジニアは結構多いです。
これらを踏まえてUniRxは採用すべきなのか、長期的に見て運用に耐えられるのか、という観点も踏まえて採用を検討していただきたいです。
ではこれから胃に穴を開けながら投稿ボタンをおそうと思います。
ちょっとした補足
新人エンジニアの人はUniRx使う前にデザインパターンの勉強とテスト実装に関しての知識を身に着けてほしいです。
UniRxが駄目だ、と僕が書いて理由は使いこなせないまま運用が走ってしまって結局カオス化するという点のみです。
むしろチーム全体に高い設計能力が伴っていればUniRxは神になれるはずなのです。
そのことを踏まえて研鑽してもらえれば幸いです。
