UniRxの注意点 (チーム制作など)
スポンサーリンク
今回はざっくりとした内容です。
UniRxを使っていてここは気をつけないと行けないなー と思ったところを書いてみました。
可読性が低い
チーム制作中によく起きるのが、「このUniRxの処理何やってるのか全然わからん！」という苦情です。
UniRxはLinqの様な書き方で、作者にとっては分かりやすい内容になっていますが、他人やUniRxを知らない人から見ると どこでどう使っているの？ と困惑してしまいます。
ストリームスパゲティ地獄
これもよく見ます。
単純に至る所でStreamとSubscribeが走っていて、どこでどう分岐しているのか解りづらい状態です。
この状態を防ぐ方法は２つ 有ります。
- StreamのSubscribeは全てAwake()で起こす
- Streamごとに単体クラスにする
1点目は某企業様のブログにて拝見しましたが、これを行うことで各ストリームの流れを把握しやすくなります。
２点目は関数化でも問題有りません。
Streamの削除し忘れ
これは稀におきますが最悪のミスです。
対象オブジェクトやイベントが消えた後もストリームは永久的に走り続けます。
バグやフリーズの原因にもなりかねません。最悪です。
対象法は
- AddTo()などの破棄処理をつける。
- Dispose()で外部から破棄処理を行う。
基本的にこれらをしっかりと守っていれば大丈夫です。
条件分岐などもあるため、Do()やSubscribe()のタイミングでLogを仕掛けるといいと思います。
Steramの発信場所と受信場所はどこ？
これは可読性やスパゲティコードの話と繋がりますが、例えばOnNext()で信号を送った先はどこでどんな処理を行うのかが解りづらいところです。
解決策は、コメントで受信先を記載する とか、変数名で特定できる様に してなどです。
VSCodeだと参照先を検索する機能があるのが便利ですよね。
それUniRxでやる必要ある？
何度も突拍子の無い発言に聞こえますがよく言われます。
確かにUniRxで行わなくてもいい処理を ワザワザUniRxで行なっているのです。
UniRxの使い方に慣れているのは分かりますが、プロジェクト全体でUniRxの処理を把握していない場合、良からぬ軋轢を生みかねません。
Rx系は便利な分、使い方を明確にしないとリファクタリングなどの工数が無駄に掛かってしまいます。
