同僚と設計やアーキテクチャの話をしていて、「目の前の問題に向き合うしかない」 というようなことを言われて、数週間くらい反芻して、ようやくそれを内面化できてきたような気がする。
ソフトウェア開発をしていると、設計で悩む。設計は難しいので当たり前である。 Unity/C#で開発をして、設計に悩んでインターネットで調べると、Clean Architectureに遭遇する。 同心円上のレイヤー構造のアーキテクスチャ図に遭遇する。
Clean Architectureの例の図は「公式」ではない、ということがようやく最近分かってきたように感じる。 本をちゃんと読むと公式であるとは一言も書いてないし、後ろの方にはレイヤードアーキテクチャは叫ばないとちゃんと書いてある。
じゃあアーキテクチャとかデザインパターンとかって何なんですか？役に立たないんですか？というとそうではないと自分は思う。 設計の本に書かれている抽象的なパターンとされているものは、特定の問題に対して優秀なエンジニアたちが与えた解なのではないか。 具体的な問題があってそれに対する解を与えて、じゃあなんでそれが解なのかを考えると、要素をそぎ落として抽象的なものが残るはずで、 なんかそういう手続きの最終的な出力なのだと思う。 それから学ぶためにやるべきことは何かというと、解を見ることではなくて、問題と解の関係や、解決の過程なんじゃないかと思う。
当たり前のことだけとツイッターとタクシー予約システムと3Dアクションゲームでは問題が違う。 アンクルボブに解いてもらうのは諦めて、目の前の問題を解くことが自分の仕事なんじゃないだろうか。
問題を解くというのは非自明な行為で、だからこそ自分は飯を食えているのであって、ありがたいことである。
そう考えると、数学やっていたときとやることは同じで、問題に向き合うしかないということで、なんか色々腑に落ちた。
