時間芸術としての天丼（190226）

本日の日報記です。

8時半：
起床。
６時半に起きたのに、、

10時半：
出社。

自分がアプリを設計するときは、今度からこんな感じのルールでやってみるかみたいな基本方針がおぼろげながら見えてきた。

# VLD-System
- View層(UI・グラフィック)
- Logic層(そのコンテンツ独自の挙動)
- Data層(コンテンツで使うデータ。)

以下が今の所思いついたルール。今後書いてみてもっと掘り下げる。

- 実装クラスに依存して良いのは、各層のトランザクション間のみ。
同じ層で別のトランザクションとやり取りする際はインターフェースを介する。
- 下の層は上の層に依存してはいけない（絶対に）
→例えば、
「View層で制御しているGameObjectの位置を
Logic層のゲーム進行を行うクラスから直接参照してロジックを組む」
みたいなのはダメで、
「Data層のFactoryクラスからインスタンス化。
生成されたGameObjectはData層に登録され、その情報を更新し続け、それを元にロジックを組む」
みたいなやり方のほうがあとあとに活きるかもしれない。どこがどこに依存してるかがわかりやすいってのと
取り外しと取り付けが楽そう。まだ試してないから知らんけど。

あと、この設計を強制できるようなフレームワークを組んでみるのもいいかもしれない。悩むこと減らせるし。コードは書くからバグる。どうやればいいかはわからん。
あと、設計とかの追求は時間だったりアプリの運用上の寿命と相談だよなぁということも思った。でかいソシャゲ開発みたいなのだったらルールをガチガチに決めて設計しないとダメだろうけど、井上みたいな半分イベント屋みたいなエンジニアの場合はその限りではないので、「多少の追加要件」+「現場での安定稼働・運用」に対応するまでが責任範囲なんだろうなと。あんまやりすぎるとコストに見合わない上に可読性が低いだけのクソ実装になり兼ねない。いずれにせよ、まだまだ井上のレベルは低い（と思ってる）ので、やっていきの心は持ち続ける。

16時：
3D歴20年の先輩がIKについてレクチャーしてくれた。
上の文書くので力尽きてしまったので、もうちょいまとめたあたりでここにメモする。

20時半：
お仕事にまた火がつき始めてきたけど、洗濯しなきゃいけなかったので帰宅。明日またオフィスに泊まりそう、、

23時：
約1週間ぶりの部活(PUBG)。
1時間でもいいから娯楽をやらないといけない。（多分仕事をいい訳にしてたらPUBGどころか何１つ手がつかなくなる可能性がある）

明日もよろしくお願いします。