オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある
— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日
上のツイートを見かけたので、自分は何を心がけているか書いてみる。
結論
- プロダクト方針的に起こりそうな未来を想像する
- 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える
- その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする
前提: あらゆる未来の変更に強い抽象化はない
設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが、あっちの未来には逆に対応しづらくなることが起こる。
そこで、プロダクトとして起こる確率が高そうな未来に対して対応しやすい設計を考えることになる。
プロダクト方針的に起こりそうな未来を想像する
ではプロダクト方針的に起こりそうな未来はどのように想像すれば良いだろうか？これは自分の勝手な想像をするのではなく、会社のビジョンやビジネスモデル、プロダクトのビジョン、PMのプロダクト方針・ロードマップをしっかり理解して想像する必要がある。
- 会社のビジョンやビジネスモデル、プロダクトのビジョンを理解すれば少なくとも絶対選択しなそうな方向は絞れる
- PMのプロダクト方針を理解すれば、確率が高そうな未来は絞れる
- プロダクトのロードマップを見れば、近い未来に起きそうなことが絞れる
もちろん、絶対に起こるものを知る術はないのだが、このあたりを抑えておくことでより予測精度は高まるだろう。もし情報が足りないと思ったら、欲しい情報を持っている人に直接聞きに行ったら良い。
想像した未来が起こったとして、どのような実装になりうるかをざっくり考える
続いて、想像したいくつかの未来が起こったとして、その時にどのような設計・実装になるかをざっくり考えてみる。この時は精緻に考える必要はなく、本当にざっくりとしたイメージで良い。なんとなーく、DBスキーマはこうなるよな〜とか、APIのインターフェイスはこういう感じかな〜とか程度で考える。
その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする
未来での実装がざっくり想像できたら、続いて今回の設計を考える。ちなみに現段階の設計を考えると、未来のことがより見えることもあるので、未来の設計と現段階の設計は行ったり来たりしながら考えることも多い。
この時は、その未来が起こることが確実として、その時に即座に実装できるように設計するのではなく、「詰む」ことがなさそうな程度に一番シンプルな設計にする。なぜ一番シンプルにするかというと、この段階で未来を想像しすぎて抽象化すると、その未来が起こらなかった時に
- 現段階では無駄な工数をかけてしまう
- その未来が起こらなかった時に、ただ認知負荷が上がるだけになる
- その未来とは別方向に進んだ場合、むしろ変更が難しくなる
となってしまうからだ。
じゃあ「詰む」というのは何か？「詰む」という表現は、自分の中ではこういうイメージで捉えている。
- そもそもその未来のための設計に変更が不可能である
- その未来が起こった時に、莫大な変更工数がかかる
元のツイートに
例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある
ということが書いてあったが、詰みやすさというのがレイヤーごとに違うという話だと思う。
- データのレイヤーは、データ自体が蓄積するため、変更しようとするとデータの変更も必要である。そのためサービスダウンが認められないケースで変更が不可能になってしまったり、データ移行に莫大な変更工数がかかることがある
- サービスとしてコアドメインなロジックのレイヤーは、その部分を変更しようとすると影響範囲が広がりやすい。そのため、変更に莫大な工数がかかりうる
- ロジックの関数シグネチャレベルの変更であれば、変更自体はそんなに大変ではない
- あるページ単体のUIの変更であれば、変更自体はそんなに大変ではない
もっとも詰みやすさが違うだけであり、詰みやすいレイヤーだからといって非常に抽象度高く作りましょうという話ではない。例えばデータのレイヤーだからといって無駄に抽象度高く作ってしまうと、先ほど言ったようにただ認知負荷が上がってしまったり、想像していた未来ではなかった場合に逆に変更が難しくなる。
まとめ
こんな感じで僕は、地道にプロダクトの指針を理解して、その指針に設計を合わせられるようにした上で、現段階では一番シンプルに心がけるようにしている。
正直な話、初めから抽象化してる設計を触る時、50%以上の確率で逆に困る〜となることが多いので、最初はシンプルにして欲しいという気持ちは強い。
