先日、寝起きに書き殴った記事だけど、誰も読まないかもと思ってたけどありがたい事に結構反響があった。

それはいいんだけど、ある意味で反響がありすぎたので、ちょっと収拾を付けた方がいいかもなと思った。

まず、「記事を書いた人がクリーンアーキテクチャに対して無理解すぎる」みたいな反応が一部にあった。
たしかに、今思えば、あの”憂鬱”の記事を書いた時点で私の理解が足りてなかった面があるかもしれない。

しかし、当然だろう。分かってなかったから勉強していたのだ。

が、なんともありがたい事に、”憂鬱”の記事へのみんなの反応を追っかけてる内に、設計に対する世間のコンセンサスがどんな温度感なのかを結構把握させていただいた。クリーンアーキテクチャへの理解も深まった気がする。つまり、記事を書く前より今の方が理解がクリアになっているはずだ。

私はそもそも、”Unityでクリーンアーキテクチャを学ぶ”的なシリーズのブログ記事を書こうかな！と思って勉強を始めたのだ。

そのモチベーションは、Unityのプロジェクトがシーンが取っ散らかったりしてカオスになりがちなのを何とかしたいと思ったからだ。

まず私の理解が浅かったのは、”クリーンアーキテクチャって言うくらいだから使えばシーンとかがクリーンになるんだろ”程度に思っていたことだ。だが、「クリーンアーキテクチャ」ってのは単にそういう名前なだけで、これを使ってれば全部がクリーンで、使ってなければ全部がダーティというようなもんではないと知った。

これも理解が浅かったが、クリーンアーキテクチャってのはアプリ全般に適用しなければならず、もしインターフェース切らずに参照したらぶっ殺す！（プルリクを）みたいな過激派宗教か何かと思い込んでいた。実際のところは、そんな押し付けるものじゃなくて、別に無理して使わなくていいよ。使えそうなところに使ってね。みたいな優しいアレらしい。そうだよね？

とにかく、そんなわけで当時の私は「クリーンアーキテクチャなんてもんが蔓延したらUnityのプロジェクトはまったく進捗出なくなるぞコレ！」みたく思い込んで、クリーンアーキテクチャを学ぶ記事を書くのをキャンセルして、”憂鬱”の記事をでっち上げた。

”憂鬱”の記事の中でとりすーぷさんのスライドを引用させていただいたので、とりすーぷさんにご迷惑をおかけしないように、「まあバーチャルキャストはゲームじゃ無いしクリーンアーキテクチャが刺さるかも」というようなフォローを入れて極力配慮したつもりだったが、それでもご本人に何らかの動揺を与えてしまったとしたら、

すいませんでした。

また、「主語がデカすぎる」という反応もいくつかあった。何のことかハッキリしないが、多分、「Unityでゲーム開発するのにクリーンアーキテクチャが向いてない」という主張の事だろう。

当時はUnityでのインゲーム的な部分の事ばっかり考えていたが、たしかに、ソシャゲのアウトゲームの通信部分とかは”固く”作るし、別のプロジェクトでも使い回す都合、オニオンアーキテクチャを使った方が便利な部分もあるだろう。

もしも「自分は普通にUnityでのゲーム開発でクリーンアーキテクチャ使ってるが？」という人のお気持ちを傷つけたとしたら、

すいませんでした。

使い回しの話で言うと、Unityで複数プロジェクトで使い回すライブラリに、DIコンテナを使うみたいな事も、それはどうかな？と思っていたけど、結局アウトゲームの話と同じで”固く”、”差し替えが効く”ようにするためにDIコンテナ＆クリーンアーキテクチャを使うのはアリなんだろうなと今は思う。ただ、Zenjectとか特定のDIコンテナに依存してしまうと、vContainer使いたいプロジェクトではどうすんだ？って事になりそうだから、DI使う前提で作るのはともかく、依存はしない方がいいのかもなと思う。

逆に、敵キャラやらのオブジェクトが動的に生成、消滅を繰り返す、MonoBehaviourが跋扈してるインゲームの世界ではクリーンアーキテクチャ使う必要は無い。そういうコンセンサスでいいよね？

”憂鬱”の記事を書きやすくするために、”クリーン勢”という想像上の存在を作ってシャドウボクシングしたわけだが、無理やりUnityのマッチしない箇所にまでクリーンアーキテクチャを教条的に強制する”クリーン勢”なんて現実には存在しなかったわけだ。そうだよね？

毎日仕様変更を言ってくるくせに「コードをちゃんと設計しろ！クリーンに書け」とか無茶なダブルバインドしてくるクライアントも存在しない。

クリーンアーキテクチャについてよく分かってないけど、とにかくこれ使ってなかったら評価下げてくるような上司も存在しない。

仮に、もしそんな連中が存在するとしたら、それは邪悪って事だ。そうではありませんか？

だから、全てをクリーンアーキテクチャで無理やり書かされて、ちゃぶ台返しされる度に全てぶん投げて設計し直すハメになってるような賽の河原の住人も、そんな気の毒な人は存在しないんだよね？

はい。

インゲームに無理にクリーンアーキテクチャ使うメリット無いというコンセンサスが取れたっぽいだけでも記事を書いて良かったと思う。

自分自身の狭い範囲の見識だけで考えていたので、色んな人の意見のおかげで視野が広く持てた。

「Unity以外でもどこでもこんな感じ（ちゃぶ台返しと仕様変更が日常茶飯事）だよ」みたいな反応もあった。それは大変そう。

「どこかのタイミングでクリーンに作り直さないと保守できなくなる」という反応もあった。そうかもしれないけど、ちょっと疑問がある。”憂鬱”の記事で、クリーンアーキテクチャを使うと”変更”には強くなるけど”設計の変更”には脆くなるという話をした。だからクリーンアーキテクチャで全面的に作り直したらもうその後は大きな変更が効かなくなるんじゃないかな。どうなんでしょうか。

「そもそも開発以前に仕事の進め方がおかしい」という反応もあった。まあマトモなエンジニアが拾わないような仕事を拾うUnityソルジャーもいるって事かもな。

ちょっと話変わるけど、今の時代ってアプリを設計して作って終わり。って感じでもない気がする。Paypayとか毎日機能増えてるような勢いだけど。いわゆるマイクロサービス的な話？

”憂鬱”の記事では、Unityでクリーンアーキテクチャが万能に使えるわけでは無いと分かって絶望して、クリーンがダメならもうダーティになるしかねえんだ。みたいな極端な結論を書いてしまっているが、これをクソコードを書く免罪符みたいに使われるのは困る。

私は別にクソコードを書いてるつもりはない。Unity的に普通のコードを書いてるつもり。
マジモンのクソコードはそもそも他人に引き継げない。（普通に難しいアルゴリズムを書いてるから引き継げない場合もある）

さて、そもそも最初のモチベーションだった、Unityプロジェクトを綺麗にする事についてはまだ何も達成できてない。

今は、クリーンアーキテクチャじゃなくても別の方法でUnityプロジェクトを綺麗にできないか考えている。

例えば、vContainerの作者のhadashiAさんが講演で発表した資料がある。

Unity専用最速DIコンテナVContainer と、UnityにおけるDIの勘所

vContainerというのは、ZenjectみたいなUnity用DIコンテナの一種である。

この資料では、UnityでのDIコンテナの使い方として、クリーンアーキテクチャ的な事は特に推してない。

ゲームにシンプルなDI を持ち込んで嬉しいポイント
制御フローをシンプルにすることの補助に使える
オブジェクト間の複雑すぎる関連を抑止する制約をつけることができる

との事。

まだよく分かってないので勉強中だが、ピュアなC#クラスに対してシーン上のMonobehaviourをDIでインジェクトすることで、依存関係をシンプルにしよう。みたいな話らしい。

Monobehaviourにする必要のない物はピュアC#のままにして、なるべくシーン上のゲームオブジェクトを減らす。みたいな事もできそうだ。なにしろシーン上のゲームオブジェクトの数が増えるとそれだけでカオスな感じになるから。

この辺りを勉強して、Unityプロジェクトをクリーンにする便利な方法が見つかったら、また記事を書きたい。